This is cool. My only worry is that the implementation complexity will prevent widespread adoption outside of maplibre. Although getting write support upstreamed into PostGIS might be all thats needed to make sure it trickles down into all the different tile servers. MVT is not the most efficient, but everything speaks protobuf and you can hack together a parser in an afternoon.

I've experimented a lot with vectorized encodings of geometries in DuckDB-spatial using the different nested types. You definitely do get very good compression out of the box if you already support a bunch of specialized lightweight compression algorithms. Simpler geometric properties are very fast to compute (e.g. area, length), but for anything more complex you usually need to do some pre-processing or conversion into an intermediate data structure (like creating a line-segment index for intersection checks, or a node graph for clipping) which dominates the processing time anyway. The cost of materializing the columnar format into a row-wise format and back again when doing joins or sorting is absolutely brutal on performance too, compared to just keeping geometries as serialized blobs that are easy to slice and memcpy.

That said, I do expect columnar encoding to work really well for rendering in the browser, where transfer speed is the big bottleneck. The paper mentions Arrow as an inspiration, but I wonder why the format isn't just based on (compressed) arrow in its entirety? Im not super up to speed on the arrow ecosystem but I know there's a couple of query engines that don't just use it internally on the CPU, but also to execute on the GPU. If you are going to decode and send over the data to WebGL, you might as well do the filtering/expression evaluation there too no? (and leverage the existing techniques/code/interop in the arrow world)

This is such great news, and these are very notable speedups (decoding and filtering)! I'm looking to host our own tiles, and this would not only reduce file size but also improve performance on our maps (https://dash.hudsonshipping.co could use a speedup in loading the tiles, though we are ever grateful to OpenFreeMap). Will keep an eye out for MapLibre news regarding the JS release of this.

> A notable feature of MLT is the storage of pre-tessellated polygon meshes directly within the file. This approach allows the computationally intensive triangulation step during runtime (online tessellation), often considered a major bottleneck in modern GPU-based map rendering, to be offloaded to the tile generation phase (offline tessellation). This is accomplished by utilizing an additional IndexBuffer stream that stores the triangle indices of polygons, along with an optional Triangles stream when a complete reconstruction of the features is necessary.

Given the emergence of GPUs vector renderers like Vello and Rive, I wonder if this the best format choice for the long term?

This is interesting, is there a reference implementation that exists somewhere? Will there be a fork of tippecanoe that can encode these files or something different?

This looks nice. While I don't think tile download and decoding is a bottleneck for web maps, the efficient in-memory representation might help elsewhere as well.

Maybe someone here will know: What is MapLibre GL JS' current in-memory representation like? I know Tangram JS decodes MVT tiles to GeoJSON, but only because it showed up on a memory profiler :)

And again the “Libre” community proves that they really, really suck at naming things.

Better names for a free geospatial tile format:

* Grout

* Watershed

* TesseraTile

* Dodeca

* RandomName7

Very interested to see what improved runtime performance looks like when this is implemented in MapLibre GL JS. I thought this effort was just focused on reducing tile size (meh). I run into runtime performance issues all the time when visualizing scientific data layers in mapbox gl js. If you build a "traditional" web map portal around MVT with lots of layers people can toggle this can become an issue. Still better than other options, but I'm excited to see what a new format with tight gpu renderer support could achieve.

Is this something similar to Mapsforge map format?