[HN Gopher] Vector Tiles are deployed on OpenStreetMap.org
___________________________________________________________________
Vector Tiles are deployed on OpenStreetMap.org
Author : ikawe
Score : 52 points
Date : 2025-07-22 21:20 UTC (1 days ago)
(HTM) web link (blog.openstreetmap.org)
(TXT) w3m dump (blog.openstreetmap.org)
| eulgro wrote:
| I had no idea what vector tiles were and the page doesn't explain
| it.
|
| https://en.wikipedia.org/wiki/Vector_tiles
| kurtoid wrote:
| 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
| rjh29 wrote:
| SVG tiles use less data too, and can be recoloured/restyled.
| SigmundA wrote:
| Not SVG
| dbetteridge wrote:
| Basically that + vector tiles can store information about the
| tile, styles, objects or buildings etc
| maelito wrote:
| > 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 wrote:
| I just tested it and it's def vector here - Firefox
| Android. Looks great!
| orblivion wrote:
| Make sure it's set to the "Shortbread" layer. Look for the
| "Layers" menu on the right.
| SigmundA wrote:
| 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.
|
| 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
| orblivion wrote:
| 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 wrote:
| More like
|
| OSM Database -> PNGs -> PNG Decoder in browser-> Your
| screen
|
| vs
|
| OSM Database -> Vector Tiles -> MaplibreGL.js -> WebGL ->
| Your Screen
| davidkwast wrote:
| Nice. I already use Vector Tiles on my backend. But it is nice to
| have other sources like this.
| maxerickson wrote:
| 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.
| maelito wrote:
| 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
|
| https://github.com/systemed/tilemaker/issues/839
| colkassad wrote:
| What's the impediment to not providing daily or weekly planet-
| wide mbtiles similar to the availability of OSM pbfs on AWS open
| data buckets[1]?
|
| [1] https://registry.opendata.aws/osm/
| ikawe wrote:
| Background:
|
| 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.
___________________________________________________________________
(page generated 2025-07-23 23:00 UTC)