First of all, thank you for making this happen! This is one of the most significant developments in the history of OSM I believe.
Moreover, as someone who dig deep into the situation of schemas/styles (I made https://openfreemap.org/), I believe this will give the much needed push for a post-OpenMapTiles ecosystem, finally based on a real open-source license.
The OpenMapTiles / MapTiler “hidden-fork” situation is really not nice. MapTiler has been deviating more and more from the OMT repo, which is in a very abandoned state. No one wants to invest in it, because of the license.
Currently, both Shortbread and Versa needs a lot of work to be on feature parity with the mature OpenMapTiles ecosystem, but I believe OSM.org embracing it will give that push.
I’d personally like to have OpenFreeMap one day be based on Shortbread + Versa, finally embracing a truly open-source, community led vector tile ecosystem.
Having said that, the big question is where will this coordination happen. Also, OSM should really clarify the situation of using Versa styles on OSM.org in my opinion. Currently I made a JSON compare and only the paths are changed, everything else is identical at the moment. Also confirmed here.
But at one point OSM might deviate/fork Versa as OSM users might want different use cases compared to “vanilla” Versa.
I mean where will the development of Versa + tightly coupled Shortbread happen in the future?
In Versa? In Shortbread? In GitHub - openstreetmap/vectortile-website?
OSM embracing Shortbread + Versa is an amazing development.
There should be a place where tightly coupled Shortbread + Versa development can happen. One repo, one team, one place to open issues and discuss them.
The website’s vector layer support is also designed to accommodate additional styles. For example, the current Shortbread layer’s tile configuration lives in a repository that also contains a partially completed style called Street Spirit that has been proposed for further development.
In general, you can usually report a bug in the issue tracker for a style and let developers figure out which component is actually responsible for the problem. Ultimately the style is responsible for deciding what to display from the tiles and the renderer is responsible for faithfully rendering the style.
That issue was a wrong example as it had nothing to do with Versa (I should have known that before posting), but there’ll be a lot of issues along the way.
I mean the low zoom levels are totally missing from Shortbread and Versa.
I mean it’ll be a tremendous amount of work until they’ll get on feature parity. And Versa cannot fix it on it’s own, as the data is simply missing from Shortbread.
Maybe this work will be done inside Sprit. Maybe somewhere else?
What I’m trying to say isn’t that anything is wrong or there is any kind of issue, I’m just emphasising the need to have a central repo which is basically a forked Shortbread + forked Versa which will develop together, hand-in-hand.
maybe they only wanted to include data from OSM in the vector tiles? In Carto there is a lot of natural earth data (low zoom cities and built up areas for instance), and it seems these are missing currently in shortbread.
But this is not the reason why low-zoom details are missing, it’s simply OSM data missing / not being displayed.
Also, I can imagine this as one point where OSM might want to deviate from other vector tile projects, as OSM might want to require to only display 100% OSM sourced vector data. I don’t know how is it done in raster Carto.
TBD I guess. Getting Shortbread to parity with OSM Carto will be a tremendous amount of effort, but OpenMapTiles would need a lot of attention too. Designing a one-size-fits-all tile schema is a monumental task, especially considering vector-specific performance tradeoffs. With so many forks and production deployments, OpenMapTiles doesn’t have as much room to experiment and address technical debt as something newer like Shortbread. At the same time, configuration-driven tile generators like Tilekiln, Tegola, and Planetiler make custom tilesets more practical, reducing the need for a general-purpose tileset to supply everything a style needs. (A style can combine multiple tilesets.) The rest of the Spirit repository shows what it could look like to combine schema and style development in one place.
Yes, one of the things that held up the MapTiler OMT layer was that MapTiler’s tileset sources place names from both Wikidata and OSM. This is the default behavior of OpenMapTiles tooling, which they offer to all their customers for a better end user experience.
The concern was that, as the initial showcase for map label localization on the OSM website, this Wikidata usage could end up confusing mappers. They’d see a place name that maybe doesn’t conform to map labeling conventions, but it would be nowhere in the OSM database. In general the use of an external dataset doesn’t prevent us from featuring a style on the site, but the potential for user confusion is a major consideration. After all, look how much confusion we’ve seen in this thread as it is!
Ultimately, MapTiler ended up disabling the Wikidata fallback – hopefully only for our website, not for all their customers just because of osm.org’s very particular use case. Other OSM-based maps still pull in Wikidata labels. For example, OSM Americana falls back to the Wikidata label if the OSM feature lacks a name:*=* tag in the selected language. But it gets away with this approach because the name=*appears underneath if it differs from the main label, for a little more user transparency.
We’re using two VersaTiles styles on osm.org. If someone had an alternative style that uses Shortbread tiles we could consider it. It’s fairly easy to change the style - that’s the point of vector tiles.
There seems to be some confusion here. Shortbread is not tightly coupled to any one style. Given it’s purpose, it can’t be tightly coupled to any one style.
The VersaTiles styles and Shortbread have a different goal and purpose than OpenStreetMap Carto. Even if they had the same goals, there are different ways to make a map that reaches those goals. There’s no reason to expect the two maps to look the same. Do apples and oranges have feature parity?
[quote=“zsero, post:43, topic:133008”]
I’m just emphasising the need to have a central repo which is basically a forked Shortbread[/quote]
There are no plans to fork Shortbread. The goal is to use a common standard.
If the aim is to have a map which looks visually just as pleasing as the maps in the OMT ecosystem, there needs to be a lot of work both on Shortbread and Versa. The emphasis being on Shortbread. It needs a lot of work. OpenMapTiles has 1300 commits on GitHub. And probably just as much on the non-public repos of MapTiler. This is how much work a map schema needs. It’s constantly being worked on, the styles + the schema is constantly being tuned together to create a nice visual style.
In companies like Mapbox and MapTiler I’m sure the cartographers and schema developers work hand-in-hand in aligning those repos.
Meanwhile Shortbread is basically a single “1.0.md” file. It received 7 commits in 2025 so far, 3 of them from you personally.
Maybe I don’t quite understand the long term aim of Shortbread. Isn’t it to finally be an open-source alternative OpenMapTiles?
I have more of an infrastructure or javascript issue. I often find myself on a map like this until at some point seconds later all tiles render. I think something is blocking the rendering.
I am in Switzerland on 10gbits internet on a beefy new Mac Studio on the latest Firefox Nightly on a 4K screen. There should be really no bottleneck.
When this happens, can you try zooming in and back out? If that fixes the rendering, you might be seeing an elusive bug in the maplibre-gl-leaflet plugin, one more reason to migrate away from it. (OpenHistoricalMap has used this plugin for several years as a compatibility shim; this is a fairly frequent issue there.)
In Firefox HAD picture with these 2 new layers but since about 2-3 days, just blank both in regular and dark theme. All other Org.osm layers show fine,
Testing in Chrome can see the layers so it must be something starting to not like Firefox.
