Get website UI to work + make customizable

[batpad]

Right now, we use the openstreetmap-website container essentially only as an API - you can edit with iD or JOSM and export data out / create vector tiles. Ideally, this website would "work" for users of an instance just like osm.org and elements like name be customizable. Ideally, however we make these changes, would not result in a fork, but we maintain an easy / clear path to receiving updates from upstream.

Things I can think of we would need to get working:

• Make website name and logo customizable
• Get the map to work. This is probably the hardest bit. We will need to swap out the current map view on osm.org to use vector tiles, OR generate rasters. This is probably non-trivial, but there could be some existing work here we could leverage.
• Either get the geocoder to work or hide it / work-around it. It's probably worth the effort to add Nominatim as a container and configure the geocoder widget to use it.

We should also have a clear idea on how we plan to make changes in a way that we can easily keep up with upstream.

cc @geohacker @kamicut @Rub21

[batpad]

Bumping this to think about it a little ..

My idea for this is roughly:

• Make changes to the OSM website code to make things like the logo, basic text, etc. customizable.
• See if its possible to switch out the map view on the website to use vector tiles without breaking everything.

Now, the tricky part here is how do we maintain this "fork". My idea for this is:

• As part of the docker build process, we still pull from the upstream openstreetmap-website repository.
• We maintain our modifications as a git patch file, that we maintain in our repository.
• As part ofthe build process, we apply the patch to the upstream code. This allows to maintain our patches separately, and not have to maintain a fork.
• In the interest of organization, we may want to have multiple patches and not a single large patch file.
• Ideally, we have a test configured that tests pulling the latest upstream code and applying our patch(es) - if the patch fails, we figure out modifying our patch file to work with the latest upstream changes and then commit the new patch file.

I like the idea of maintaining and checking in patch files, instead of maintaing a fork of the osm website repo that gets potentially easy to forget about updating and then very painful to update whenever we do.

I don't still have a clear idea of the best way to do this, but just bumping this here.