You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 tilesetsource_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.
The text was updated successfully, but these errors were encountered:
When more than one tileset is composited, vector_layers get merged into a single list.
source
andsource_name
fields 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.
The text was updated successfully, but these errors were encountered: