MapLibre is an awesome project, their JS library is by far the best way to display maps in the browser that I've come across. Very excited to eventually switch to this format!
Looks great. I wish there was similar advancement for full 3d tiles. The only real option at the moment is cesiums 3d tiles format which is nowhere near as fast as it could/should be
I find it shocking that a reputable resource such as this is still displaying the size of Greenland or Africa wrong (Mercator projection) in relation to other land masses in its marketing material and documentation, like here. It just brings doubt to the whole project, which is a shame considering all the time they must have put in. Why show the map that way when majority of its users will never use it for nautical navigation?
https://maplibre.org/maplibre-gl-js/docs/examples/display-a-...
Another thing worth mentioning is it's very similar to the structure of columnar formats like Arrow and Parquet. Anyone with familiarity with these formats could build a decoder in a couple of days. If they don't use FastPFOR.
I really wish they hadn't used FastPFOR. It's a research library and has an incredibly opaque algorithm:
I do. The pros are hosting own data and have total control over stack and cloud hosting. The cons are having to code your own stack and do cloud management. I use PostGis to storage and serve vector tiles. And I use a simple backend with AWS S3 to store and serve raster data (GeoTiff COG).
I had to go down this path for a print-on-demand book project. If you need high-DPI assets for physical print the commercial static map APIs are prohibitively expensive or restrict usage rights for resale. Self-hosting was basically the only way to generate 300dpi rasters at scale without destroying the margins.
Have used pmtiles to self-host a “find your nearest store” map, which only needed to cover Australia. Created two sources: (1) a low-detail worldwide map to fill out the view (about 50 MB), and (2) a medium-to-high detail source for Australia only, up to zoom level 15 (about 900 MB). In this case, there’s no need for up-to-date maps, so we were able to upload these two files to S3 and forget about them. Works great!
Planetiler currently supports generating MLT by adding —-tile-format=mlt cli argument. It’s only on latest main right now but I should be able to get a release out in the next few days. In my testing I’ve seen ~10% reduction in overall OpenMapTiles archive size with default settings but there are some more optimizations the team is working on that should bring it down even further.
I <3 Martin and the team that built it. It's great to see that the Rust stack they used is the one I contributed to, now 8 years ago. Aging like fine wine!
It's cool that stuff like vector file formats is still being reinvented. What's the new idea(s) here, though?
Like, I get that it's new and has better features (better compression, faster decoding, etc.) --- but what are the new ideas or insights that led to this design?
Been following this for a little bit and am extremely excited for this. I think the final big hurdle for adoption (for those of use in the MapLibre stack at least) will be getting an equivalent As_MLT() function added to PostGIS.
25 comments
[ 3.1 ms ] story [ 48.9 ms ] threadhttps://docs.protomaps.com/pmtiles/
afaik, pmtiles uses mvt, let's hope the tooling to convert the tiles to mlt also becomes available.
In that example I saw this in the console:
So roughly a ~10% compression improvement, neat!* How this tile format, or the organization behind it, related to OpenStreetMap (if it is related at all)?
* Why the need to replace the previous tile format / scheme which they mention?
* What challenges such a project faces (other than, I suppose, being noticed and considered for adoption)?
That will leave a significant part of the community out of this transition.
See this interesting (and quite heated) discussion : https://github.com/systemed/tilemaker/issues/856
I really wish they hadn't used FastPFOR. It's a research library and has an incredibly opaque algorithm:
https://ayende.com/blog/199523-C/integer-compression-underst...
If there were something better than FastPFOR, we would use it. If something comes up, we can always use a new tag and add it in the future.
There is still a lot to do, for example one can do like-operators on FSST without decompressing it.
https://fosdem.org/2026/schedule/event/QAL9VN-state-of-the-m...
Like, I get that it's new and has better features (better compression, faster decoding, etc.) --- but what are the new ideas or insights that led to this design?
If you or your organization would like to
- sponsor (-> https://maplibre.org/sponsors) the work or
- contribute engineering time (-> https://maplibre.org/community/), we’d be happy to discuss options.
Feel free to reach out on Slack (invite at https://slack.openstreetmap.us/).