Next-generation 3DTiles (Next) detailed explanation [6] 3DTILES_metadata of tile attribute data organization extension

depends on

3D Tiles 1.0

optional and required

If attribute metadata is used, this extension must be present in both the extensionsUsed and extensionsRequired arrays, ie "required".

1 Overview

This extension defines a mechanism for storing structured metadata in 3D Tiles, commonly referred to as attribute data , from a wide variety of sources that can be used for data inspection, analysis, styling 3D Tiles, or for other purposes.

In this article, I'll call it attribute metadata for now.

These attribute data should be recorded according to the template, which is called "Schema", which makes the attribute data have rules to follow. Moreover, objects at different levels (the largest object is Tileset, followed by Tile, etc.) have different associations.

The following describes the details of the metadata (attributes) of objects at different levels:

• For the Tileset level, attribute metadata records information at the entire dataset level, such as the year of data release, etc.
• For the tile level, attribute metadata can record more fine-grained information, such as the maximum height of tile data content, etc.
• For the Tile Content Groups level, the attribute metadata of the grouped tile data content can also be grouped to store

Regarding the three-dimensional element level in the tile data content, there can also be attribute metadata, refer to 3.5 Deeper element-level attribute metadata

The concepts in this extension are all 3D Metadata Specification .

The following figure shows an example of the relationship and attribute metadata between the various levels of objects (tileset, tiles, content, group) in 3D Tiles:

What is attribute metadata useful for?

• Direct View: Display attribute metadata when mouse over or click tiles on the interface
• Grouping: The data content of tiles can be grouped, and each group can have its own attribute metadata, so that all consistent operations of tiles in the group, such as display and hiding, can be controlled according to each group's own attribute metadata.
• Supports data in complex formats: This extension supports Schema embedded within JSON, as well as external references, so that experts in various fields can incorporate industry data into it
• Rendering optimization: The attribute metadata may contain some performance optimization-related parameters, so that the related algorithms can be optimized when traversing is needed.

2. Attribute metadata

2.1. Overview

Property describes the information of an entity (entity refers to Tileset, Tile or TileGroup).

Schema defines metadata information such as data types for Class.

Each entity is a concrete instance of Class and has data values recorded in Class.

In addition, Statistics can extract the statistical values in a specific Class and store them separately; Semantic is used to define the usage and meaning of a specific Property.

2.2. schema

A schema generally composed classes and enum both describe the data storage format attributes, and the remaining attributes are descriptive id , name , description , version , extensions and extras .

Classes consist of several key-value classes.

2.2.1. class

Each class abstracts a type of metadata, the name is the key.

There are specific properties that describe what properties constitute.

Example:

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "classes": {
          "building": {
            "properties": {
              "name": {},
              "id": {},
              "height": {}
            }
          }
        }
      }
    }
  }
}

"building" is a class, which has 3 "property": "name", "id", "height", which is the class property to be introduced in the following section.

2.2.2. class property

Each class has a properties property object, and each of its key-values is a property

All properties are used to describe the data composition of the class.

Used to describe the properties of a property, measured by fields such as componentType, type, semantics, etc.

① property.componentType

The attribute componentType is the component type, and there are the following types:

• "BOOLEAN" , Boolean
• "STRING" , string type
• "ENUM" , enumeration type, refer to section 2.2.3
• "INT8" , "INT16" , "INT32" , "INT64" , signed integer, from 8 to 64 bits
• "UINT8" , "UINT16" , "UINT32" , "UINT64" , unsigned integer, from 8 to 64 bits
• "FLOAT32" , "FLOAT64" , floating point, both 32 and 64 bit

② property.type

There are four categories, all of which are strings:

• "SINGLE" , the default, single value type
• "ARRAY" , array type
• "VEC2" , "VEC3" , "VEC4" , vector type
• "MAT2" , "MAT3" , "MAT4" , moment (square) matrix type

Among them, for "SINGLE" and "ARRAY" type properties, its elements can be of any data type; for "VECN" and "MATN" types of properties, its element type can only be numeric.

③ property.semantic

The property can be marked with a special meaning, that is, using the property.semantic attribute, to mark the additional information required by the front end. Its value can be any string, or it can be built-in semantic by the specification, see 3D Metadata Semantic Reference

