Feature-Modul

Das Feature-Modul definiert die Tabellen zur Speicherung von Stadtobjekten, einschließlich ihrer Attribute und Relationen zu anderen Features, Geometrien und Appearances. Es bietet ein schlankes und dennoch mächtiges Framework, das alle in CityGML definierten Objektarten abbildet.

image featureModule
Figure 1. Feature-Modul des relationalen Schemas der VCDB v5.

FEATURE Tabelle

Die FEATURE Tabelle ist die zentrale Tabelle im relationalen Schema der VCDB v5. Sie dient als primärer Speicherort für alle Stadtobjekte und eindeutig identifizierbaren Objekte wie Gebäude, Straßen oder Vegetationsobjekte innerhalb des Stadtmodells.

Jedem Feature wird eine eindeutige id als Primärschlüssel zugewiesen. Die objectid ist ein String-Identifier, der zur eindeutigen Referenzierung eines Features innerhalb der Datenbank und von Datensätzen verwendet wird. Es wird empfohlen, einen global eindeutigen Wert für objectid zu verwenden und sicherzustellen, dass diese Spalte immer befüllt ist. Die identifier Spalte bietet einen weiteren, optionalen Identifier zur eindeutigen Unterscheidung des Features zwischen verschiedenen Systemen und potenziell mehreren Versionen desselben Realwelt-Objekts. Über den Code-Space in der identifier_codespace Spalte wird die Autorität referenziert, die für die Vergabe und Verwaltung des identifier verantwortlich ist.

Die objectclass_id erzwingt den Typ bzw. die Objektart des Features, wie Gebäude, Fenster, Stadtmobiliar oder Baum. Sie dient als Fremdschlüssel zur OBJECTCLASS Tabelle, die alle von der VCDB-Instanz unterstützten Feature-Typen enthält.

Die bi-temporalen Zeitstempel-Paare creation_date und termination_date sowie valid_from und valid_to ermöglichen die Verwaltung einer Objekt-Historie. Die creation_date und termination_date Attribute beziehen sich auf die Datenbankzeit und geben an, wann das Feature in die Datenbank eingefügt bzw. gelöscht wurde, während valid_from und valid_to die Lebensdauer des Features in der realen Welt definieren. Das creation_date wird automatisch befüllt, sobald das Feature erstmals in die VCDB importiert wird, es sei denn, der Eingabedatensatz enthält bereits einen entsprechenden Zeitstempel. Das termination_date kann als Flag verwendet werden, um anzuzeigen, dass die Version des Features untergegangen und damit nicht mehr aktuell ist, ohne das Feature physisch aus der Datenbank löschen zu müssen.

Die Spalten last_modification_date, updating_person, reason_for_update und lineage sind spezifisch für die VCDB und sind nicht in CityGML definiert. Sie erfassen Metadaten über den Ursprung des Features, seine Aktualisierungshistorie, sowie die für Änderungen verantwortlichen Personen und Aktualisierungsgründe.

Die envelope Spalte speichert das minimale 3D-Rechteck, welches das Stadtobjekt komplett umschließt. Diese Spalte kann für effiziente räumliche Abfragen von Features verwendet werden.

PROPERTY Tabelle

Die PROPERTY Tabelle ist der zentrale Ort für die Speicherung der Eigenschaften (Attribute und Relationen) von Stadtobjekten in der VCDB. Jede Eigenschaft wird mit ihrem Namen, Namespace, Datentyp und Wert erfasst. Dieses flexible und erweiterbare Design erlaubt es, neue Eigenschaften hinzuzufügen, ohne das zugrunde liegende Datenbankschema anpassen zu müssen. Eigenschaften können sowohl Attribute als auch Relationen sein, die Feature, Geometrien und Appearances miteinander verknüpfen.

Welche Eigenschaften sind für ein bestimmtes Feature verfügbar?

Wie oben beschrieben, muss jedem Feature ein Feature-Typ aus der OBJECTCLASS Tabelle zugewiesen werden. Diese Tabelle enthält pro Feature-Typ eine JSON-basierte Typdefinition, die die verfügbaren Eigenschaften des Features beschreibt. Zusätzlich enthält sie Informationen zur Vererbung, sodass auch geerbte Eigenschaften von übergeordneten Feature-Typen abgefragt werden können. Weitergehende Informationen finden sich im Metadaten-Modul.

