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)
> My only worry is that the implementation complexity will prevent widespread adoption outside of maplibre.
I don't think the implementation is that complex. You may be underestimating the extent to which heavy users of mapping data already write their own informal bug-ridden versions of the transforms and representations standardized in this tile format. In fact, it is not uncommon for companies to actually be using multiple slightly incompatible implementations of these under the hood. The practical effect could be to actually reduce the amount of code being written to do this, never mind the compatibility bugs it would address.
A key caveat is that this format is explicitly optimized for visualization. It is not optimized for efficient geospatial or spatiotemporal analytics, which may not even have visualizable output in this sense. Formats optimized for analysis make a very different set of tradeoffs.
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.
I can't see the map. It does not display neither on Firefox nor on Chrome, even with uBlock Origin disabled. Console shows "08:27:58.824 Uncaught TypeError: can't access property "Speed", hourlySpeeds[157] is undefined"
> 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?
Still needs some work on the documentation side. There will be a separate announcement when it is done. We have a newsletter that we share on all the common social networks. https://maplibre.org/news/
Aside from getting the encoding side ready so tile providers can start to make MapLibre Tiles available, we are focussed on integrating the decoder in MapLibre GL JS (MapLibre for the web) and MapLibre Native (Android, iOS and other platforms). ETA is sometime near the end of 2025.
I work as a maintainer for MapLibre, let me know if you have any other questions about the project!
Thank you for the link to the git repo, this looks great. Thank you for your work. MapLibre is a library I use all the time and while MVT isn't something I have any complaints about this will still be a big upgrade.
Thanks for your work! Out of curiosity, do you know why this project chose to go with Java as it's core? Great to see you're also supporting TS + Rust out of the gate
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 :)
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.
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)
> My only worry is that the implementation complexity will prevent widespread adoption outside of maplibre.
I don't think the implementation is that complex. You may be underestimating the extent to which heavy users of mapping data already write their own informal bug-ridden versions of the transforms and representations standardized in this tile format. In fact, it is not uncommon for companies to actually be using multiple slightly incompatible implementations of these under the hood. The practical effect could be to actually reduce the amount of code being written to do this, never mind the compatibility bugs it would address.
A key caveat is that this format is explicitly optimized for visualization. It is not optimized for efficient geospatial or spatiotemporal analytics, which may not even have visualizable output in this sense. Formats optimized for analysis make a very different set of tradeoffs.
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.
I can't see the map. It does not display neither on Firefox nor on Chrome, even with uBlock Origin disabled. Console shows "08:27:58.824 Uncaught TypeError: can't access property "Speed", hourlySpeeds[157] is undefined"
> 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?
We are finishing up the CLI for encoding tiles for public release: https://github.com/maplibre/maplibre-tile-spec/pull/504 Likely a project like Planetiler will integrate this.
Still needs some work on the documentation side. There will be a separate announcement when it is done. We have a newsletter that we share on all the common social networks. https://maplibre.org/news/
Aside from getting the encoding side ready so tile providers can start to make MapLibre Tiles available, we are focussed on integrating the decoder in MapLibre GL JS (MapLibre for the web) and MapLibre Native (Android, iOS and other platforms). ETA is sometime near the end of 2025.
I work as a maintainer for MapLibre, let me know if you have any other questions about the project!
Thank you for the link to the git repo, this looks great. Thank you for your work. MapLibre is a library I use all the time and while MVT isn't something I have any complaints about this will still be a big upgrade.
Thanks for your work! Out of curiosity, do you know why this project chose to go with Java as it's core? Great to see you're also supporting TS + Rust out of the gate
"As of January 2025, implementation has started for MapLibre GL JS and MapLibre Native." [1]
Github shows java, js, rust, and typescript folders, though I didn't poke any further beyond literally just looking at the folder names. [2]
[1] https://maplibre.org/roadmap/maplibre-tiles/
[2] https://github.com/maplibre/maplibre-tile-spec
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
It's not a "fun" name like Grout would be, but it makes up for it - I know exactly what "MapLibre Tile" is just from the name.
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?