Note that the demotiles style is not really comparable to a production basemap such as ones based on the popular OpenMapTiles schema. The article linked in the announcement has some more findings related to compression ratio.
Also note that lightweight encodings are built into the format, and different tiles can even be encoded in a completely different way. So you have to use heuristics to find the best combination of encodings and often you need to make a trade off between tile size and decoding performance. It is still early days for MLT, but all this means there are a lot of possibilities for optimization. In fact, AWS is again financing work on MLT this year, with a focus on optimization.
Lastly, when benchmarking tile size, it is good to look at actual usage patterns instead of size of the total tile set. Nobody is zooming into a random spot in the ocean, for example. ;-)
PMTiles is actually pretty agnostic to what kind of tiles it contains! There is already a PMTiles PR that updates the byte that specifies the type of tile to include MLT.
PMtiles is often used with MVT tiles, but it can encapsulate a variety of tile types: the current spec [1] has defined tile types for MVT, PNG, JPEG, WebP and AVIF (plus "Unknown/Other").
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!
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.
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?
We've been self-hosting protomaps (aka pmtiles) for several years. The only thing you need server-side is a web server that can serve static files and supports range requests (so anything works; I've tried caddy and nginx). The map is one large file, it's easy to share it between however many servers you need.
Downsides? Nothing major that I can think of. You have to add another client-side dependency (support for their custom protocol); the library is pretty small and easy to audit.
Editing map styles is slightly more difficult because generic maplibre styles won't work with it: they add a bit of custom sauce on top. IIRC this editor worked fine, you can import one of protomaps styles and base your work off it:
In short: We have a script that builds a pbf of the area we are interested in (Colorado, USA) from OSM, then set up a openstreetmap-tile-server container with that data, bring in our styles, and then set up renderd.
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 <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!
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:
We don't have a marketing department, so we're happy to take suggestions on our messaging!
What makes it modern are the ideas behind it: the column-oriented layout, support for lightweight encodings such as FSST and FastPFOR and support for pre-tessellation. Also, enabling doing more computations on the GPU instead of the CPU, which are made possible thanks to modern graphics APIs like Vulkan and Metal. I agree that it is better to be specific about these things (if that is your gripe with it), but there's only so many characters that fit into a title. ;)
1) It's not. Maplibre is a JS library for displaying map data. OpenStreetMap is a collection of map data that is published in various formats. Different levels of the stack.
2) It's an optimization/advancement. There are some pain points in the older version that 10 years of experience can fix in a newer format.
3) Attention, funding. Technically, they're at the leading edge of open source.
Additionally to point 2, the older format was created by a company (Mapbox) that used to be open source-friendly but has recently made a larger pushback against open source and open standards, changing the licenses of much of their formerly open source work. (The Maplibre JS library itself is a fork of that company's previous open source work from its last open source drop to keep the work open source.)
The key info token you'll want to know as someone foreign to map topics is that maplibre is a licence continuity fork of the formerly open source Mapbox code.
Everything else pretty much derives from this, e.g. yeah, OSM did not suddenly go all in on former mapbox stuff only because the company started keeping updates behind a paywall, OSM continues to be as tool-agnostic as ever.
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-...
I’m not sure it’s very useful to rehash an argument with very tenuous relation to the OP here. The normal reason to use the Mercator projection in these situations is (a) it’s what people are used to and (b) it preserves angles so if you zoom in on a street then up will still be north and roads that are at right angles in the real world appear to be at right angles on the map. The latter property is pretty desirable and hard to achieve without doing some weird transition between projections as you zoom. This matters more for Europe (and I suppose parts of British Colombia) where there is a high population density at latitudes that are pretty extreme in much of the world.
I think Apple Maps has a pretty reasonable compromise here of transitioning from a globe to Mercator as you zoom, but this is a less nice UI with a mouse as you need to click to rotate the globe instead of pointing and zooming only. I don’t think there’s anything in this data that would make that unachievable – you just need to reproject the vector data a bit as you zoom out – but it takes some tricky mathematics to get right and so hasn’t been done yet.
It's on our roadmap to support alternate projections, but as you can imagine it's a big project that so far nobody has been willing to pay for to implement unfortunately.
MapLibre GL JS does support globe mode. https://maplibre.org/maplibre-gl-js/docs/examples/display-a-... May we should update our examples to use globe mode when showing examples, especially those that show a world map. We will take that feedback into consideration!
MapLibre's globe mode is both fantastic and performant. Also, it's literally just the one option to change it, and your tile formats/CRS don't need to change either.
It's the easiest way to escape from web mercator projections with no real downsides that I have discovered yet. Also, there is a built-in control if you want to offer a button to toggle between web mercator view, and globe view, since it's all just rendering changes.
Web Mercator is the standard projection used on the web, if you think the we should use a different projection on the web then that's a completely separate argument
It's actually worse than that because the Web Mercator projection is unusable for navigation too - it doesn't preserve angles or area! (Angles are nearly preserved).
Well done Google. Slow handclap.
The NGA advised it's likely to cause geolocation errors of up to 40km near the poles:
I would not use such strong rhetoric as the GP, but I believe they probably mean we should lean towards using the Gall/Peters projection, which maintains lengths and areas, but not angles.
(There are of course other projections with other interesting features; or you could take the same projection but center the world differently etc.)
This comment is inaccurate! Web Mercator causes such large errors in geolocation that the NGA had to issue an advisory about it [1].
There is a whole science behind map projections and Google ignored it entirely when they created Web Mercator, which was a hack to divide the world into a quad tree. It was vaguely clever and utterly stupid at the same time.
Web mercator is fantastic map. It's well known of course, so very helpful to orient. Plus, its square and easily tile-able, which is good for performance. Shapes of countries are preserved. Plus, the lines are straight, which works great for on screen. Neat and tidy.
Who cares Greenland looks big when zoomed out. "Mercator distorts size" is one of those gis-nerd idee fixes, the first factoid they learn in class, and it overwhelms all thought.
Come to the MapLibre talk in the Geospatial devroom at FOSDEM on Saturday
https://fosdem.org/2026/schedule/event/QAL9VN-state-of-the-m...
If one can fit :P
Had to search a bit, but here's a demo page: https://maplibre.org/maplibre-gl-js/docs/examples/display-a-... Can be compared with: https://maplibre.org/maplibre-gl-js/docs/examples/display-a-...
In that example I saw this in the console:
So roughly a ~10% compression improvement, neat!
Note that the demotiles style is not really comparable to a production basemap such as ones based on the popular OpenMapTiles schema. The article linked in the announcement has some more findings related to compression ratio.
Also note that lightweight encodings are built into the format, and different tiles can even be encoded in a completely different way. So you have to use heuristics to find the best combination of encodings and often you need to make a trade off between tile size and decoding performance. It is still early days for MLT, but all this means there are a lot of possibilities for optimization. In fact, AWS is again financing work on MLT this year, with a focus on optimization.
Lastly, when benchmarking tile size, it is good to look at actual usage patterns instead of size of the total tile set. Nobody is zooming into a random spot in the ocean, for example. ;-)
This is interesting. We recently deployed a solution that uses pmtiles and it's great.
https://docs.protomaps.com/pmtiles/
afaik, pmtiles uses mvt, let's hope the tooling to convert the tiles to mlt also becomes available.
PMTiles is actually pretty agnostic to what kind of tiles it contains! There is already a PMTiles PR that updates the byte that specifies the type of tile to include MLT.
https://github.com/protomaps/PMTiles/pull/596
Neat, as someone integrating PMTiles right now, thank you!
Oh wow, thank you, looking forward to this
PMtiles is often used with MVT tiles, but it can encapsulate a variety of tile types: the current spec [1] has defined tile types for MVT, PNG, JPEG, WebP and AVIF (plus "Unknown/Other").
[1]: https://github.com/protomaps/PMTiles/blob/main/spec/v3/spec....
Absolutely, we have MVT tiles at the moment, I'm hoping to test MLT soon
I'm building PMTiles through Tilemaker, PMTiles is incredible, but sadly it will take a lot of work to produce MLT though Tilemaker :/
Oh pmtiles is such a simple and innovative solution!
It is. I’ve found it so useful I created an Elixir library to act as a cache in front on a pmtiles file. https://hex.pm/packages/ex_pmtiles
Yes, Absolutely in love with it. Loading tiles with range requests made our application so much faster.
2 replies →
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!
This 100%
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.
Unfortunately, Tilemaker hasn't planned or cannot plan to support MLT in the medium-term.
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
[dead]
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?
Does anyone self host maps? If you do, mind sharing the pros, cons and tools to do that?
We've been self-hosting protomaps (aka pmtiles) for several years. The only thing you need server-side is a web server that can serve static files and supports range requests (so anything works; I've tried caddy and nginx). The map is one large file, it's easy to share it between however many servers you need.
https://docs.protomaps.com/guide/getting-started
Downsides? Nothing major that I can think of. You have to add another client-side dependency (support for their custom protocol); the library is pretty small and easy to audit.
Editing map styles is slightly more difficult because generic maplibre styles won't work with it: they add a bit of custom sauce on top. IIRC this editor worked fine, you can import one of protomaps styles and base your work off it:
https://maputnik.github.io/editor
That's probably it.
How do you update pmiles? Do you have to rebuild the entire map every time? If so, I think that's a downside/limitation for some use cases.
Are the names of cities/streets included in the tiles, or do they have to be placed from a different data source?
3 replies →
We use mod_tile+renderd: https://github.com/openstreetmap/mod_tile
In short: We have a script that builds a pbf of the area we are interested in (Colorado, USA) from OSM, then set up a openstreetmap-tile-server container with that data, bring in our styles, and then set up renderd.
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 <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!
Unrelated, but I noticed that clicking the logo goes to the current permalink rather than the homepage, might be unintentional.
I just want support for globe view on maplibre native
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:
https://ayende.com/blog/199523-C/integer-compression-underst...
All links in the top navigation are broken (404).
Sorry about that. Noticed the footnote was broken.
Fixed the footnote, broke all other links. Should be OK again when the caches catch up.
"Modern" is such a silly way to advertise things.
We don't have a marketing department, so we're happy to take suggestions on our messaging!
What makes it modern are the ideas behind it: the column-oriented layout, support for lightweight encodings such as FSST and FastPFOR and support for pre-tessellation. Also, enabling doing more computations on the GPU instead of the CPU, which are made possible thanks to modern graphics APIs like Vulkan and Metal. I agree that it is better to be specific about these things (if that is your gripe with it), but there's only so many characters that fit into a title. ;)
Although the word is overused, hindsight can be a huge advantage in design.
[dead]
I am not familiar with the ecosystem of geographic data and mapping as online services. Can someone please explain...
* 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)?
1) It's not. Maplibre is a JS library for displaying map data. OpenStreetMap is a collection of map data that is published in various formats. Different levels of the stack.
2) It's an optimization/advancement. There are some pain points in the older version that 10 years of experience can fix in a newer format.
3) Attention, funding. Technically, they're at the leading edge of open source.
Additionally to point 2, the older format was created by a company (Mapbox) that used to be open source-friendly but has recently made a larger pushback against open source and open standards, changing the licenses of much of their formerly open source work. (The Maplibre JS library itself is a fork of that company's previous open source work from its last open source drop to keep the work open source.)
> There are some pain points in the older version that 10 years of experience can fix in a newer format.
What were the major pain points? Compression ratio and speed seem like two of them. (Thanks for answering the elementary questions.)
The key info token you'll want to know as someone foreign to map topics is that maplibre is a licence continuity fork of the formerly open source Mapbox code.
Everything else pretty much derives from this, e.g. yeah, OSM did not suddenly go all in on former mapbox stuff only because the company started keeping updates behind a paywall, OSM continues to be as tool-agnostic as ever.
[dead]
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-...
I’m not sure it’s very useful to rehash an argument with very tenuous relation to the OP here. The normal reason to use the Mercator projection in these situations is (a) it’s what people are used to and (b) it preserves angles so if you zoom in on a street then up will still be north and roads that are at right angles in the real world appear to be at right angles on the map. The latter property is pretty desirable and hard to achieve without doing some weird transition between projections as you zoom. This matters more for Europe (and I suppose parts of British Colombia) where there is a high population density at latitudes that are pretty extreme in much of the world.
I think Apple Maps has a pretty reasonable compromise here of transitioning from a globe to Mercator as you zoom, but this is a less nice UI with a mouse as you need to click to rotate the globe instead of pointing and zooming only. I don’t think there’s anything in this data that would make that unachievable – you just need to reproject the vector data a bit as you zoom out – but it takes some tricky mathematics to get right and so hasn’t been done yet.
It's an important discussion because it's abundantly clear that almost nobody on this thread has a clue what they're talking about.
Web Mercator != Mercator.
I suggest most people on this thread need to go away ask the question "What's the difference between Web Mercator and Mercator".
It's on our roadmap to support alternate projections, but as you can imagine it's a big project that so far nobody has been willing to pay for to implement unfortunately.
MapLibre GL JS does support globe mode. https://maplibre.org/maplibre-gl-js/docs/examples/display-a-... May we should update our examples to use globe mode when showing examples, especially those that show a world map. We will take that feedback into consideration!
You can use the Equal Earth projection with a plugin: https://equal.bbox.earth/maplibre-americas/
MapLibre's globe mode is both fantastic and performant. Also, it's literally just the one option to change it, and your tile formats/CRS don't need to change either.
It's the easiest way to escape from web mercator projections with no real downsides that I have discovered yet. Also, there is a built-in control if you want to offer a button to toggle between web mercator view, and globe view, since it's all just rendering changes.
Web Mercator is the standard projection used on the web, if you think the we should use a different projection on the web then that's a completely separate argument
It's actually worse than that because the Web Mercator projection is unusable for navigation too - it doesn't preserve angles or area! (Angles are nearly preserved).
Well done Google. Slow handclap.
The NGA advised it's likely to cause geolocation errors of up to 40km near the poles:
https://www.gpsworld.com/nga-issues-advisory-notice-on-web-m...
Accuracy where it matters is why. Do you have a better suggestion for projecting a sphere onto a rectangle?
I would not use such strong rhetoric as the GP, but I believe they probably mean we should lean towards using the Gall/Peters projection, which maintains lengths and areas, but not angles.
(There are of course other projections with other interesting features; or you could take the same projection but center the world differently etc.)
5 replies →
This comment is inaccurate! Web Mercator causes such large errors in geolocation that the NGA had to issue an advisory about it [1].
There is a whole science behind map projections and Google ignored it entirely when they created Web Mercator, which was a hack to divide the world into a quad tree. It was vaguely clever and utterly stupid at the same time.
[1] https://web.archive.org/web/20140607003201/http://earth-info...
3 replies →
You can read more about why most web maps are like this and a quest to fix this in this article: https://www.mapbox.com/blog/adaptive-projections
Web mercator is fantastic map. It's well known of course, so very helpful to orient. Plus, its square and easily tile-able, which is good for performance. Shapes of countries are preserved. Plus, the lines are straight, which works great for on screen. Neat and tidy.
Who cares Greenland looks big when zoomed out. "Mercator distorts size" is one of those gis-nerd idee fixes, the first factoid they learn in class, and it overwhelms all thought.
> Who cares Greenland looks big when zoomed out.
You never know - one day, the geography of Greenland could matter quite a bit to the rest of the world.
Maybe you shouldn't have skipped that class if you don't think it's important.
You're a bit hasty, for the users that needs mercator projections, they should be able to get it, see: https://maplibre.org/maplibre-gl-js/docs/API/type-aliases/Pr...
Because that's what everyone is used to.
Maplibre supports different projections if you want.
Not everyone has a spherical monitor.
obligatory West Wing: https://www.youtube.com/watch?v=vVX-PrBRtTY
This episode never made any sense at all. We already have globes for true sizes.