Geometrie-Modul

Explizite Geometrien werden über Realwelt-Koordinaten beschrieben und in der geometry Spalte gespeichert. Diese Spalte verwendet einen vordefinierten räumlichen Datentyp des zugrunde liegenden Datenbanksystems. Alle Geometrien müssen mit 3D-Koordinaten angegeben werden, deren Werte dem Koordinatenreferenzsystem (CRS) entsprechen müssen, das für die VCDB-Instanz festgelegt wurde. Um effiziente räumliche Abfragen zu ermöglichen, ist die geometry Spalte standardmäßig indiziert.

Die Verbindung zwischen einem Stadtobjekt in der FEATURE Tabelle und seiner Geometrie erfolgt über eine Geometrie-Property in der PROPERTY Tabelle. Zusätzlich enthält die GEOMETRY_DATA Tabelle einen Fremdschlüssel feature_id, der auf das zugehörige Feature verweist. Damit sind bidirektionale Abfragen möglich – vom Feature zu den zugehörigen Geometrien oder umgekehrt.

Implizite Geometrien werden in der implicit_geometry Spalte der GEOMETRY_DATA Tabelle gespeichert. Im Gegensatz zu expliziten Geometrien verwenden implizite Geometrien lokale Koordinaten, wodurch sie als Template für mehrere Stadtobjekte in der Datenbank dienen können. Aus diesem Grund werden sie in einer eigenen Spalte gespeichert und nicht in der geometry Spalte. Da implizite Geometrien nicht eindeutig einem einzelnen Feature zugeordnet sind, wird der Wert der feature_id Spalte auf NULL gesetzt. Stattdessen werden sie über die IMPLICIT_GEOMETRY Tabelle referenziert.

Aufgrund der lokalen Koordinaten werden implizite Geometrien typischerweise nicht für räumliche Abfragen verwendet. Die implicit_geometry Spalte ist daher standardmäßig nicht indiziert.

Die Nutzund der vordefinierten räumlichem Datentypen zur Speicherung sowohl expliziter als auch impliziter Geometrien bringt zwei zentrale Herausforderungen mit sich:

Frühere Versionen der VCDB haben dies gelöst, indem flächenhafte Geometrien in ihre einzelnen Polygone zerlegt wurden, die dann zusammen mit einem eindeutigen Identifier in jeweils eigenen Zeilen gespeichert wurden. Über eine hierarchische Tabellenstruktur wurden die Einzelpolygone entsprechend ihrem ursprünglichen Geometrietyp logisch gruppiert. Diese Lösung ermöglichte zwar eine effiziente Referenzierung, hatte aber den Nachteil, dass Geometrien für räumliche Abfragen zur Laufzeit erst wieder zusammengestzt werden mussten. Dadurch wurden diese Abfragen langsamer und weniger effizient. Weiterhin erhöhte die Lösung den Speicherbedarf und war nur für flächenhafte Geometrien umgesetzt, nicht jedoch für Punkte oder Linien.

Die VCDB v5 löst dieses Problem, indem die gesamte Geometrie ohne weitere Zerlegung direkt in einem der vordefinierten räumlichen Datentypen gespeichert wird. Damit wird die Performance räumlicher Abfragen erheblich verbessert und der Speicherbedarf deutlich reduziert. Um dennoch die Wiederverwendbarkeit und Referenzierbarkeit von Geometrien und ihrer Bestandteile zu ermöglichen und die unterschiedlichen CityGML-Geometrietypen zu unterstützen, werden zusätzlich JSON-basierte Metadaten in der Spalte geometry_properties gespeichert.

Die Struktur und Verwendung dieser Metadaten wird im Folgenden anhand der Speicherung einer CityGML Solid-Geometrie in PostgreSQL/PostGIS veranschaulicht. Der hierfür erforderliche PostGIS-spezifische räumliche Datentyp ist POLYHEDRALSURFACE Z, der ein einfaches Array von Polygonen speichert. Das folgende Beispiel zeigt, wie ein Einheitswürfel bestehend aus sechs Polygonen als POLYHEDRALSURFACE Z repräsentiert wird. Die äquivalente Solid-Geometrie in CityGML wird in einem zweiten Tab gegenübergestellt.

Im Gegensatz zur POLYHEDRALSURFACE Z in PostGIS enthält die CityGML Solid-Geometrie eine zusätzliche Shell, die die aus den Polygonen gebildete äußere Hülle des Volumnes repräsentiert. Darüber hinaus verfügen sowohl der Solid, die Shell als auch jedes einzelne Poylgon über einen eigenen Identifier (gml:id), die eine Wiederverwendung der Bestandteile sowie die Zuweisung von Texturen und Farben ermöglichen. Das folgende JSON-Objekt kodiert diese zusätzlichen Metadaten und verknüpft sie mit der POLYHEDRALSURFACE Z Repräsentation:

Die Metadaten werden wie folgt interpretiert: Die Eigenschaft "type" des JSON-Objekts klassifiziert die Geometrie als Solid (type = 9), mit einer eindeutigen "objectId" von "mySolid". Das "children" Array listet alle Bestandteile des Solid auf und stellt eine hierarchische Beziehung zwischen ihnen her. Das erste Element im "children" Array repräsentiert die äußere Hülle der Volumengeometrie (type = 6) und hat den Identifier "myOuterShell". Gemäß der Definition in ISO 19107 fungiert die äußere Hülle als Container, verweist jedoch nicht direkt auf eine bestimmte Geometrie innerhalb der POLYHEDRALSURFACE Z.

Die weiteren sechs Einträge im "children" Array repräsentieren die einzelnen Polygone (type = 5), aus denen die äußere Hülle besteht. Jedes Polygon besitzt eine eigene eindeutige "objectId". Das "parent" Attribut enthält einen 0-basierten Verweis auf einen Eintrag im "children" Array und definiert darüber das übergeordnete Element des jeweiligen Kindelements. In diesem Beispiel bedeutet der Wert 0, dass alle Polygone zur äußeren Hülle gehören. Der "geometryIndex" ist ein 0-basierter Index, der das Kindelement mit einem bestimmten Polygon innerhalb der POLYHEDRALSURFACE Z verknüpft, die in der geometry Spalte gespeichert ist.

Die folgende Tabelle listet alle Geometrietypen auf, die über die JSON-Metadaten unterstützt und beschrieben werden können. Für jeden Typ sind der entsprechende Wert des "type" Attributs sowie die zuläassigen Kindelemente angegeben:

Zusätzlich zu den zuvor beschriebenen Eigenschaften "objectId", "type" und "children" kann das JSON-Metadatenobjekt auch die "is2D" Eigenschaft enthalten. Wenn "is2D" auf true gesetzt ist, muss die Geometrie als zweidimensional interpretiert werden. Dennoch muss sie weiterhin mit 3D-Koordinaten in der geometry Spalte gespeichert werden (z.B. mit einem Höhenwert von 0). Werkzeuge, die die Geometrie verarbeiten, können die Höhenkoordinaten ignorieren, wenn "is2D" gesetzt ist.

Darüber hinaus kann jedes Element im "children" Array eine "isReversed" Eigenschaft besitzen. Dieses Flag zeigt an, ob die Koordinaten des Elements beim Import umgekehrt wurden, um die Orientierung zu invertieren. Dies kann beispielsweise beim Import von CityGML-Daten auftreten, die orientierbare Primitive wie gml:OrientableSurface enthalten, deren orientation Attribut auf "-" gesetzt ist. Anhand der "isReversed" Eigenschaft können solche (Teil-)Geometrien wieder als orientierbares Primitiv exportiert werden.