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 3 days ago | parent | next [-]

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 2 days ago \| parent [-]
		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 3 days ago | parent | prev [-]

More like

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

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

▲

bugsMarathon88 3 days ago | parent [-]

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

	▲	lxgr 3 days ago \| parent \| next [-]
		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 2 days ago \| parent \| prev \| next [-]
		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 2 days ago \| parent \| prev [-]
		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.