For example, take the property "building" as an example:

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "classes": {
          "building": {
            "properties": {
              "name": {"componentType": "STRING", "semantic": "NAME"},
              "id": {"componentType": "STRING", "semantic": "ID"},
              "height": {"componentType": "FLOAT32", "semantic": "_HEIGHT"}
            }
          }
        }
      }
    }
  }
}

It can be seen that it has 3 properties:

"name", "id" and "height",

Their "semantic" are:

"NAME", "ID" and "_HEIGHT".

Among them, "NAME" and "ID" are built-in specifications, and "_HEIGHT" is custom.

2.2.3. enum

enum, that is, enumeration, the property.componentType in the previous section is allowed to have "ENUM" , that is, the value of the property of class, which is allowed to be of enumeration type.

Example:

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "enums": {
          "qualityEnum": {
            "name": "Quality",
            "description": "An example enum defining expected quality of data within a tile.",
            "values": [
              {"name": "Unspecified", "value": 0},
              {"name": "Low", "value": 1},
              {"name": "Moderate", "value": 2},
              {"name": "High", "value": 3}
            ]
          }
        }
      }
    }
  }
}

enums and classes are attributes of the same level. An enumeration type "qualityEnum" "name" that can be used for display. It can be seen that its enumeration value is given in the form of an array:

[
  {"name": "Unspecified", "value": 0},
  {"name": "Low", "value": 1},
  {"name": "Moderate", "value": 2},
  {"name": "High", "value": 3}
]

Where "name" is the name "value" is the value of the enumeration value.

Note that the Unspecified enumeration value here is special and optional and can be used to identify missing data.

2.2.4. External schemas

If "3DTILES_metadata" does not provide the "schema" attribute, the schema definition is provided by external json:

{
  "extensions": {
    "3DTILES_metadata": {
      "schemaUri": "https://example.com/metadata/buildings/1.0/schema.json"
    }
  }
}

2.3. statistics

Statistical information is used to record the statistical variables of each class, such as the maximum and minimum values, the average, the frequency of enumeration, etc.

These statistics can be used in the code for data analysis, display and other operations, such as using [Declarative Style Language]().

Statistics are provided by class. After providing styling or context based on the entire tileset, the program code only needs to manage the downloading and processing of the tiles.

Example:

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "classes": {
          "building": {
            "properties": {
              "height": {"componentType": "FLOAT32"},
              "owners": {"type": "ARRAY", "componentType": "STRING"},
              "buildingType": {"componentType": "ENUM", "enumType": "buildingType"}
            }
          }
        },
        "enums": {
          "buildingType": {
            "valueType": "UINT16",
            "values": [
              {"name": "Residential", "value": 0},
              {"name": "Commercial", "value": 1},
              {"name": "Hospital", "value": 2},
              {"name": "Other", "value": 3}
            ]
          }
        }
      },
      "statistics": {
        "classes": {
          "building": {
            "count": 100000,
            "properties": {
              "height": {
                "minimum": 3.9,
                "maximum": 341.7,
                "_mode": 5.0
              },
              "buildingType": {
                "frequencies": {
                  "Residential": 50000,
                  "Commercial": 40950,
                  "Hospital": 50
                }
              }
            }
          }
        }
      }
    }
  }
}

There is only one class here, and its statistics are extracted separately as follows:

{
  "count": 100000,
  "properties": {
    "height": {
      "minimum": 3.9,
      "maximum": 341.7,
      "_mode": 5.0
    },
    "buildingType": {
      "frequencies": {
        "Residential": 50000,
        "Commercial": 40950,
        "Hospital": 50
      }
    }
  }
}

It is easy to see that the numerical attribute height records the maximum and minimum values, which are 341.7 and 3.9 respectively; the frequencies of the three enumeration values in the buildingType

2.3.1. Custom Statistics

The specification allows adding custom statistical information. In order not to conflict with the official statistical variable name, just add an underscore before the custom statistical variable name, such as the custom statistical variable _mode of the height attribute in the above example, and its value is 5.0

2.3.2. Official built-in statistical variables

name	describe	appropriate types
minimum	minimum	SINGLE、ARRAY、VECN、MATN
maximum	maximum value	Ditto
mean	Arithmetic mean	Ditto
median	median	Ditto
standardDeviation	standard deviation	Ditto
variance	variance	Ditto
sum	and	Ditto
frequencies	frequency	ENUM

