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 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").
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.
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!
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!
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:
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.
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.)
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
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
In that example I saw this in the console:
So roughly a ~10% compression improvement, neat!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://github.com/protomaps/PMTiles/pull/596
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...
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.
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.)
Maplibre supports different projections if you want.
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)?