Der Name und Namespace der Eigenschaft werden in den Spalten name bzw. namespace_id gespeichert. Die namespace_id ist ein Fremdschlüssel, der auf einen Namespace aus der NAMESPACE Tabelle verweist. Jede Eigenschaft ist über den feature_id Fremdschlüssel mit dem zugehörigen Feature in der FEATURE Tabelle verknüpft.

Die Spalte datatype_id erzwingt den Datentyp der Eigenschaft und referenziert eine Typdefinition aus der DATATYPE Tabelle. Der Wert der Eigenschaft wird abhängig von ihrem Datentyp in einer oder mehreren val_* Spalten gespeichert.

Einfache und komplexe Attribute

Einfache Attributwerte wie Ganzzahlen, Gleitkommazahlen, Zeichenketten oder Zeitstempel werden in den Spalten val_int, val_double, val_string oder val_timestamp abgelegt. Boolesche Werte werden ebenfalls in der val_int Spalte gespeichert, wobei 0 für false und 1 für true steht. Array-Werte von Attributen werden als JSON-Arrays in der val_array Spalte abgebildet. Die Elemente eines JSON-Arrays können einfache Attribute, JSON-Objekte oder selbst wieder JSON-Arrays sein.

In der val_content Spalte können beliebige Inhalte als Character-Blob gespeichert werden, während val_content_mime_type den zugehörigen MIME-Typ angibt. Dies kann dazu verwendet werden, Werte im Originalformat aus dem Eingabedatensatz zu speichern (z.B. GML/XML oder JSON).

Die PROPERTY Tabelle unterstützt auch komplexe Attribute, die neben einem einfachen Wert auch verschachtelte Unterattribute mit eigenen einfachen oder komplexen Datentypen enthalten können. Lassen sich sowohl der Attributwert als auch alle Unterattribute auf die vorhandenen val_* Spalten abbilden, kann das gesamte komplexe Attribut in einer einzigen Zeile gespeichert werden. Ein Beispiel hierfür ist ein Messwert mit zugehöriger Einheit: Der Messwert wird in val_double, die Einheit in val_uom gespeichert.

Reicht eine einzelne Zeile nicht mehr aus, um ein komplexes Attribut vollständig abzubilden, wird dessen Struktur hierarchisch innerhalb der PROPERTY Tabelle dargestellt. Unterattribute verweisen über den parent_id Fremdschlüssel auf das übergeordnete Attribut. Diese rekursive Struktur ermöglicht die Darstellung von Hierarchien mit beliebiger Tiefe, und damit die Speicherung von beliebig komplexen Attributen.

Relationen

Zusätzlich zu Attributen speichert die PROPERTY Tabelle auch Relationen, die definieren, wie ein Feature mit anderen Objekten verknüpft ist. Jede Relation wird in einer separaten Zeilen gespeichert und darf nicht gemeinsam mit anderen Attributwerten in einer Zeile stehen.

Relationen zu anderen Features werden durch die feature_id Spalte abgebildet, welche auf das verknpüfte Feature in der FEATURE Tabelle verweist. Der Typ der Relation wird über die val_relation_type Spalte als Integer-Wert kodiert:

  • 0 steht für "relates" (eine allgemeine Assoziation zwischen zwei Features), und

  • 1 steht für "contains" (eine Subfeature-Beziehung, bei der das referenzierte Feature als Bestandteil des übergeordneten Features betrachtet wird).

Der Relationstyp hat funktionale Auswirkungen. Beispielsweise werden Subfeatures, die über eine "contains"-Beziehung eingebunden sind, beim Löschen des Eltern-Features automatisch mitgelöscht. Bei "relates"-Beziehungen ist das nicht der Fall (siehe Löschfunktionen).

Geometrien sind über die val_geometry_id Spalte mit ihrem Feature verknüpft, die auf einen Eintrag in der GEOMETRY_DATA Tabelle verweist. Das optionale val_lod Attribut gibt dabei den Level of Detail (LoD) der Geometrie an.

Implizite Geometrien werden über den val_implicitgeom_id Fremdschlüssel referenziert und sind ebenfalls in der GEOMETRY_DATA Tabelle gespeichert. Zusätzlich zu val_lod werden die Transformationsmatrix und der Referenzpunkt, die zur Definition der impliziten Repräsentation des Features benötigt werden, in val_array und val_implicitgeom_refpoint gespeichert.

Appearance- und Adressinformationen werden über die val_appearance_id und val_address_id Fremdschlüssel referenziert, die auf Einträge in den Tabellen APPEARANCE bzw. ADDRESS verweisen.

Beispiele

In welchen Spalten stehen die Werte von Feature-Eigenschaften?

