| ▲ | sp8962 7 days ago |
| 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. |
|
| ▲ | lxgr 7 days ago | parent | next [-] |
| > 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? |
| |
| ▲ | wiredfool 7 days ago | parent | next [-] | | 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. | | |
| ▲ | lxgr 7 days ago | parent [-] | | 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! | | |
| ▲ | wiredfool 7 days ago | parent [-] | | 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. | | |
| ▲ | sp8962 7 days ago | parent [-] | | > 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. |
|
|
| |
| ▲ | maxerickson 7 days ago | parent | prev [-] | | It can, it's just that they typically don't, because they use an off the shelf data schema for the tiles and a library to handle the rendering. Having the data in tiles also complicates some things (where the renderer needs to consider merged tiles to get a similar result). |
|
|
| ▲ | astrange 7 days ago | parent | prev [-] |
| For Arabic specifically, different users want text to render differently, so you'd want to do it on the client if you can. (Some countries use Roman numerals and some use Arabic numerals for numbers. And by Arabic numerals I don't mean 1-9.) |
| |
| ▲ | rafram 7 days ago | parent [-] | | All Arabic-speaking countries use Arabic numerals. Some use Western Arabic numerals (123) and some use Eastern Arabic numerals (١٢٣). Roman numerals are I, V, X, etc. | | |
|
