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 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.

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

Is this something similar to Mapsforge map format?

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.