Die PROPERTY Tabelle ist typsicher, da jeder Eigenschaft ein spezifischer Datentyp zugewiesen wird, der in der DATATYPE Tabelle definiert ist. Diese Tabelle enthält für alle Attribute und Relationen eine JSON-basierte Typdefinition, die eindeutig festlegt, in welcher val_* Spalte der Wert gespeichert wird und ob verschachtelte Unterattribute vorhanden. Jedes Unterattribut besitzt wiederum einen eigenen Datentyp mit entsprechender Typdefinition. Weitergehende Informationen finden sich im Metadaten-Modul.

Das folgende Beispiel erläutert anhand des name Attributs von Stadtobjekten, wie Feature-Eigenschaften in der PROPERTY Tabelle basierend auf ihrem Datentyp gespeichert werden. Das name Attribut hat gemäß CityGML den Datentyp core:Code. Es handelt sich um eine Zeichenkette, die den Namen enthält. Optional kann ein codeSpace Attribut auf ein Wörterbuch oder eine andere Definition für den Namen verweisen. Die zugehörige JSON-Typdefinition in der DATATYPE Tabelle spezifiert, wie der Wert und das Unterattribut codeSpace gespeichert werden:

{
  "identifier": "core:Code",
  "description": "Code is a basic type for a string-based term, keyword, or name that can additionally have a code space.",
  "table": "property",
  "value": {
    "column": "val_string",
    "type": "string"
  },
  "properties": [
    {
      "name": "codeSpace",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the code space of the term, typically a dictionary, thesaurus, classification scheme, authority, or pattern for the term.",
      "value": {
        "column": "val_codespace",
        "type": "string"
      }
    }
  ]
}

Basierend auf dieser Typdefinition wird der Attributwert von core:Code als String in der val_string Spalte gespeichert. Das verschachtelte codeSpace Attribut ist ebenfalls ein String und wird auf die val_codespace Spalte gemappt. Da die Typdefinition keine explizite Verknüpfung zwischen codeSpace und dem übergeordneten Attribut über die parent_id verlangt, werden beide Werte in derselben Zeile der PROPERTY Tabelle gespeichert. Nachfolgend ist eine beispielhafte Abbildung des Attributs auf die PROPERTY Tabelle dargestellt. Zur besseren Übersicht sind nur die relevanten Spalten der Tabelle aufgeführt.

id name parent_id val_string val_codespace …​

1

"name"

NULL

"myBuilding"

"https://example.org/buildings"

…​

Das height Attribut von CityGML-Gebäuden hat den Datentyp con:Height und dient als Beispiel für ein komplexeres Attribut. Die zugehörige JSON-Typdefinition in der DATATYPE Tabelle ist wie folgt aufgebaut:

  • con:Height

  • core:Measure

  • core:String

{
  "identifier": "con:Height",
  "description": "Height represents a vertical distance (measured or estimated) between a low reference and a high reference.",
  "table": "property",
  "value": {
    "property": 0
  },
  "properties": [
    {
      "name": "value",
      "namespace": "http://3dcitydb.org/3dcitydb/construction/5.0",
      "description": "Specifies the value of the height above or below ground.",
      "type": "core:Measure",
      "join": {
        "table": "property",
        "fromColumn": "id",
        "toColumn": "parent_id"
      }
    },
    {
      "name": "status",
      "namespace": "http://3dcitydb.org/3dcitydb/construction/5.0",
      "description": "Indicates the way the height has been captured.",
      "type": "core:String",
      "join": {
        "table": "property",
        "fromColumn": "id",
        "toColumn": "parent_id"
      }
    },
    {
      "name": "lowReference",
      "namespace": "http://3dcitydb.org/3dcitydb/construction/5.0",
      "description": "Indicates the low point used to calculate the value of the height.",
      "type": "core:Code",
      "join": {
        "table": "property",
        "fromColumn": "id",
        "toColumn": "parent_id"
      }
    },
    {
      "name": "highReference",
      "namespace": "http://3dcitydb.org/3dcitydb/construction/5.0",
      "description": "Indicates the high point used to calculate the value of the height.",
      "type": "core:Code",
      "join": {
        "table": "property",
        "fromColumn": "id",
        "toColumn": "parent_id"
      }
    }
  ]
}
{
  "identifier": "core:Measure",
  "description": "Measure is a basic type that represents an amount encoded as double value with a unit of measurement.",
  "table": "property",
  "value": {
    "column": "val_double",
    "type": "double"
  },
  "properties": [
    {
      "name": "uom",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the unit of measurement of the amount.",
      "value": {
        "column": "val_uom",
        "type": "string"
      }
    }
  ]
}
{
  "identifier": "core:String",
  "description": "String is a basic type that represents a sequence of characters.",
  "table": "property",
  "value": {
    "column": "val_string",
    "type": "string"
  }
}

