Migrate slippy map from Leaflet to GL JS

[1ec5]

As a followup to upgrading the slippy map to a newer version of GL JS in #650, I think we should consider migrating off of Leaflet altogether, embedding a GL JS map instead. Leaflet’s only advantage is its lower browser and graphics requirements, but the map is unusable anyways in any environment that doesn’t support GL JS. Embedding GL JS directly comes with many benefits, including:

• Significantly better rendering performance, especially when animating the time slider
• Smooth updates while zooming in and out
• Rotation, which allows users to orient the map consistent with non-Western traditions when desired
• Support for screen readers through the mapbox-gl-accessibility plugin
• Potential point-and-click interactivity
• Consistency with secondary maps such as the timeslider demo, embed map, and tile inspector
• Much easier debugging of the deployed style

This upgrade will require us to rewrite the site’s Leaflet integration, which consists of several custom controls and some external plugins such as leaflet-osm. Some of this code has readily available replacements, either built into GL JS or as plugins. As far as I can tell, the impact to the custom time slider and inspector code should be minimal.

Ideally, these changes would be implemented upstream in openstreetmap-website. However, that project has been debating a migration to vector tiles for years without much to show for it yet: openstreetmap/operations#214. Even just implementing the compatibility shim we’re using hasn’t really gone anywhere. (openstreetmap/openstreetmap-website#2686 hasn’t ruled it out, but the proposed implementation in openstreetmap/openstreetmap-website#4042 has gotten bogged down in unrelated concerns.)

[1ec5]

Ideally, these changes would be implemented upstream in openstreetmap-website.

OSM’s Engineering Working Group has hired @pnorman to build vector tile support on osm.org. If the implementation is powered by MapLibre GL JS, then there would be relatively little to do on the OHM side other than streamline how the time slider code interacts with the style. We’d continue to use our own tileset and styles but will no longer need the Leaflet compatibility shim.

[jeffreyameyer]

@1ec5 - it's 6 months past your OP. Any updated thoughts or perspectives on any changes in the landscape, etc.? Getting this done would be a very very nice thing. 😎

[erictheise]

Odd that I didn't hear anything about vector tiles upgrades at osm.org at State of the Map US/Salt Lake City but maybe I was in the wrong sessions (or was heads down working on my own (Friday morning)).

[1ec5]

@pnorman didn’t get a speaking slot at SotMUS, but there were lots of side discussions about the OSMF vector tile transition. There were also lots of discussions among MapLibre folks about how to evolve the tile format, which might eventually have an impact on us.

My understanding is that the current OSMF-funded effort is focused on the tile generation and serving, but obviously styling and website integration would be important if this work is ever to see the light of day. I asked a few months ago whether osm-website would adopt our current approach or migrate directly to GL JS, but they didn’t have a concrete plan at the time.

A migration to GL JS would entail largely the same work for both OSM and OHM in the Rails port and client-side scripts, but OSM would need to contend with the unmaintained Leaflet Routing Machine dependency, while we’d have to upgrade our time slider library. If we feel confident in the customizations we made to implement the MapLibre compatibility shim, then we could offer to upstream them as a starting point. At least that would reduce the burden of maintaining our fork.

However, since we already know we want to move beyond this compatibility shim, it might be incumbent upon us to lay the groundwork for a GL JS transition ourselves, either here or upstream. Otherwise, I fear the path of least resistance will be to simply adopt the compatibility shim and get stuck with it for many more years.

[jeffreyameyer]

@1ec5 and I talked about this ticket this morning. I have a concern that if we wait for OSM to do this, it could be quite a ways off. In order to get a better sense of what exactly it might take if we did want to do it on our own in a way that made the most sense, here's a very high-level set of short-term next steps to move this discussion forward:

• [x] Write a ticket to better scope the impact of removing leaflet from OHM, including descoping things like leaflet routing: #828
• [ ] Talk with @danrademacher & team about what it might take, organizationally, to work with OSM as we work through this dev work; maybe there's an opportunity to push upstream or make available for testing with @pnorman's work

[1ec5]

we’d have to upgrade our time slider library

Or resurrect mbgl-timeslider perhaps.