[kurtoid]

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

[SigmundA]

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]

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.

[stevage]

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]

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/

[SigmundA]

More like

OSM Database -> PNGs -> PNG Decoder in browser-> Your screen

vs

OSM Database -> Vector Tiles -> MaplibreGL.js -> WebGL -> Your Screen

[bugsMarathon88]

Could you please comment on any security implications of executing community-generated vector tile content, compared to classic PNG decoding?

[lxgr]

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.

[SigmundA]

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.

[fsflover]

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.

[rjh29]

SVG tiles use less data too, and can be recoloured/restyled.

[SigmundA]

Not SVG

[maelito]

> 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 :/

[orblivion]

Make sure it's set to the "Shortbread" layer. Look for the "Layers" menu on the right.

[Stephen304]

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]

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]

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.

[akdor1154]

I just tested it and it's def vector here - Firefox Android. Looks great!

[dbetteridge]

Basically that + vector tiles can store information about the tile, styles, objects or buildings etc