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.
maelito 12 hours ago [-]
In case you wonder how much time / resources it takes to generate vector tiles, I'm running benchmarks with Tilemaker here for https://cartes.app
Nice. I already use Vector Tiles on my backend. But it is nice to have other sources like this.
maxerickson 22 hours ago [-]
A feature goal for this deployment was that the tiles would update continuously, keeping up with changes that people are making to the OpenStreetMap database.
Providing that feedback is one of the main purposes of the site.
eulgro 1 days ago [-]
I had no idea what vector tiles were and the page doesn't explain it.
Here's how I understand it: Previously, OpenStreetMap's tile endpoints would serve pre-rasterized PNG images, so zooming in on a tile could cause it to get blurry, until your client requests a new, zoomed in tile. Now, they can serve tiles in SVG format, which scale better
orblivion 27 minutes ago [-]
Someone please correct me if I'm wrong here, but I think there's an additional benefit.
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.
SigmundA 24 minutes ago [-]
More like
OSM Database -> PNGs -> PNG Decoder in browser-> Your screen
vs
OSM Database -> Vector Tiles -> MaplibreGL.js -> WebGL -> Your Screen
maelito 12 hours ago [-]
> so zooming in on a tile could cause it to get blurry, until your client requests a new, zoomed in tile. Now, they can serve tiles in SVG format, which scale better
They still are blurry, because openstreetmap.org uses a JS library that does not seem to support vector tiles :/
akdor1154 47 minutes ago [-]
I just tested it and it's def vector here - Firefox Android.
Looks great!
rjh29 23 hours ago [-]
SVG tiles use less data too, and can be recoloured/restyled.
SigmundA 33 minutes ago [-]
Not SVG
SigmundA 35 minutes ago [-]
Not SVG, its Mapbox Vector tile format which is like Geojson coded in protobuf it is then rendered to raster in the browser using webgl typically.
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.
https://github.com/systemed/tilemaker/issues/839
[1] https://registry.opendata.aws/osm/
Providing that feedback is one of the main purposes of the site.
https://en.wikipedia.org/wiki/Vector_tiles
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.
OSM Database -> PNGs -> PNG Decoder in browser-> Your screen
vs
OSM Database -> Vector Tiles -> MaplibreGL.js -> WebGL -> Your Screen
They still are blurry, because openstreetmap.org uses a JS library that does not seem to support vector tiles :/
https://github.com/mapbox/vector-tile-spec/tree/master/2.0
SVG is an XML based format that browsers render naitively, completely different.
https://en.wikipedia.org/wiki/SVG