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.
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.
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.
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.
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.
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”.
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.
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.
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.
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.
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.
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.”
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.
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.
Definitely not. Any reasonable way of producing vector tiles will reduce number of features encoded into it.
For example low zoom tiles providing data for entire NA (data equivalent of
raster tile) will not contain all POI data of all shops in USA, Canada, Mexico, Portugal etc. But only general land geometry, border and maybe some selected names of countries. Maybe some extra info, but definitely not all data in OSM for that area.
Client will be able to decide to show labels or not, maybe choose one of provided languages - as all name tags are unlikely to be included (or not available at all, if this zoom level will also skip label info). Change colour of water/land/borders. But showing say supermarket presence heatmap would require making dedicated tiles. Note that geometries will be also simplified.
Without simplification and filtering it would require forwarding raw OSM data - what for several reason is pointless and will not work.
Not really, because “everything” would be a very large amount of data - there still would need to be some sort of schema that says “we’ll take X data out of OSM and store it in vector tiles as Y, and clients then show something to the user based on that Y”. See above for a.bit more of an explanation. It would, however, be possible to store more data in those vector tiles than is needed by any particular map display style, and people could then create their own map styles that display that other data.
“Having more data available to be shown” isn’t a universal positive; it means that clients have to download more data to pick and choose what they want to show. As an example, have a look here at two configurations for “tilemaker”** (some software that you can use to create vector tiles). The “example” config puts less data into the resulting vector tiles than the other one, which are then smaller and quicker to download - but obviously less data is available to be shown by the client. Now imagine a tilemaker config that tried to store everything - it’d be a bit like asking for everything louder than everything else
** lots of other vector tile software exists; I’m just linking to that because the configs are hopefully easy to understand (and test, if you fancy it).