Among them, freqencies appear in the form of objects, the key is the name of the enumeration, and the value is the frequency; the values of the other statistical variables are all numeric values. See example above.

3. Distribution of metadata

classes just defines the data type and meaning of attribute metadata, the actual elements in 3D Tiles do not really have actual data.

The attribute metadata of each 3D Tiles actual element will include which class it belongs to, which is identified by the name of the class, and the specific attribute fields of the attribute metadata correspond to the fields specified in the class (the name is the same, the data type is the same), if An attribute field does not have required: true provisions in its class, so it may not appear in JSON.

Most property metadata is written directly in JSON, with the exception of property metadata for implicit tiles in the tileset of the Implicit Tile Splitting extension, which stores property metadata in binary.

Grading:

• Attribute metadata at the Tileset level
• Tile-level attribute metadata (including implicit tile attribute metadata)
• ContentGroup-level attribute metadata
• ContentFeature level attribute metadata

Next, let's look at specific examples of attribute metadata on elements at each level from coarse to fine.

3.1. Attribute metadata at the Tileset level

Specification references tileset.schema.json and metadataEntity.schema.json

Attribute metadata that acts on the entire tileset level, common attributes may include: year information, data producer details, general context of tileset, etc.

example:

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "classes": {
          "city": {
            "properties": {
              "name": {"componentType": "STRING", "semantic": "NAME", "required": true},
              "dateFounded": {"componentType": "STRING", "required": true},
              "population": {"componentType": "UINT32", "required": true},
              "country": {"componentType": "STRING"}
            }
          }
        }
      },
      "tileset": {
        "class": "city",
        "properties": {
          "name": "Philadelphia",
          "dateFounded": "October 27, 1682",
          "population": 1579000
        }
      }
    }
  }
}

In this example, extensions is the top-level attribute of the entire tileset.json. The tileset attribute and schema are at the same level, and both are components extensions.3DTILES_metadata

tileset attribute specifies the top-level element of this tileset, that is, the attribute metadata of the tile dataset itself. Its class is "city" , which can be found in the schema. In the example, three required: true the class city are assigned, namely "name" of "Philadelphia" , "dateFounded" of "October 27, 1682" of 061f300cf5af10, and "population" of 1579000 .

3.2. Tile-level attribute metadata

Specification references [tile.3DTILES_metadata.schema.json]() and [metadataEntity.schema.json]()

Each tile is allowed to have its own attribute metadata, such as adding some spatial information to facilitate the traversal of the spatial indexing algorithm.

The following example will use the built-in semantic TILE_MAXIMUM_HEIGHT , see the specific reference (3D Metadata Semantic Reference)[]

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "classes": {
          "tile": {
            "properties": {
              "maximumHeight": {
                "semantic": "TILE_MAXIMUM_HEIGHT",
                "componentType": "FLOAT32"
              },
              "countries": {
                "description": "Countries a tile intersects.",
                "type": "ARRAY",
                "componentType": "STRING"
              }
            }
          }
        }
      }
    }
  },
  "root": {
    "extensions": {
      "3DTILES_metadata": {
        "class": "tile",
        "properties": {
          "maximumHeight": 4418,
          "countries": ["United States", "Canada", "Mexico"]
        }
      }
    },
    "content": { ... },
    ...
  }
}

It's easy to see that this is a traditional tileset, without the use of the implicit tile split extension.

The attribute metadata acts on the extensions.3DTILES_metadata attribute of the root tile, indicating that the attribute metadata follows the tile class, which records the two attribute fields specified by the tile class, of which the maximumHeight field has built-in semantics (semantic)—— "TILE_MAXIMUM_HEIGHT", whose value is specified as 4418 ; the countries field is a regular string array whose value is ["United States", "Canada", "Mexico"] .

3.3. Attribute metadata for implicit tiles

Specification references [subtree.3DTILES_metadata.schema.json]() and [metadataEntity.schema.json]()

This section requires a leading base of 3DTILES_implicit_tiling.

If a tileset has the implicit tile segmentation extension enabled, then there is no JSON definition of each tile in tileset.json, and the attribute metadata of each tile needs to be recorded elsewhere, that is, in the subtree file JSON and binary, that is, the 3DTILES_implicit_tiling extension can be used compatible with the 3DTILES_metadata extension.

