Feature requirements for v2

[merlinnot]

I intend to work on a v2 version and I'd love to hear your feedback and brainstorm some ideas.

What I have in mind is:

• Separate it into two containers, provide a Docker Compose file:
  • Postgres with storage attached as a volume
  • An API
• Support root path (drop the /nominatim prefix for paths).
• Update all dependencies.
• Enable automated updates with Renovate if possible.
• Resolve an issue with the database updates.
• Restructure the documentation to include more details on suggested deployment strategies, elaborate on options, add contributing guidelines etc.

[ryan-morris]

I tend to avoid using databases inside docker containers because they are too difficult to tune properly, especially with one as big as OSM. Though I do understand this is a necessity for most people to just get up and running.

I have a cluster of postgres servers I'd love to be able to offload to. If possible it would be great if the API just had an environment variable for pointing to a database, then link them in the default compose configuration. The problem with "external" databases from nominatim is the required extension that gets installed, I'm not sure if this is something the API container could handle during intial setup or something you were planning on addressing in the postgres container image. Also, if using something like docker swarm, there might be more than 1 instance of the API container running, so preventing conflicts or issues during updates may be problematic.

[bryanrideshark]

If anything, it would be incredibly helpful just to separate it into two containers.

[UntitleDude]

I'd love to be able to initialize the build blocks of the containers until you have to import data. Having to re-initialize the first steps can take quite a lot of time. Take a look at this other nominatim-docker which uses this mechanic.