Include arbitrary key/values from metadata in TileJSON for `pmtiles serve`.

[scottrhoyt]

It would be useful to have arbitrary key/value pairs in the metadata exposed in the TileJSON. The TileJSON spec allows for it, and it would be allow passing non-standard TileJSON values to map renderers. For instance, MapLibre looks for an encoding value of "terrarium" or "mapbox" in a raster DEM TileJSON to determine how to handle the data (maplibre/maplibre-native#3564).

[bdon]

Adding all keys from the JSON metadata to TileJSON will have some unintended consequences: vector tiles created with tippecanoe have a "tilestats" key that can contain hundreds of KBs of data.

Also it seems like the encoding of a raster DEM source ought to be in the style.json source object and not the TileJSON: https://maplibre.org/maplibre-style-spec/sources/#url_2

[scottrhoyt]

Thanks for that additional context! There are unintended consequences to this that I was unaware of, and they should be carefully explored.

After discussions with the ML folks, it's currently pretty undefined as to whether encoding is meant to be in the style.json or TileJSON. For instance, currently MapLibre Native will look for it either in the TileJSON or in the style.json but only if the style.json is the provider of the entire required TileJSON spec. I have a PR out to make this more consistent with the JS implementation and allow the encoding param to supplement/override the TileJSON info retrieved dynamically.

I do think it would be really useful to allow for arbitrary metadata to flow through to TileJSON for cases beyond the encoding one. For instance, useful fields I've added before have been id, icon, and ttl. The TileJSON spec allows for these arbitrary key/value pairs and specifies implementations must pass them on to users. While that's not exactly pertinent here since this is constructing a TileJSON instead of interpreting it, I do believe the spirit is to allow these implementation-specific key/value pairs to transparently be passed through the spec, and I think this repro serves as a reference implementation for how other libraries (like MapLibre) should build TileJSON info for a PMTiles file.

Even as someone who has generated PMTiles with tippecanoe, I was unaware of the tilestats metadata. Considering a main use case is for the whole file to be stored in the cloud and publicly accessible, I wonder if there should generally be more insight/control for users on what is in the metadata and how it gets translated into a TileJSON?

Anyway, thanks for the additional info and engaging in conversation on this. I see both sides and do believe in the benefits of additional control over the TileJSON data, but I understand if that's not the direction you want to take.