Since the subtree file is a binary file, simply encode the attribute metadata into the binary, and the JSON part only leaves the bytes of the attribute metadata in the binary to store the description information. For specific encoding specifications, refer to 3D Metadata Specification - Storage Format - Binary Table Format

Binary encoding is good for large datasets.

Note that the attribute metadata of tiles is only valid for visible tiles, and for each visible implicit tile, even if there is no attribute field, the value of this attribute needs to use the corresponding noData symbol placeholder.

Implementation Note: In order to determine the index value of an attribute of a specific implicit tile in the attribute array, the pre-visibility of this implicit tile needs to be calculated according to the visibility order of all implicit tiles in the subtree number of tiles. For example, if there are i visible tiles before a particular implicit tile, then an attribute value for this particular implicit tile will be stored in the ith of the attribute value array. The complex index information of these visible tiles needs to be calculated in advance.

The following is the portion of JSON in a subtree file (without comments):

{
  "tileAvailability": {"bufferView": 0},
  "contentAvailability": {"bufferView": 1},
  "childSubtreeAvailability": {"bufferView": 2},
  "extensions": {
    "3DTILES_metadata": {
      "class": "tile",
      "properties": {
        "horizonOcclusionPoint": {
          "bufferView": 3
        },
        "countries": {
          "bufferView": 4,
          "arrayOffsetBufferView": 5,
          "stringOffsetBufferView": 6
        }
      }
    }
  },
  "buffers": [
    {"byteLength": 99692}
  ],
  "bufferViews": [
    {"buffer": 0, "byteLength": 688, "byteOffset": 0},
    {"buffer": 0, "byteLength": 688, "byteOffset": 688},
    {"buffer": 0, "byteLength": 2048, "byteOffset": 1376},
    {"buffer": 0, "byteLength": 49152, "byteOffset": 3424},
    {"buffer": 0, "byteLength": 24576, "byteOffset": 50528},
    {"buffer": 0, "byteLength": 8196, "byteOffset": 75104},
    {"buffer": 0, "byteLength": 16388, "byteOffset": 83304}
  ]
}

The tile visibility, tile content visibility, and child subtree visibility data are encoded in the binary data pointed to by the three bufferViews 0, 1, and 2, but the buffer of this subtree has 7 bufferViews, of which 3, 4, 5, and 6 bufferViews are used for 3DTILES_metadata.

3DTILES_implicit_tiling specifies the segmentation scheme of tiles and the visibility content encoding of subtrees, so that there is no need to display the information specifying each tile object of each layer in tileset.json, everything can be calculated according to level and tile coordinates. Come.

Similar to the root tile in the previous section, in this cluster of subtrees, the attribute metadata of each implicit tile is implemented from the tile class, but the specific attribute field information is no longer JSON, but encoded It has become binary, so the data pointed to in the properties is the number of the bufferView.

For example, the data of the horizonOcclusionPoint attribute field is stored in bufferViews[3], and the countries attribute field is an indefinite-length string array type, so three values need to be stored, namely the data itself bufferView[4], the bufferView[5] that stores the arrayOffset, and bufferView[6] where stringOffset is stored.

How to store these different types of metadata in binary can refer to the three-dimensional metadata specification - the , as shown in the second example of the Array part, in short, the data itself is a character The byte information of each character of the string, stringOffset is the starting length of each string, and arrayOffset is the starting stringOffset index number of each variable-length string array.

3.4. Content Group Attribute Metadata

Specification references [group.schema.json](), [tileset.3DTILES_metadata.schema.json]() and [metadataEntity.schema.json]()

A Tile may contain more than one data content (refer to 3DTiles Next to extend 3DTILES_multiple_contents), or multiple tile data content can share a metadata. This extension can be used with tiles of multi-tile content.

It makes sense to group attribute metadata. For example, only a part of the data content in a tile has metadata, so only the attribute metadata of the part of the tile content with metadata is recorded; or like a "layer" With tiles with multiple tile content, attribute metadata can be used to control the visualization or styling of the tile's data content.

How does the tile data content allocate the grouped attribute metadata? In the JSON of tile.content, record its extensions.3DTILES_metadata property and assign the group property. Each tile.content can only correspond to one group, but a group can be assigned to any tile.content.

Translator's Note

