In that example I saw this in the console:
before - 2.41+26.29+24.87+71.28+59.2+77.57 - 261.62kb
after - 2.45+22.4 +22.66+60.6+51.99+77.57 - 237.67kb
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. ;-)
https://docs.protomaps.com/pmtiles/
afaik, pmtiles uses mvt, let's hope the tooling to convert the tiles to mlt also becomes available.
[1]: https://github.com/protomaps/PMTiles/blob/main/spec/v3/spec....
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.
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...
Fixed the footnote, broke all other links. Should be OK again when the caches catch up.
* 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)?
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.
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.
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/
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...
It has errors of up to 40km near the poles, the NGA had to issue an advisory about it.
There is a whole science behind map projections and Google ignored it entirely when they created Web Mercator.
(There are of course other projections with other interesting features; or you could take the same projection but center the world differently etc.)
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.
Maplibre supports different projections if you want.