←back to thread

OpenStreetMap's New Vector Tiles

(tech.marksblogg.com)
497 points marklit | 4 comments | 19 Nov 24 12:03 UTC | HN request time: 0.813s | source
Show context
zawaideh ◴[19 Nov 24 15:27 UTC] No.42184496[source]▶
The other issue is that the arabic font is not rendering correctly in the vector version. It's rendering left to right (instead of right to left) with characters broken up instead of linked.
replies(3): >>42185056 #>>42185301 #>>42190246 #
sp8962 ◴[19 Nov 24 16:13 UTC] No.42185056[source]▶
The whole point of vector tiles is that the rendering is local and controlled by a style configuration (except for the tile schema) that can be changed. So the brokenness you are seeing is either in the style or the library that is rendering the contents locally.
replies(2): >>42185076 #>>42185878 #
SSLy ◴[19 Nov 24 16:15 UTC] No.42185076[source]▶
Indeed, but that is probably not going to help end users of apps.
replies(1): >>42185643 #
sp8962 ◴[19 Nov 24 17:04 UTC] No.42185643[source]▶
Well nobody claimed things are going to get simpler.

It is difficult to beat raster tiles in that respect. vector tiles split up responsibility for what you get visually over multiple moving pieces with different provenance and operators.

replies(2): >>42185815 #>>42186040 #
lxgr ◴[19 Nov 24 17:16 UTC] No.42185815[source]▶
> It is difficult to beat raster tiles in that respect.

Intuitively, why can't the local vector rasterizer do whatever the server-side tile rasterizer does, especially if both are fully custom?

replies(2): >>42185854 #>>42185938 #
1. wiredfool ◴[19 Nov 24 17:19 UTC] No.42185854[source]▶
Partially because they're completely different stacks -- the client side is WebGL + Javascript, and the server side is whatever they've been doing for 15 years.

They're probably missing a raqm/freebidi or something in the stack on the client side.

replies(1): >>42186266 #
2. lxgr ◴[19 Nov 24 17:52 UTC] No.42186266[source]▶
Ah, so the input into the client-side isn't OSM-like data (i.e. OSM XML or some high-level transform of that), but rather something closer to a vector graphics format like SVG?

That makes sense then, thank you!

replies(1): >>42186959 #
3. wiredfool ◴[19 Nov 24 19:04 UTC] No.42186959[source]▶
It's a mapbox mvt, which is protobuf. It contains the OSM data (obviously), but it's a specific format that's in wide use (mapbox-gl, maplibre, and many other open source versions). There are similar versions in pmtiles, which is basically the same thing in a http range friendly big single file which can be hosted on S3-like storage and used directly.

The difficulty is that the stack for rendering vector tiles in the browser is different than the legacy vector->png generation that's been done for ages.

replies(1): >>42187426 #
4. sp8962 ◴[19 Nov 24 19:55 UTC] No.42187426{3}[source]▶
> It contains the OSM data (obviously) ...

Not really. You need to build geometries from raw OSM data (aka the stuff that you edit) then transform those geometries into MVT format adding appropriate attributes from the original data. In general you actually will want to normalize the data and throw out anything that is not included in the vector tile schema you are using. The net result is quite far from raw OSM data in any case.

PS: I maintain a project that stores actual OSM data in MBTiles format for offline editing, and yes proper editing apps have to do the above on the fly and it is the main reason they are not lightning fast.