[HN Gopher] Vector Tiles are deployed on OpenStreetMap.org
___________________________________________________________________
Vector Tiles are deployed on OpenStreetMap.org
Author : ikawe
Score : 268 points
Date : 2025-07-22 21:20 UTC (2 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.
| Stephen304 wrote:
| Hmm I tried the shortbread layer and while it looks nice
| it still pixelates when zooming in until it loads the new
| zoom level
| orblivion wrote:
| I guess you're right. I see the same on my desktop
| Firefox on Linux. But on my Android phone it's pretty
| smooth.
| Stephen304 wrote:
| It seems to just not work in Firefox for me, it's the
| same for me on FF Android but in Chrome it's beautiful!
| Constant text size while zooming and it's super smooth.
|
| 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.
| 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
| bugsMarathon88 wrote:
| Could you please comment on any security implications of
| executing community-generated vector tile content,
| compared to classic PNG decoding?
| lxgr wrote:
| I don't think anything's being executed here, in the same
| sense that both PDF (without JavaScript, at least) and
| JPEG are "data only", even though one uses vectors while
| the other only supports raster graphics.
| fsflover wrote:
| If you care about security implications of reading
| untrusted data, you may be interested in trying Qubes OS,
| which isolates apps by running everything in VMs. My
| daily driver, can't recommend it enough.
| SigmundA wrote:
| The security surface area will be either the png decoder
| or webgl, both are pretty well scrutinized but if I had
| to pick I would the png decoder is less likely to have a
| security issue compared to webgl.
|
| Does't really matter because both png or webgl are
| available to any website at anytime.
| stevage wrote:
| The enormous difference from an infrastructure standpoint
| is where the arrows are happening and how much effort it
| is.
|
| > 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.
| severak wrote:
| Rendering of Vector Tiles is not that hard as all the
| geometry is already processed, polygons assembled and
| data sorted. If you have good source of vector tiles
| renderer itself can be relatively dumb.
|
| 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
|
| [0] - https://github.com/severak/lunarender3/
| stevage wrote:
| Fun fact: I wrote a lot of that article :)
|
| https://en.wikipedia.org/w/index.php?title=Vector_tiles&oldi...
| 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
| economyballoon wrote:
| I am sorry but what is "300 Go RAM" 300 Go? I only know GB/GiB.
| farkanoid wrote:
| It's basically French for GB (Go = Gigaoctet)
| leca wrote:
| OP is probably French or his native tongue is French. Byte is
| "Octet" in French and typically you'll see Go = Gigaoctet
| which is the same as GB.
| globular-toast wrote:
| Also more technically correct as byte never "officially"
| meant 8 bits, but octet is unambiguous.
| julienfr112 wrote:
| <troll>like measuring lengths in meters</troll>
| mourner wrote:
| Also worth checking out
| https://github.com/onthegomap/planetiler, which maybe a bit
| less mature, but is much faster than Tilemaker.
| maelito wrote:
| Is it ? The benchmark section says 42 m for a 128 Gb machine
| with 64 CPU.
| 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/
| tppiotrowski wrote:
| I think mbtiles are being phased out for pmtiles because no DB
| required and can be served from static storage like R2/S3 (with
| a worker but hopefully the worker part goes away and they
| support byte offset requests soon)
| stevage wrote:
| You don't need a database to serve mbtiles. If you're
| deploying PMTiles somewhere that doesn't support byte offset
| requests, then they don't really have much advantage over
| mbtiles.
| jamessb wrote:
| That depends what you mean by needing a database. MBtiles
| files are SQLite database files, so you need a SQLite
| process running somewhere to extract the requested tiles.
| jtbaker wrote:
| The worker isn't required, having a z/x/y tile scheme just
| makes caching the tiles server side super easy.
|
| Look at the network tab on
| https://pmtiles.io/#url=https%3A%2F%2Fdemo-
| bucket.protomaps....
| sureglymop wrote:
| An mbtiles file is just an SQLite db which can store image or
| vector tiles which can be very useful.
|
| It's great for exploring tiles but it essentially doesn't
| support range queries/requests, which pmtiles does.
| sp8962 wrote:
| To answer the question: somebody needs to do the initial work
| and it's a further moving part that needs to be kept running
| (as the other responses point out such a distribution would
| likely use PMTiles as a container format). Given the current
| finances and staffing of the OSMF likely not top priority.
| colkassad wrote:
| But they've done the work and are serving them now, just
| wondering why they don't just dump a copy on AWS. Thanks for
| answering!
| 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.
| stevage wrote:
| >Vector tiles are not new technology.
|
| 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.
| gregoriol wrote:
| Indeed almost everyone except Apple's MapKit library for in-
| app native maps integration is using vector these days.
| hopelite wrote:
| Could you explain why you say that? My understanding is
| that rasterized tiles are only a graceful degradation when
| necessary in MapKit, while vector is default, as the
| behavior and experience would indicate.
| showcaseearth wrote:
| +1. Google launched their (proprietary) vector tiles in 2013
| as well, and I'd even argue that vector has been the standard
| well over 5 years now.
| awkward wrote:
| Tiles aren't just about data selection, they're also about
| caching. By turning a continuous domain (any part of the world
| at any scale) into a series of discrete requests (a grid of
| tiles at several fixed scales), maps become a series of
| cacheable requests.
| stevage wrote:
| For anyone who wants to actually try the new layer, it's called
| "Shortbread" and can be accessed under the layers selector. Or
| use this link: https://www.openstreetmap.org/#map&layers=S
|
| 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
| dolmen wrote:
| Many important details are not visible anymore: -
| gates on private pathways - shop names
| lutoma wrote:
| Personally I'm quite happy that these tiles cut down on the
| clutter in the original OSM tiles. It made it very hard for me
| to actually use them for navigation because there was just so
| much stuff everywhere.
|
| 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.
| timeon wrote:
| Yes but this one only highlights motorways which are used
| usually just for long distance drives.
| wiredfool wrote:
| The nice thing is, that's just a style, not a property of
| the tiles. So if you want to alter the rendering, it's
| "just" a change to the style of that layer/attribute.
| johannes1234321 wrote:
| The choices are tough, also in details: Which shops to show in
| busy areas at which zoom level?
|
| But 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 ...
| notachatbot123 wrote:
| All the more reason to show rather more than less data.
| ikawe wrote:
| Official? I've never heard this as official doctrine. Can you
| point me to anything official?
|
| I'd love to see OpenStreetMap.org be more directly useful to
| more people, rather than only as a "developer site".
| severak_cz wrote:
| Oh but that default style for Shortbread is so ugly! No contrast,
| missing details and lots of information lost.
|
| 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).
| MapNavTom wrote:
| There is also the MapTiler OMT style for OpenMapTiles, which
| uses Vector Tiles. It is a close copy of the Standard OSM map
| style. It appeared at the same time as Shortbread on the
| osm.org website.
| reddalo wrote:
| I agree, it's super close to the classical OSM style, but
| some things are missing, e.g. roads that are currently
| planned or in the building phase.
| MapNavTom wrote:
| Yes, buildings under construction aren't there yet either.
| OMT is OpenSource though, so you can make a pull request:
| https://github.com/openmaptiles/openmaptiles
| severak_cz wrote:
| Yeah. MapTiler has much better styles in general.
| timeon wrote:
| Yeah only motorways are highlighted everything else is faded in
| background.
| showcaseearth wrote:
| The lack of boundaries below national level is off-putting.
| Both the style and the tile spec itself seem to need a lot of
| refinement... highways look like a patchwork at low zoom. I had
| also thought shortbread excluded a lot of POI types, but maybe
| I need to review again.
|
| But that's not to diminish the accomplishment overall here for
| the OSM page itself- this is an awesome step forward!
| wiredfool wrote:
| OSM has always overdone boundaries in my opinion, the raster
| tiles show national/international waters and electoral
| districts, which are of limited use for most purposes.
| wiz21c wrote:
| does a vector tile use more or less memory than a raster tile ? I
| mean, on average, in OSM.
| amluto wrote:
| What happened to maps trying to make the names of most or all
| streets visible? It looks like the vector layer on the web viewer
| is sort of trying to show some street names, but it seems
| extremely buggy right now -- names appear and then disappear
| again when making small zoom adjustments.
|
| Not that Apple Maps or Google Maps are much better in this
| regard.
| neomantra wrote:
| This comment is a reminder that OSM Vector Tiles is sponsored
| work. It is exciting to see the deployment of it -- congrats to
| the team!
|
| If you find value in it, consider donating any amount to the
| OpenStreetMap Foundation.
|
| https://blog.openstreetmap.org/2024/02/11/2024-announcing-th...
| butz wrote:
| While vector tiles are often marketed as faster loading ones, and
| it is true in OSM case, I would like to see apples to apples
| comparison: vector tiles with same level of detail as original
| OSM raster tiles. Maybe someone already has such vector style
| built?
| perrygeo wrote:
| To everyone with complaints about the new "Shortbread" styling, I
| agree that it's not perfect but that's kinda missing the point.
| The real story is that vector tiles have the styling applied
| client-side so anyone can tweak the look with a little
| javascript.
|
| 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.
___________________________________________________________________
(page generated 2025-07-24 23:02 UTC)