Features - glTFspecdraftimplproposal
Kodierung von CityGML Gebäuden (LoD1, LoD2) in glTF 2.0.
Umfang
Das Modul Features - glTF unterstützt glTF 2.0 als Kodierung für Features. Unterstützt werden die Objektarten Building
und BuildingPart
. Das Modul Features - glTF bietet Unterstützung für glTF 2.0 als Feature-Kodierung. Unterstützt werden die CityGML-Objektarten Building
und BuildingPart
.
Dieses Modul unterstützt die glTF 2.0 Erweiterung KHR_mesh_quantization für eine kompakte Kodierung von Vertices und Normalen. Die Verwendung dieser Erweiterung wird empfohlen und ist standardmäßig aktiviert.
Jede Feature-Eigenschaft, die im glTF-Modell enthalten ist, aktiviert die Unterstützung für die glTF 2.0-Erweiterungen EXT_mesh_features und EXT_structural_metadata. Die Eigenschaften werden in binären Tabellen gespeichert.
Limitierungen
Es gelten die folgenden Einschränkungen:
Nur CityGML-Gebäude und Gebäudeteile in LoD1 und LoD2 werden unterstützt.
- 3D-Metadaten:
- Es werden nur Eigenschaften vom Typ SCALAR, STRING und ENUM unterstützt.
- Arrays werden nicht unterstützt.
- Offset und Skalierung werden nicht unterstützt.
- Standardwerte werden nicht unterstützt.
Konformitätsklassen
Features - glTF implementiert Unterstützung für glTF 2.0 mit den Erweiterungen KHR_mesh_quantization, EXT_mesh_features, und EXT_structural_metadata.
Operationen
Ressource | Pfad | Methoden | Formate | Beschreibung |
---|---|---|---|---|
glTF Schema | collections/{collectionId}/gltf/schema | GET | Die glTF-Schema-Ressource beschreibt die Feature-Eigenschaften und die Aufzählungen, wie sie in den glTF-Modellen für die Feature Collection kodiert sind. Einzelheiten finden Sie in der [3D Metadata Specification] (https://github.com/CesiumGS/3d-tiles/tree/main/specification/Metadata#schema). |
Pfad-Parameter
Name | Ressourcen | Beschreibung |
---|---|---|
collectionId | Features, Feature | Der Identifikator der Feature Collection. |
Query Parameter
Name | Ressourcen | Beschreibung |
---|---|---|
Features - glTF | Features, Feature | Wenn dieser Parameter auf true gesetzt ist, werden die z-Koordinaten jedes Features so verändert, dass der Boden des Features auf dem WGS84-Ellipsoid liegt. Dieser Parameter wirkt sich nur auf glTF-Modelle aus. |
f | glTF Schema | Wählt das Ausgabeformat der Antwort. Wenn kein Wert angegeben wird, gelten die Standard-HTTP Regeln, d.h. der "Accept"-Header wird zur Bestimmung des Formats verwendet. |
Konfiguration
Voraussetzungen
Das Modul erfordert, dass der Feature Provider einen Typ "building" enthält. Die Anforderungen an den Typ sind dieselben wie in der Konfiguration der CityJSON-Kodierung.
Optionen
Name | Default | Beschreibung | Typ | Seit |
---|---|---|---|---|
buildingBlock | Immer GLTF . | string | v2.0 | |
extensionType | Deprecated Siehe buildingBlock . | string | v2.0 | |
enabled | false | Soll das Modul aktiviert werden? | boolean | v2.0 |
transformations | {} | Property-Transformationen erfolgen bei der Aufbereitung der Daten für die Rückgabe über die API. Die Datenhaltung selbst bleibt unverändert. Alle Filterausdrücke (siehe queryables in Features) wirken unabhängig von etwaigen Transformationen bei der Ausgabe und müssen auf der Basis der Werte in der Datenhaltung formuliert sein - die Transformationen sind i.A. nicht umkehrbar und eine Berücksichtigung der inversen Transformationen bei Filterausdrücken wäre kompliziert und nur unvollständig möglich. Insofern sollten Eigenschaften, die queryable sein sollen, möglichst bereits in der Datenquelle transformiert sein. Eine Ausnahme sind typischerweise Transformationen in der HTML-Ausgabe, wo direkte Lesbarkeit i.d.R. wichtiger ist als die Filtermöglichkeit. | object | v2.0 |
meshQuantization | true | Aktiviert die Unterstützung für die glTF 2.0 Erweiterung KHR_mesh_quantization. | boolean | v3.4 |
withNormals | true | Wenn true , werden die Normalen für jeden Punkt berechnet. | boolean | v3.4 |
withOutline | false | Wenn true , werden die Kanten der Polygone in Cesium hervorgehoben. | boolean | v3.4 |
polygonOrientationNotGuaranteed | true | Wenn true , werden Materialien als double-sided definiert. | boolean | v3.4 |
properties | {} | Verwenden Sie diese Option, um anzugeben, welche Feature-Attribute in das glTF-Modell aufgenommen werden sollen. type ist entweder SCALAR , STRING oder ENUM . Für einen Skalar geben Sie den componentType an (siehe 3D Metadata Specification), Standard ist UNIT16 . Für eine Zeichenkette geben Sie den stringOffsetType als UNIT8 , UNIT16 oder UNIT32 an, abhängig von der erwarteten Länge des Text-Buffers, Standard ist UNIT32 . Bei einer Aufzählung muss die Feature-Eigenschaft entweder einen enum -Constraint im Provider-Schema haben oder einen codelist -Constraint, bei dem die Codeliste einen Integer-Code verwendet; geben Sie den componentType entsprechend dem Bereich der Codes an, Standard ist UINT32 . Darüber hinaus kann ein Sentinel-Wert mit noData angegeben werden (siehe 3D Metadata Specification für weitere Einzelheiten). | object | v3.4 |
withSurfaceType | false | Wenn true , wird für Gebäude in Level-of-Detail 2 mit Informationen über die Semantik jeder Oberfläche (Wand, Dach, etc.) wird automatisch eine weitere Eigenschaft "surfaceType" hinzugefügt, die für jeden Vertex verfügbar ist. | boolean | v3.4 |
maxMultiplicity | 3 | Wenn die Daten abgeflacht sind und das Feature-Schema Arrays enthält, werden maxMultiplicity Eigenschaften für jede Array-Eigenschaft erstellt. Wenn eine Instanz mehrere Werte in einem Array hat, werden nur die ersten Werte in die Daten aufgenommen. | number | v3.4 |
Beispiele
- buildingBlock: GLTF
enabled: true
withNormals: true
polygonOrientationNotGuaranteed: true
meshQuantization: true
properties:
gml_id:
type: STRING
stringOffsetType: UINT16
noData: ''
function:
type: STRING
stringOffsetType: UINT16
noData: ''
roofType:
type: ENUM
componentType: UINT16
noData: 0
name:
type: STRING
stringOffsetType: UINT16
noData: ''