That’s in the data - if you hover the mouse over the Edinburgh Bypass here you’ll see it.
Other than ferry lines I don’t think they’re in the schema? Bus stops (and airports etc.) are though - but without a ref tag.
I don’t know how to see the refs on
https://pnorman.github.io/tilekiln-shortbread-demo/#16.73/39.453426/-1.134882
That map style (Versatiles Colorful) doesn’t seem to show them. Your options to see them on a style like that are:
- Turn debug on in the tiles, by hosting that .html file (and anything else that it expects to be local) somewhere and modifying it. Some example styles have debug in the file but commented out; I can’t remember if that one does. It wouldn’t create a “nice” website, but you would see the values.
- Copy the .json that defines the style (you can see the .html reference it), unminify it in an online json formatter, find the bit that shows street labels and add “{ref}” where there currently is “{name}”.
- If you’re really keen you can create proper highway shields - alongside the ref the length of it is also stored in the data so you can overlay a road ref over the right size shield image.
The answer is pretty much always geometry simplification. From a very quick look, there are some enormopolygons with residential or farm landuse which could potentially be made simpler with little visual effect, as here at z10. The Visvalingam-Whyatt algorithm (which tilemaker recently borrowed from tippecanoe) is great for this scenario - it’s in PostGIS as ST_SimplifyVW so could presumably be used for the OSMF tiles.
There’s also the option of merging adjacent polygons (e.g. buildings) if you don’t mind losing the dividers between them - e.g. this example in Hamburg at z14:
You can fine-tune this stuff until the cows come home, and these tiles are a WIP so I wouldn’t expect them to be perfectly optimised yet. Personally I tend to simplify pretty aggressively but that’s a cartographic choice made easy because I like uncluttered maps!
@Richard You mean also merging nearby polygons where the gaps are not really visible on the given zoom level, right?
Currently, it doesn’t look like vector.osm.org does any geometry simplification (neither merging polygons nor simplifying geometry).
The below is the boundary of Schaffhausen at the German/Swiss border on zoom level 5 or something - zoomed in while preventing MapLibre from loading any new tiles adequate for the zoomed-in map (e.g. by going offline and having no cache).
And this is how it looks at the adequate zoom level. (The line thickness is the same, it just appears thicker because those are actually micro-zigzag-lines as if drawn with a trembling hand)
1 Like
Hi there, quick question - not sure this forum thread is the right place to discuss it, or if it should happen on the shortbread repo eg on this thread Add policy and definition of what should be included in the POI layer.
I just discovered OSM vector tiles can now be consumed from a production endpoint, with client-side styling via TileJSON, which is really amazing! I wanted to spin-up a demo map similar to HistOSM - which shows POIs with filters like "amenity"~"place_of_worship|monastery" or "historic"="archaeological_site|ruins|monument|castle|city_gate" etc.
When editing the https://pnorman.github.io/tilekiln-shortbread-demo/colorful.json demo TileJSON style so:
- POIs min-zoom is reduced from 14 to eg 5
- and icon-layout size and opacity are fixed values,
Then the POIs still disappear at zoom-levels Z < 14 like if they are not included in the tile content themselves. Digging into the referenced https://vector.openstreetmap.org/shortbread_v1/tilejson.json the pois layer seem to have enforced minzoom=maxzoom=14.
Is it expected to have a single level of zoom for POI tiles? Or could the tiles produced be hierarchical and grouping POIs together - for example of they share the same subclass value, with merge at their centroid, stripping the pois metadata - at lower zoom levels like eg tippecanoe did? Thanks for your feedback!
The human readable version of the schema says that for the POI layer “All features are available on zoom level 14 only”, so this looks like the intended behaviour rather than an implementation bug.
I think the expectation is that the level 14 tiles will be ‘over-zoomed’ for most applications where you would ordinarily want e.g. zoom 18 tiles.
I’m not sure merging POIs for lower zoom levels would be particularly useful for most maps.
2 Likes
There are a few things going on here, I think.
One thing that is worth mentioning is that the maximum zoom level for vector tiles is usually 14, because even with lots of information available, the actual tile size in kb is still quite small. Data consumers such as vector map styles can, as noted above display that information at much higher zoom levels.
Another is that, as you’ve seen, if something is only written to zoom 14 tiles it’s not available in lower zoom levels. What is written to what tile is a choice made by the vector schema (here, Shortbread).
I suspect that the reason why Shortbread was chosen for these proof-of-concept tiles was that it’s a well-defined schema, and it’s relatively light - well-known keys and values are supported, but the tiles are still quite small, making it easy to manage these demo tiles.
If you want to create your own vector tiles with different information in them you can - there is a shortbread-tikemaker repository available that you can experiment with. See also this.
However, if you want to make things previously only available at high zooms to be available at low zooms too, then rhose low zoom tiles will be larger, which might be a problem
2 Likes
Thank you both for getting back with these details. Understood regarding the fact that z14 allows tiles to be lightweight enough that client application can display these POIs for zoom levels between 14 and max_zoom_level.
Also thanks for the link to generate my own vector tiles with shortbread. If I was to produce tiles for zoom levels below 14, then I would also probably aggregate features in a way that allows resulting tiles to respect a given max tile-size - where tiles would be dropped or those within a radius would be grouped - the way felt/tippecanoe does it eg here.
Just thought the fact that OSM publishes official vector tiles, it might now be faster to tile using a bottom-up approach, iteratively merging tiles from zoom levels 14 to 0.
This now seems to be getting errors:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://tiles.versatiles.org/assets/sprites/sprites@2x.json. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 404.
My guess is that Versatiles have moved things around again and both the fonts and the sprites are now elsewhere.
(for anyone wondering) the underlying OSMF vector tiles are still fine and contain all the data they ever did.
1 Like
I took some much-needed time away from everything during the holidays, and am getting back into things.
My main focus has been on reducing the work done each update. This speeds up the update frequency, which is not currently where it needs to be. Moving from the legacy osm2pgsql tile expiry to flex-based has cut in half the work that needs to be done. To get the rest of the way there, I’m splitting up the storage to store separate layers. This will take more space on-disk, but allows regeneration of only specific layers.
I’ve finished the generation part of this work and am working through the storage changes, then come the CLI changes.
These changes would allow features like server-side layer filtering, but this is not on the roadmap.
9 Likes
It seems like things have been moved, the old url gives 404 now:
glyphs: "https://tiles.versatiles.org/assets/fonts/{fontstack}/{range}.pbf"
I think changing fonts to glyphs should work.
glyphs: "https://tiles.versatiles.org/assets/glyphs/{fontstack}/{range}.pbf"
Will POIs be clickable like they are on many othar maps?
Maybe versatiles doesn’t like the rise in traffic from the demo.
I’ve made a PR.
You can make a “map” with clickable POIs out of vector tiles, yes. If that is planned for a future integration of vector tiles on openstreetmap.org I suspect nobody really knows at this point in time because I don’t believe the plans for the integration have progressed a lot. There’s a bit of a conflict there between having osm.org relatively light weight to use, and forcing everybody to download (quite large) vector tiles.
2 Likes
On osm.org you could, of course, do a round-trip - i.e. you just encode the feature type/ID in the tiles, and then clicking a POI sends a request to some server (whether it be Overpass or the tile db or whatever) to get the tags for that object type/ID. You don’t need to encode everything in the tiles themselves, as you would for something designed for offline use.
But this is an implementation detail and off the main point 
That might be OK for points but It looks to me like linestrings are being merged in the vector tiles if they are e.g. the same highway type so you’d presumably have to include all OSM ids and disambiguate somehow.
Indeed yes - clickable POIs is a simpler problem than clickable everything!
That appears to just Versatiles moving some things around.
https://map.atownsend.org.uk/vector/index_osmf_shortbread.html should work as a quick test.
Indeed - also, while “minutely updated vector tiles” would be viewed as essential by OSM mappers now, most people who “just want a map” might actually prefer a less-frequently updated one (if they checked “their patch” for errors or vandalism when the map was created, they know no problems have been introduced if it hasn’t been updated).