Gemäß der Typdefinition besizt con:Height vier verschachtelte Attribute:

  1. "value" vom Typ core:Measure: Repräsentiert eine Messung, deren Wert in val_double und deren Einheit in val_uom gespeichert wird.

  2. "status" vom Typ core:String: Ein einfacher String, gespeichert in val_string.

  3. "lowReference" vom Typ core:Code: Wie bereits oben beschrieben, wird der Attributwert als String in val_string gespeichert. Der optionale codeSpace wird in val_codespace vorgehalten.

  4. "highReference" vom Typ core:Code: Wird auf dieselbe Weise wie lowReference repräsentiert.

Alle vier Unterattribute besitzen eine "join" Definition, die sie über den parent_id Fremdschlüssel mit dem gemeinsamen übergeordneten Attribut verknüpft. Damit ensteht eine hierarchische Struktur, und jedes Unterattribut muss in einer separaten Zeile gespeichert werden. Alle vier Unterattribute befinden sich auf derselben Hierarchieebene und referenzieren diesselbe id des Elternattributs. Da con:Height keinen eigenen "value" hat, enthalten alle val_* Spalten der übergeordneten Zeile den Wert NULL.

id name parent_id val_string val_double val_uom val_codespace …​

1

"height"

NULL

NULL

NULL

NULL

NULL

…​

2

"value"

1

NULL

11.0

"m"

NULL

…​

3

"status"

1

"measured"

NULL

NULL

NULL

…​

4

"lowReference"

1

"lowestGroundPoint"

NULL

NULL

"https://references.org/heights"

…​

5

"highReference"

1

"highestRoofEdge"

NULL

NULL

"https://references.org/heights"

…​

ADDRESS Tabelle

Obwohl Address in CityGML ein Feature-Typ ist, werden Adressen nicht in der FEATURE Tabelle gespeichert, sondern in einer eigenen ADDRESS Tabelle des relationalen Schemas der VCDB. Adressinformationen sind für sich relevante Daten und dienen oft als Grundlage für spezialisierte Such- und Ortungsdienste. Die Speicherung von Adressen in einer separaten Tabelle ermöglicht daher die effiziente Indizierung sowie dedizierte Abfragen und Updates ohne Auswirkungen auf die FEATURE Tabelle, die selbst eine große Anzahl von Stadtobjekten und weiteren Features enthalten kann.

Die Spalten objectid, identifier und identifier_codespace der ADDRESS Tabelle dienen der Speicherung eindeutiger Identifier für ein Adressobjekt und werden wie die entsprechenden Spalten der FEATURE Tabelle verwendet (siehe oben). Die eigentlichen Adressinformationen werden dann auf die folgenden Spalten abgebildet:

Spalte Beschreibung

street

Speichert den Straßennamen der Adresse.

house_number

Speichert die Hausnummer.

po_box

Speichert das Postfach der Adresse (falls vorhanden).

zip_code

Enthält die Postleitzahl oder den ZIP-Code der Adresse.

city

Speichert den Namen der Stadt oder der Ortschaft.

state

Enthält den Namen des Staates, der Provinz oder Region.

country

Speichert den Namen des Landes, in dem sich die Adresse befindet.

free_text

Ermöglicht die Speicherung von Adressinformationen als unstrukturierter Freitext. Kann verwendet werden, um die anderen strukturierten Felder zu ergänzen oder zu ersetzen.

multi_point

Speichert die Geolokation einer Adresse als MultiPoint-Geometrie und ermöglicht effiziente räumliche Abfragen und Reverse Geocoding.

Zusammen bieten diese Spalten eine umfassende und flexible Struktur für die Speicherung von Adressdaten in verschiedenen Formaten und Kontexten. Wenn jedoch die ursprünglichen Adressinformationen komplexer sind und erhalten werden müssen, kann die content Spalte verwendet werden, um die Adressdaten in ihrem ursprünglichen Format als Character-Blob abzulegen. In diesem Fall spezifiert die content_mime_type Spalte den MIME-Typ des Inhalts.

Die MultiPoint-Geometrie einer Adresse muss im selben Koordinatenreferenzsystem (CRS) vorliegen, das für die gesamte VCDB-Instanz definiert ist.