For each group in a tile, there may be a situation: a class is shared, but the specific attribute metadata of each group is different, and the attribute metadata needs to be recorded for each group separately.

At this time, define another group at the same level of the schema, and each group can specify its class and the properties value specified by the class. Then each content directly records the name of the group, so that the tiles with multiple data contents share a class, but the attribute metadata can be grouped.

Officially, the specific attribute metadata of the group is extracted into groups, rather than directly recorded in the extensions of content. It is estimated that it is for the convenience of decoupling and let the content focus on the content, but the tile records the attribute metadata by itself, which makes the I'm a little confused.

Here is the official example:

{
  "extensions": {
    "3DTILES_metadata": {
      "schema": {
        "classes": {
          "layer": {
            "properties": {
              "name": {"componentType": "STRING", "semantic": "NAME", "required": true},
              "color": {"type": "VEC3", "componentType": "UINT8"},
              "priority": {"componentType": "UINT32"}
            }
          }
        }
      },
      "groups": {
        "buildings": {
          "class": "layer",
          "properties": {
            "name": "Buildings Layer",
            "color": [128, 128, 128],
            "priority": 0
          }
        },
        "trees": {
          "class": "layer",
          "properties": {
            "name": "Trees Layer",
            "color": [10, 240, 30],
            "priority": 1
          }
        }
      }
    }
  },
  "root": {
    "extensions": {
      "3DTILES_multiple_contents": {
        "content": [
          {
            "uri": "buildings.glb",
            "extensions": {"3DTILES_metadata": {"group": "buildings"}}
          },
          {
            "uri": "trees.glb",
            "extensions": {"3DTILES_metadata": {"group": "trees"}}
          }
        ]
      }
    },
    ...
  }
}

This example has a layer class, and the same level as the schema has a groups attribute, which means that the attributes have two groups, one is the buildings attribute, and the other is the trees attribute. Implemented on the specific tile data content, it is the information assigned by the two composite data contents of the root tile, such as content[0] , its uri is "buildings.glb" , and its attribute metadata is assigned to the group buildings

3.5. Deeper Feature-Level Attribute Metadata

3D Tiles only record the structural topology of tiles, but the data content of each tile can still be subdivided into different levels.

This part does not belong to the definition of "tile" in 3D Tiles. It needs to be supplemented in the extension of , namely 161f300cf5b372 EXT_mesh_features extension, which does not conflict with 3DTILES_metadata, both are [3D Metadata Specification] (), but the above four categories belong to the tile level, and further exploration can refine the metadata into glTF primitive, mesh, node and other elements.

4. JSON Schema Definition

• tileset.3DTILES_metadata.schema.json
• tile.3DTILES_metadata.schema.json
• content.3DTILES_metadata.schema.json

Translator's Note

The attribute metadata extension, namely 3DTILES_metadata, first defines "attribute data" on the main spatial entity objects of the 3D Tiles specification, because these spatial entity objects are themselves "three-dimensional data", so these attribute data are actually "data data", i.e. metadata.

In order to better store property data from various fields, this extension designs a Schema { Class { Properties } } template, and then records specific data items on the corresponding spatial entity objects. Schema also allows to specify Enum, which is a characteristic data type in addition to basic data types, arrays, vectors, and matrices.

There are also three data items of Tileset, Group, and Statistics defined at the same level as Schema, which take care of the metadata at the dataset level, the content level of the tile group data, and store the statistics of all classes in the metadata.

The above Schema, Class, Properties, Tileset, Group, Statistics, and Enum all start with uppercase, and do not refer to the field names in JSON. They are just for the sake of good-looking and unified writing.

In order to cooperate with the implicit tile expansion, attribute metadata also has a special encoding format (binary) in the subtree file, especially strings, with more details.

In addition to extending these attribute metadata on the main spatial entity objects of the 3D Tiles specification, attribute metadata can also be defined on the "three-dimensional elements" in the tile data content, but the tile data content is no longer 3D Tiles content, but the content of glTF, tile format. For the glTF format, you need to consult the derived extension specification:

• EXT_mesh_features
• [EXT_gpu_mesh_instancing]()

Including this extension and the above two extensions of glTF, together constitute the arbitrary level specification of the next-generation 3D Tiles attribute metadata, and their formulation also involves two materials:

• 3D Metadata Specification
• 3D Metadata Semantic Reference