If one can fit :P

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.

https://github.com/protomaps/PMTiles/pull/596

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....

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!

This 100%

You can always convert after the fact. Just go from MVT to MLT. There's a Java based program in the repo.

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.

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!

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.

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.

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).

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.

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.