And it is very generous from you to do so. Your style looks good. But I was envisioning something on the osm.org site with the same “demo” purpose as the default style.
Latest (from about a moth ago) that I know about is from this PR: Add OpenMapTiles vector map by zdila · Pull Request #4042 · openstreetmap/openstreetmap-website · GitHub
2 Likes
Thanks. The thread was interresting but is there any actual intention to host it or is it still just a wish shared by many?
(Brian’s opinion)
The problem I see is that hosting the same style as the standard tile layer, except in vector format, isn’t particularly useful to anyone. What does it do for anyone exactly? First, the proposed style is the OpenMapTiles style, which is an incomplete implementation of the features of the standard tile layer. I mean, it’s close, but there are noticeable variations. Hosting a feature-incomplete map as vector tile technology’s signature showpiece is not a great look.
Further, the interesting things about vector tiles are the ability to make style decisions in the user’s web browser, such as changing the language on the fly. However, that PR doesn’t propose adding any interesting vector features - it’s just the (almost) same style in vector format.
The other proposed rationale for vector tiles is to “jump-start community vector tile projects” by having a centrally-hosted server that anyone can use for that development. However, as I’ve highlighted in standing up the community vector tile server, hosting a tile server is no longer a barrier to entry. I’ve posted my recipe for hosting a tile server for less than $20 a month, which at this point is already horribly out of date (less than $5 a month is now realistic). Also, a centralized vector tile server is fairly inefficient unless it is customized to serve the features and attributes that a style is actually using.
So for these reasons, I no longer see the point of osm.org hosting a general-purpose vector tile server, and a vector tile style will show up as soon as some community project becomes mature enough to justify and apply to become a featured layer.
I am happy to be proven wrong about all of this.
4 Likes
MapTiler’s OpenMapTiles pull request does install a library that changes the label language based on the language setting in user preferences. This functionality would be a useful addition to the site by helping mappers detect missing or incorrect translations, at least for the languages that would be hard-coded. However, it doesn’t sound like language support would be the principal motivation for introducing client-side style rendering in this pull request. After all, a lot of the feedback relates to gaps in language support, which the author doesn’t seem to consider a showstopper.
Maybe MapTiler recognizes that, for many of the people who have been clamoring for vector tiles on osm.org, client-side rendering would be an ego boost for the project, proof that, yes, OSM data can power a modern map too! I would challenge this notion a bit: a layperson or casual mapper who visits the site wouldn’t know the difference between a raster map and a vector map (other than a performance hit). This especially the case because MapLibre GL JS would be squeezed through a compatibility layer for Leaflet that can’t even zoom smoothly between zoom levels.
If we want to impress others and ourselves with vector maps, the map has to do more than just render in the same manner that a raster map would. For example, OpenHistoricalMap has taken the osm.org code, applied the same technique that MapTiler has proposed, and gone even further by dynamically filtering the data based on the time period the user wants to focus on. Imagine if osm.org could filter the map thematically, based on real layers like “roads”, “railroads”, and “waterways”. This is trivial with client-side map rendering.
And when we’re done impressing ourselves, maybe we can turn our attention to using vector tiles to power something a raster map truly can’t: an X-ray view that lists all the raw tags immediately when you hover over a feature. Brian’s tile server has just such a style installed. I use it all the time when developing a style based on the tiles, and I would be thrilled to use it instead of having to hop into iD just to inspect the tags on some busway or craft workshop.
In the meantime, vector styles based on vector tiles are already on osm.org – on wiki.osm.org, that is. 
4 Likes
I belive that the customization of the name language and the ability to choose precisely the zoom levels should be valid enough reasons to continue to advocate in that direction. The OSM.org is a “poster” for the project and having something a bit polished doesn’t sound to be asking for bling as I see it.
3 Likes
It is useful for me. It implements a newer-than-1990s technology stack, which allows me to use it instead of the old and wasteful one.
Yes. What seems obvious to me, is that to implement advanced vector features, firstly basic vector support should be implemented. Only then extra things should be added, preferably one by one, in small, incremental upgrades.
“No, let’s rather not do anything until we can get everything-but-a-kitchen sink implemented in one huge lump” is IMHO not a very good strategy. Better to start small(er) and simple(r), kink out problems there, and then grow up.
Also, to be fair, languages-related features are intended to be improved on, just not in that initial PR, see e.g. this comment.
2 Likes
No argument there. But what this PR implements is more like converting a vector map into a Leaflet-compatible raster map, just on the client side instead of on the server side. So eventually there will need to be a step backwards in order to advance further.
Of course, perfect shouldn’t be the enemy of the good. But we shouldn’t make this PR out to be more than it is: a baby step. As a workalike, client-side style that uses third-party tiles, it hardly relates to the discussions about vector tile schemas and distribution that have consumed discussions around vector maps both here and on GitHub. I think it’s fair to look back at the last five years in light of this PR and wonder, “What was that all about?”
If, practically speaking, the only remarkable thing about “OpenMapTiles” beyond MapLibre’s getting started guide is that it installs mapbox-gl-language – something I wholeheartedly support – then at least it could be configured with the same languages that the real OpenMapTiles supports. The fact that it’s already outdated doesn’t reflect well on the maintenance strategy for this feature. And if the suggested minor changes must be deferred as tail work, then it also doesn’t bode well for the more substantial issues surrounding the proposal, such as confusion about Wikidata, that could conceivably entail changes to MapTiler’s server-side configuration.
2 Likes
While a vector tile based system with client side rendering surely would be welcome as an addition and would offer a lot of opportunities, it shouldn’t replace the raster tiles IMHO. Vector tiles require a GL capable client and more resources to display. It would exclude people with old hardware or on weak systems (settop boxes etc.) from seeing the map. Raster tiles also offer the possibility to have a high information density while still being relatively small. Opposed to this, vector tiles either require filtering, precomputation (e.g. of “ranks” (order) or centroids) and simplification (and as a result become less versatile and more focused on a specific style) or become quite “heavy”.
3 Likes
OpenMapTiles literally does all of these things, as does any modern vector tile map. There are limitations of the maplibre-gl-js stack for sure, but this isn’t one of them.
1 Like
I know that this is all done, what I wanted to hint at: you will not be as flexible as the word “vector tile” might sound, because you typically don’t simply get the original osm data, you get a transformed version that is adapted to a certain style or class of styles. If you wanted to show railways at zoom 5 you cannot with https://tile.ourmap.us/ (as an example, it’s not a critique) because they are not there, but motorways are. These are all decisions that make the whole thing feasible but also lead to new constrictions.
You also cannot generate “generic” vector tiles with all data included in all zoom levels, naturally, or you would end up in the zoom0 tile to contain the whole planet and tens of gigabytes.
More flexibility could be achieved by creating different (thematic) layers of vectortiles, and merge them on the server or send them individually, according to the style requirements.
2 Likes
And nobody is proposing to do this. The OWG discussions I’m aware of centered around whether to host OpenMapTiles, geofabrik’s ShortBread, or some other community schema to be invented. If a style wanted to use some data that wasn’t in a hypothetical OSMF-hosted vector server, at that point they’d have to run their own server that’s customized to serve the data that they care about.
But to your point, hosting a generic tile server where every style gets the same data whether they need it or not is fundamentally inefficient compared to an equivalent raster, unless that vector schema is specifically tailored to what the client style actually uses.
That said, the proposed OpenMapTiles style doesn’t really suffer from these criticisms because the style is intended to show off the data that’s in OpenMapTiles. The one exception is language information, which is encoded in the tiles whether the client chooses to display them or not.
Maybe as a kind of inspiration for our vector tile effort,
I want to mention the online solutiom by a company named Mapilion (placed in Stuttgart/Germany) …
see https://mapilion.com/
Scroll down to see their implementation, and also try to drag the map example while holding Ctrl key on desktop computers
So far, this company is not mentioned in any way in the OSM wiki, this is a surprise for me.
Maybe this topic can have some benefits from that implementation? Or not?
If you’re referring to tilting the map, yes, this is something that most vector map libraries support, including MapLibre GL JS. Technically even a raster map can be tilted, but all that means is that the image gets skewed (just like in an image editor), which isn’t very useful. The advantage of a vector map is that the labels can stay “billboarded” onto the screen to maintain legibility, not to mention the possibility of 3D buildings and such.
Unfortunately, this PR takes the approach of shoehorning MapLibre GL JS into Leaflet, a raster library that doesn’t support 2.5D/3D features like tilting. Originally, it included a link advertising a 3D terrain map by MapTiler, but it was removed by request.
1 Like
Both raster and vector tiles require filtering, ordering, and simplification. This is done in different ways depending on the stack, with raster tiles, server-side vector tiles, and client-side vector tiles all subject to different constraints.
You also can’t generate generic raster tiles with all data on all zoom levels - this is not a new constriction.
2 Likes
oh yes, you could render a raster tile with all data and no filtering or simplification, the end result would be a raster tile 256px (or whatever) and easily consumable by almost any device with a screen. It wouldn’t probably make a lot of sense. With raster tiles you don’t have to compromise (or much less) geometric detail and tile size, as you said: “subject to different constraints.”
1 Like
The rendering is itself a filtering and simplification step, just one which is harder to control. With raster tiles you do have to compromise on detail - they tend to be lower DPI than vector tiles, so this overwhelms any other simplifications. The developer of a client-side rendered style has to worry about tile size, but if the style is a good one, the user doesn’t.
1 Like
… An utter mess?
Actually, not even that - at low zoom levels you simply don’t have enough pixels on a raster tile to show everything. Look at taginfo for any reasonably large area, and you’ll see that there are more tags than pixels on a raster tile.
1 Like
Bumping the thread given that 2024 is the year of vector tiles: 2024: announcing the year of the OpenStreetMap vector maps | OpenStreetMap Blog
12 Likes
Fantastic news! I am looking forward!