Use OHM slippy map on OHM nominatim

[jeffreyameyer]

Bug description

What is happening?: when I visit nominatim.openhistoricalmap.org, I see the openstreetmap slippy map and not the OHM slippy map.

What should be happening? I should be able to see the results of the nominatim search, which list what is in OHM, but the display doesn't show this.

Repro Steps Steps to reproduce the behavior:

1. Go to nominatim.openhistoricalmap.org
2. Search on 'Kehl"
3. Click on any of the results
4. Note that you cannot see anything on the basemap.

Screenshots & URL

[geohacker]

@jeffreyameyer this is true. We ticketed this a while ago when we setup nominatim https://github.com/OpenHistoricalMap/ohm-nominatim/issues/8

What's needed here is to fork the nominatim front-end code, and update the tile URL. But it's not super straightforward as we don't have a raster tile endpoint like the default OSM tiles. Though, we could replace the slippy map on nominatim website with a mapbox gl js and then use our vector tiles.

@danrademacher what do you think?

[danrademacher]

The Leaflet timeslider demo we have might provide relatively readymade code to swap in GL inside Leaflet as the least invasive approach. I'll take a look

[danrademacher]

Hmm, OK, I looked into this some more, and here's my take:

• Currently, we don't actually have a fork of Nominatim, we're just installing straight from OSM, but with our own database. This is great because it means we have one fewer fork to maintain.
• If we want to have our vector tiles on our Nominatim, as Sajjad noted, we can't just replace this line of code for a new xyz template: https://github.com/osm-search/Nominatim/blob/master/settings/defaults.php#L97.
• Instead, we'd need to mod the Nominatim website code. Simplest example would be to pull from the Leaflet GL timeslider demo, https://github.com/OpenHistoricalMap/mbgltimeslider-leaflet-control/blob/master/demo/index.html, though not sure we actually want a timeslider here.
• Nominatim is a PHP application, and we'd have to root around a bit to see how we can best replace the map without making it overly difficult to stay in sync with upstream changes. It might just be a matter of hacking at this area of one JS file, https://github.com/osm-search/Nominatim/blob/f69c3d2b6674fe6624460e6a644d1f6e2cb2b415/website/js/nominatim-ui.js#L60-L63, but would need to experiment a bit and see.

I do find myself wondering a bit how important nominatim.openhistoricalmap.org is as a separate website. We need the service and application running to get search on openhistoricalmap.org, and it's nice to have this specific search and display system, but it also seems like Yet Another Thing to try to keep a fork aligned with upstream code.

[jeffreyameyer]

Well... I think the important thing is something we haven't really mentioned, which is including some sense of time in the search results.

That might argue for a different geocoder altogether... let's hold off on this thread for a bit.

On Sat, Oct 31, 2020 at 9:54 PM Dan Rademacher notifications@github.com wrote:

Hmm, OK, I looked into this some more, and here's my take:

• Currently, we don't actually have a fork of Nominatim, we're just installing straight from OSM, but with our own database. This is great because it means we have one fewer fork to maintain.
• If we want to have our vector tiles on our Nominatim, as Sajjad noted, we can't just replace this line of code for a new xyz template: https://github.com/osm-search/Nominatim/blob/master/settings/defaults.php#L97 .
• Instead, we'd need to mod the Nominatim website code. Simplest example would be to pull from the Leaflet GL timeslider demo, https://github.com/OpenHistoricalMap/mbgltimeslider-leaflet-control/blob/master/demo/index.html, though not sure we actually want a timeslider here.
• Nominatim is a PHP application, and we'd have to root around a bit to see how we can best replace the map without making it overly difficult to stay in sync with upstream changes. It might just be a matter of hacking at this area of one JS file, https://github.com/osm-search/Nominatim/blob/f69c3d2b6674fe6624460e6a644d1f6e2cb2b415/website/js/nominatim-ui.js#L60-L63, but would need to experiment a bit and see.

I do find myself wondering a bit how important nominatim.openhistoricalmap.org is as a separate website. We need the service and application running to get search on openhistoricalmap.org, and it's nice to have this specific search and display system, but it also seems like Yet Another Thing to try to keep a fork aligned with upstream code.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OpenHistoricalMap/issues/issues/157#issuecomment-720028039, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALM4ETZ6MMIKSSVEXSTJGLSNTSYRANCNFSM4TEH5JKQ .

-- Jeff Meyer 206-676-2347 osm: Open Historical Map (OHM) http://wiki.openstreetmap.org/wiki/Open_Historical_Map / my OSM user page http://www.openstreetmap.org/user/jeffmeyer t: @OpenHistMap

[danrademacher]

I just remembered that we talked a long time ago (2018?) about trying to handle date-specific results client-side within openhistoricalmap.org — so ask Nominatim for all results, and then filter them on OHM.org.

So aim for an approach that reworks this Sidebar with JS to layer on date filtering to these results:

This approach would build on other sidebar work we have to do, and focus our code changes still on the website codebase. But it would still leave us with a nominatim.openhistoricalmap.org that's an incomplete OSM-ish experience, with OSM maptiles and no date filtering...

[jeffreyameyer]

Closing per decision not to set up standalone nominatim.ohm.org in #378 - but, we still need to turn off the hyperlink in search results - new ticket coming for that.