When more than one tileset is composited, vector_layers get merged into a single list. source and source_name fields are useful for identifying which vector_layers belong to which member of a composite source.
// An example vector layer entry with `source` and `source_name`:
{
description: string,
fields: { [string]: string },
id: string,
maxzoom?: number,
minzoom?: number,
source: string, // Matches id of parent tileset
source_name?: string // Matches name of parent tileset
}
This does bring up a bigger question for me. I find the tileJSON spec's ability to successfully describe composited tileJSON to be lacking. I want to know more details about each tileset in my composite. A nested data structure for composited tileJSON that includes the full original tileJSON for each composited tileset would be a much more convenient document to work with, for example.
When more than one tileset is composited, vector_layers get merged into a single list.
sourceandsource_namefields are useful for identifying which vector_layers belong to which member of a composite source.This does bring up a bigger question for me. I find the tileJSON spec's ability to successfully describe composited tileJSON to be lacking. I want to know more details about each tileset in my composite. A nested data structure for composited tileJSON that includes the full original tileJSON for each composited tileset would be a much more convenient document to work with, for example.