Vector Tiles are deployed on OpenStreetMap.org(blog.openstreetmap.org) |
Vector Tiles are deployed on OpenStreetMap.org(blog.openstreetmap.org) |
Mapping applications split up data into "tiles" so you can download only the data you are currently looking at. For example, you don't want to download the entire planet, just to look at your own neighborhood.
Historically, these tiles were literally images that the client application (i.e. web map) could "tile" side by side to cover the part of the map you were looking at. Now we refer to those images as "raster" tiles, to differentiate them with "vector" tiles.
Rather than a rendered image, Vector tiles contain the raw data that you could use to render such an image. Vector tiles allow a smaller file size and more flexibility. For example, with vector tiles you can crisply render at partial zoom levels, keeping lines sharp and avoid pixelating text. The client can also have customizable styles - hiding certain layers or accentuating others from the vector tiles.
Vector tiles are not new technology. For example, Google Maps started using them over a decade ago. So why has it taken so long for OpenStreetMap.org? One reason is no doubt a lack of engineering capacity. There were also concerns about older and less powerful clients hardware not being up to the task, but that concern has lessened over time.
OpenStreetMap also has some unique requirements. It is a community edited database, and users want to see their edits soon (immediately really). It's not feasible to dynamically generate every tile request from the latest data, so caching is essential. Still, to minimize the amount of time tiles will be stale, a lot of work went into being able to quickly regenerate stale tiles before the new vector tiles were rolled out.
Yeah, it really is not. Mapbox Vector Tiles spec came out in 2014, and they've been absolutely standard across all (non-government) web mapping for at least the last 5 years.
The blog post could do a better job of surfacing that bit!
You can compare it to the existing vector tile layer created by MapTiler, which mimics the classic raster tile style: https://www.openstreetmap.org/#map&layers=V
Hopefully it's vector tiles and information are there (I checked in Maputik) so it's possible to create my own style (which I will definitely try).
But that's not to diminish the accomplishment overall here for the OSM page itself– this is an awesome step forward!
- gates on private pathways
- shop namesBut mind: openstreetmap.org is ment as a developer site, for developers to see their changes quickly. The official idea is that other people should take the data and do "nice" things elsewhere. But of course reality is that users want to use openstreetmap.org as alternative to Google maps ...
I'd love to see OpenStreetMap.org be more directly useful to more people, rather than only as a "developer site".
For example the old tiles displayed rail tracks extremely prominently, which just aren't relevant 99% of the time even when traveling by train. In the vector tiles they're much more muted and thinner.
The Openstreetmap.org tiles are a demo and a contributor quality assurance tool - they are not meant for end-user applications, hence the rather over-the-top selection of map objects.
Not that Apple Maps or Google Maps are much better in this regard.
Look at the network tab on https://pmtiles.io/#url=https%3A%2F%2Fdemo-bucket.protomaps....
It's great for exploring tiles but it essentially doesn't support range queries/requests, which pmtiles does.
The prior raster tiles have the style baked in; if you want a new look, you need to generate a new image. So each map publisher ends up running their own data and server infrastructure just to tweak the style.
The vector tile approach means a single (cacheable) asset can be used in many different maps. Huge win. If you don't like the style, you can make your own without having to literally download the planet.
Providing that feedback is one of the main purposes of the site.
If you find value in it, consider donating any amount to the OpenStreetMap Foundation.
https://blog.openstreetmap.org/2024/02/11/2024-announcing-th...
https://github.com/mapbox/vector-tile-spec/tree/master/2.0
SVG is an XML based format that browsers render naitively, completely different.
Traditional process is:
OSM Database -> PNGs -> Your screen
The first arrow decides what data to pull out and how to draw it.
The new process is:
OSM Database -> Vector Tiles -> Your Screen
The first arrow decides what data to pull out. The second arrow decides how to draw it. So given your vector tiles, you can choose and tweak the style that it's drawn as, deciding how (and if) to display certain things. And you can tweak that in your browser. That's useful for devs and users. "Night Mode", "Show bike lanes" (maybe?), etc.
Also relevant is that the vector tile is not only in a couple formats (pmtiles, mbtiles) but conforms to a couple different schemas (Shortbread, OpenMapTiles) which determines what kinds of data shows up. For instance (I'm just making up this example) one schema might have "big" "medium" and "small" roads. Another schema might just have "big" and "small". The transformation process will decide which kinds of roads in the OSM database map on to which type of road in the schema. (I think it turns out that you can't realistically just pull out all of the OSM database data, you have to pare it down). And then certain styles (Americana, etc) work for specific schemas, deciding things like "big roads are black", etc.
They still are blurry, because openstreetmap.org uses a JS library that does not seem to support vector tiles :/
https://en.wikipedia.org/w/index.php?title=Vector_tiles&oldi...
The main purpose of the maps on the site is, besides showcasing some topical uses of OSM data, rapid feedback to contributors, which is something that required specific development so that can be provided with vector tiles too.
The 'late to the game' narrative seems to be a bit misplaced in any case given that OSM data has powered essentially all vector tile use outside of Google over more than a decade.
Thus, we get a built-in editor (less friction, yay/too rudimentary, boo) and popups (OSM events, yay/Popups are now everywhere, boo). And endless discussions on "this should be more/less prominent."
I don't think there's any official edict, but the approach "I don't like this and I'll make my own version" is at the very least workable (as opposed to, say, Google Maps).
> OSM Database -> PNGs
This is a tile rendering farm. It takes a lot of compute power and has to be redone every time a style changes or data changes.
> OSM Database -> Vector Tiles
This is a relatively cheap data extraction process. It has to be redone when data changes.
> PNGs -> Your screen
This is extremely simple.
> Vector Tiles -> Your Screen
This is pretty complex and hard to do fast. Mapbox GL JS is the leader here and they have put a lot of resources into doing it well and fast. Maplibre GL JS is the fork, which is decent, and there are also Leaflet and OpenLayers options.
Source: This is basically my life for the last 10 years.
I was able to implement relatively straightforward renderer in Nim language[0].
I have encountered only three hard parts:
- rendering map labels on paths (this is really hard!) - how to render labels not to be clipped by tile boundary (I had some ideas but did not implemented it yet) - collisions between labels and symbols
OSM Database -> PNGs -> PNG Decoder in browser-> Your screen
vs
OSM Database -> Vector Tiles -> MaplibreGL.js -> WebGL -> Your Screen
Does't really matter because both png or webgl are available to any website at anytime.
Edit: It also weirdly doesn't work on Chrome on Linux for me either, only Chrome on android. Oh well, hopefully they can bring support everywhere eventually.