support for conversion back to mbtiles (or pmtile-join)

[underbluewaters]

If maintaining a library of layers converted to pmtiles, it would be nice to be able to consolidate them into a multi-layer tileset. Right now the conversion to pmtiles seems to be a one-way process. If the archive could be converted back to mbtiles then tippecanoe's tile-join utility could be used. I can't get my head around whether an analogous pmtiles-join process would be possible.

[bdon]

Agreed, this should be pretty simple to implement and should happen in http://github.com/protomaps/go-pmtiles

Thinking out loud a bit, the MBTiles spec only specifies a view over the tiles table - a dataset originally created in PMTiles format would write two tables, one tile_data and another tile_coords with a JOIN in between using a synthetic key or even the offset in the PMTiles archive as an integer join key.

In the long run I would hope for a pmtiles-join command but we do need the conversion back for interior with existing tools.

[underbluewaters]

Ah, I was thinking about this as more of a batch job rather than a dynamic process using something like go-pmtiles. Both are important use cases though. Mapbox supports compositing multiple data sources into a single vector tile service dynamically, so that your can do a request like /sources/mapbox.streets-v12,seasketch.bathymetry,seasketch.eez/{z}/{x}/{y}.pbf and get a tile with data from all 3 static tile archives. Dynamic compositing would definitely be useful.

I'd like to also combine archive_a + archive_b, to get a static archive_c, ideally with some of the advanced capabilities of tile-join to support overzooming of data in case the zoom levels of the 2 archives don't match.

[bdon]

It would be a batch job. Sorry, the README for go-pmtiles is not updated, but it is intended to replace the pmtiles-convert python program as it is much faster, easier to maintain, and simpler to install on different environments.

Basic dynamic compositing and layer trimming is something that is being prototyped in the vtfilter branch = a serverless function on Lambda or Cloudflare Workers can composite multiple PMTiles sources or return only a subset of layers/features. The overzooming use case is tricky however for if the max zooms do not match; a naive implementation could avoid clipping and simply translate + scale the over zoomed geometry, possibly including lots of extra data outside the tile boundary.

A full fledged polygon clipping implementation inside the overzooming code on the server side seems quite difficult...