Support client-side rendered featured layers

[pnorman]

The OWG has had a couple of submissions for featured layers that involve client-side rendered featured layers.

We should figure out how to support them. The requirements I see are

• other layers work when a user's setup doesn't support a particular client-side layer (e.g. if webgl is disabled)

• we aren't locked into only supporting one client-side rendering engine

• large libraries aren't loaded until a user needs it

• client-side layer support in the layer switcher bar

• support for fractional zooms on client-side layers

The client-side rendered layers we've had interest from are using Mapbox GL, but like I mentioned, we need to be able to support multiple client-side rendering engines in the future

Two methods mentioned are

• use mapbox-gl-leaflet, or
• shift to Mapbox GL JS.

I don't know enough to know if there are other options. Shifting to Mapbox GL JS seems like more work, and would likely make it more difficult to use other client-side rendering engines, so it's probably not the way to go.

[ra0e]

From my understanding there are no other options. I'd suggest to goo Mapbox GL JS too, since it is faster and future proof. However it is much more work to migrate to vector tile based rendering.

[pnorman]

The work to migrate a style to a vector tile based rendering doesn't matter here, this issue is about supporting client-side rendering on the website. Migrating OpenStreetMap Carto or changing what the OSMF hosts with tile.openstreetmap.org isn't a website issue.

[systemed]

Mapbox GL Native (i.e. in-app library for Android/iOS) has just gone closed-source. Before considering Mapbox GL JS for osm.org, we would presumably need a commitment that this is going to remain open source. /cc @mikelmaron

[mmd-osm]

OL can do vector tiles these days. IDK if they would meet all requirements for client side rendering: https://openlayers.org/en/latest/examples/mapbox-vector-tiles.html

[pnorman]

Mapbox GL Native (i.e. in-app library for Android/iOS) has just gone closed-source. Before considering Mapbox GL JS for osm.org, we would presumably need a commitment that this is going to remain open source. /cc @mikelmaron

Mapbox GL JS has gone un-open source. This excludes them from consideration here. Options which consume Mapbox GL JSON styles are still an option, as are other rendering engines.

[tomhughes]

mapbox/mapbox-gl-js#10162 is the reference for the mapbox gl reverse ferret.

[jvolker]

How about https://github.com/maplibre/maplibre-gl-js?

MapLibre GL is a community led fork derived from mapbox-gl-js prior to their switch to a non-OSS license.

[grischard]

@pnorman could this issue be re-titled "Migrate from Leaflet to maplibre-gl-js"?

[pnorman]

@pnorman could this issue be re-titled "Migrate from Leaflet to maplibre-gl-js"?

There's an implementation question there that the maintainers would need to weigh in on.

One implementation option is to completely replace Leaflet with Maplibre GL JS. This would

• presumably speed up the data layer
• minimize total data transferred if someone uses both a raster layer and a vector layer
• minimize code complexity
• require WebGL for most of the site to work
• lock us in to only client-side rendering that Maplibre GL JS supports

The other option is to use Leaflet for raster layers, and only use Maplibre GL JS for vector layers. This would

• require data layer implementations for Leaflet and Maplibre GL JS
• minimize time to map load for raster layers because Leaflet is smaller
• keep the site working for users without WebGL
• keep the option open for different client-side rendering

My preference is for the first option, mainly for code complexity reasons. The latter would require our leaflet integration, a maplibre integration, and logic to switch between them. But making this decision isn't my call, it's a maintainer decision.

[tomhughes]

Well I think we need to know the impact of requiring WebGL but my initial reaction would be that requiring it is unlikely to be possible.

I think all my machines have it enabled now but it's not that long ago that I had it disabled on some browsers.

[pnorman]

Can we quantify what portion of traffic doesn't support WebGL with piwik?

[tomhughes]

I don't believe there are are any builtin reports for that.

We could add something to the site that flagged an indicator to piwik based on whether the browser looked like it was capable?

[pnorman]

I haven't used piwik/Matomo and I don't have access, so I'm not sure what's possible. caniuse reports good webgl coverage, but as you pointed out, for various reasons, webgl might be disabled on a browser that otherwise supports it.

[tomhughes]

I know Firefox at least blacklists various features depending on the exact OS/graphics card/driver in use so it's not as simple as whether the browser in theory supports it - whether any of the effects the level of WebGL needed here I don't know.

[pnorman]

Looks like https://github.com/sgiehl/piwik-plugin-DeviceFeatureWebGL will track webgl support which will get us the data needed to make an informed decision.