Serving Vector tile styles

[pnorman]

Currently the osm.org shortbread layer uses a style hosted on vector.osm.org, but we've made no commitments to hosting the style at that URL in the long term. It is useful to have some style on vector.osm.org for a demo page.

I see four options going forward

1. The status quo, where we host https://vector.openstreetmap.org/demo/shortbread/colorful.json and related assets with CORS headers that allow cross-site usage but don't publish it or commit to hosting a style at that URL.
2. Host colorful.json and assets but use CORS headers to restrict its usage to OSM domains
3. Have openstreetmap-website generate the style JSON but still rely on vector.osm.org for other assets.
4. Commit to publishing a style + assets with CORS headers that allow cross-site usage

I do not consider it practical to have all assets generated in openstreetmap-website. The fontstack and sprite sheets are difficult to generate and require unusual dependencies.

I want to avoid any situations like we have right now with OpenLayers, where we're locked in to hosting a publicly used file that we don't need.

[1ec5]

Do we expect these styles to deviate from the original VersaTiles styles (beyond the mechanics of resource URLs)? If not, should we clarify that our hosted copy of the stylesheet is just an implementation detail and point developers to a more canonical location hosted by VersaTiles?

[pnorman]

Do we expect these styles to deviate from the original VersaTiles styles (beyond the mechanics of resource URLs)?

No. They might lag a version behind at times.

Do we expect these styles to deviate from the original VersaTiles styles (beyond the mechanics of resource URLs)? If not, should we clarify that our hosted copy of the stylesheet is just an implantation detail and point developers to a more canonical location hosted by VersaTiles?

Out of the box Versatiles loads from their demo server for both the tiles and other resources. I think the resource part is more difficult to deal with.

[1ec5]

I do not consider it practical to have all assets generated in openstreetmap-website. The fontstack and sprite sheets are difficult to generate and require unusual dependencies.

The next version of MapLibre GL JS will relax the requirement for server-side fonts and add support for the same kind of fonts that ordinary webpage content uses: maplibre/maplibre-gl-js#4564. Depending on design decisions, it opens up the possibility that Versatiles would no longer require a complicated build step or a large prebuilt file for font glyphs. If so, then osm.org would no longer need to deploy any glyph PBFs at all, and we could resolve half of openstreetmap/vectortile-website#12 by removing that particular relative path altogether.

Unfortunately, opting into the local font mechanism (by removing glyphs from the stylesheet) would make the style incompatible with MapLibre Native for the time being: maplibre/maplibre-native#165. Conversely, MapLibre Native has a similar feature that’s mutually incompatible with GL JS, but a fix is coming soon: maplibre/maplibre-style-spec#1350.

[pnorman]

Unfortunately, opting into the local font mechanism (by removing glyphs from the stylesheet) would make the style incompatible with MapLibre Native for the time being: maplibre/maplibre-native#165.

I'm okay breaking native support until it's on par. I'm also not sure if versatiles colorful works on native or if it relies on properties only supported in GL. Apps deploying should not be pointing at our demo URLs

The big question is still the policy one

[pnorman]

Per discussion at today's ops meeting the plan is

Host colorful.json and assets but use CORS headers to restrict its usage to OSM domains