Support for generating MapLibre Tiles (MLT)?

[der-stefan]

Currently tilemaker is a great tool for generating MVT vector tiles. There is some work going on at the MapLibre project for specifying a more up-to-date vector tile format called MLT: https://maplibre.org/maplibre-tile-spec/specification/
According to their information the format should come with a better compression while being more flexible and better decoding performance at the clients.
Is there some work going on to support also MLT tiles? Or would tilemaker get obsolet when there are different implementations for generating MLT tilesets?

[systemed]

The MLT file format is incredibly complex, and in practice I think we would be reliant on a C++ encoder being provided that we could hook into. Currently the C++ code only claims "partial support" for encoding, but in practice I'm not sure it even has that. :) Once it's more complete we could look at integrating it into tilemaker.

[der-stefan]

Thank you for your response! I am very excited to test the MLT tile format once a well-known path for tile generation is existing. Let's give the developers a bit more time...

[CommanderStorm]

Thanks for the interst ❤️
I agree that integration into tilemaker is likely too early.

partial support for encodings

encodings != ecoder

That mostly refers to our experimental encodings, where we have not fully worked out all the details. See the experimental tag at https://maplibre.org/maplibre-tile-spec/specification/

practice I think we would be reliant on a C++ encoder being provided that we could hook into

We won't do a C++ encoder by itself, (or at least currently don't have budget allocated for that).
We are doing the C++/ts decoders since that is required for the renderers and java/rust encoder/decoder for the rest.

The rust encoder is not currently production ready, @nyurik is working on it (❤️).

Users will be able to use our CLI tool to convert the tiles or planetiler to create their pm/mbtiles.

[systemed]

Thanks for the update!

I think that's a great shame. Mapbox Vector Tiles became an open standard and a success because anyone was able to build tooling around the format.

A format that is so complex that it requires external funding simply to write a tile generator is not going to do that, and I'm sad if Maplibre has become merely a tool for corporates.

[nyurik]

strong and offensive words without context or meaning.... have you seen the complexity of implementing flatgeobuf or similar modern format? have you looked at the modern compression algorithms like fastpfor?

[systemed]

Not meaning any offense. Yes, these things are indeed complex. You've made a deliberate choice that this implementation complexity is worthwhile for the performance and filesize gains, and that's absolutely your choice to make. Nonetheless choices come with trade-offs, and the trade-off in this case is that implementation is not practical unless (a) you're using one of the anointed languages/toolchains, or (b) you're a corporate with the resources to roll your own implementation.

[CommanderStorm]

Lets all chill and focus on the technical aspects, ok?

The format is desiged to be the fastest to render and the most compact.
That this comes at complexity is to be expected.
In the end, if you were looking for simplicity, you would choose GeoJSON, right? 😉

Is it currently production ready in all aspects? No, but progressing.
Was the original research and implementation funded by somebody? Yes, mostly.
Be it thesis work or real work, R&D needs support 🤷🏻‍♂️
I don't think you are arguing against this.

I don't think doing cutting edge things is possible without that.

Will ecosystem adoption be slower because of this complexity? Likely

[CommanderStorm]

Also, we will continue to support MVTs for the forseeable future, at least until the ecosystem is fully ready.
It is all going to be fine and will take a lot of time.

[systemed]

In the end, if you were looking for simplicity, you would choose GeoJSON, right? 😉

I'm not sure the fun of writing JSON from C++ is ever going to count as "simplicity" ;)

But agreed on all of that. I would just encourage you to remember that a large part of the reason MVT became such a success was because of the hobbyists building an ecosystem around it, not just because Mapbox wrote a genuinely awesome renderer. It would be good to see MLT continue in that tradition.

[pnorman]

MVT has the advantage that you "only" have to write code that handles geometry¹ and calling the protobuf library. You don't need to know anything about the binary representation of MVTs because Protobuf read/write implementations are available for virtually every language.

A custom binary format like MLT is out of the reach of many people who wrote custom MVT stuff.

I recommend closing this because for now

1. the spec is not yet ready, with comments like "This is not clear, and possibly incorrect. Why any number? Should the size of the upcoming metadata and table be part of that structure?" in it.
2. The best estimate of how much work it would be to implement MLT writing in C++ is that it would require external funding for Maplibre to implement. Implementing it in tilemaker would require even more work because there isn't existing expertise in the format. If anyone wants to come forward and pay for it to be implemented in tilemaker they would be better off paying for the creation of a C++ library²

Footnotes

1. Handling geometry quantization to an integer grid is very tricky and why I don't recommend people write their own MVT generation code. ↩

2. Or more realistically, a C++ interface to the Rust library ↩

[louwers]

Let's have a chat about this.

Would @systemed or one of the tilemaker contributors be able to in join our monthly MLT call? Next one is scheduled for 9 Feb 2026, 3 PM (GMT+00:00) United Kingdom Time (although I will try to bump it to one our later).

Please send me an e-mail at bart.louwers@gmail.com and I can send an invite!