Metadaten-Modul

Das Metadaten-Modul stellt Meta-Informationen über die VCDB-Instanz und die darin gespeicherten Stadtobjekte bereit. Die VCDB v5 erzwingt Typ-Sicherheit, was bedeutet, dass jedes Feature in der FEATURE Tabelle und jede Eigenschaft in der PROPERTY Tabelle einen Typ besitzen muss, der im Metadaten-Modul definiert ist. Die vordefinierten Typen des Metadaten-Moduls basieren auf dem CityGML 3.0 Conceptual Model (CM), wodurch die VCDB v5 eine vollständige Implementierung von CityGML 3.0 darstellt. Die CityGML-Versionen 2.0 und 1.0 werden auch weiterhin unterstützt, indem ihre Elemente auf diese vordefinierten Typen abgebildet werden.

Das Metadaten-Modul ist erweiterbar und benutzerdefinierte Feature-Typen und Eigenschaften können jederzeit hinzugefügt werden, um anwendungsspezifische Daten zu speichern, die von CityGML nicht abgedeckt werden. Dadurch bietet die VCDB v5 eine vollständige Unterstützung für den Application Domain Extension (ADE)-Mechanismus von CityGML.

image metadataModule
Figure 1. Metadaten-Modul des relationalen Schemas der VCDB v5.

NAMESPACE Tabelle

Alle Typen und Eigenschaften in der VCDB v5 müssen mit einem Namespace verknüpft sein. Dies hilft, Namenskonflikte zu vermeiden und gruppiert die Inhalte der VCDB v5 logisch gemäß dem CityGML 3.0 Conceptual Model. Die Namespaces werden in der NAMESPACE Tabelle gespeichert und beim Aufsetzen einer VCDB-Instanz mit den folgenden Werten befüllt.

id alias namespace

1

core

http://3dcitydb.org/3dcitydb/core/5.0

2

dyn

http://3dcitydb.org/3dcitydb/dynamizer/5.0

3

gen

http://3dcitydb.org/3dcitydb/generics/5.0

4

luse

http://3dcitydb.org/3dcitydb/landuse/5.0

5

pcl

http://3dcitydb.org/3dcitydb/pointcloud/5.0

6

dem

http://3dcitydb.org/3dcitydb/relief/5.0

7

tran

http://3dcitydb.org/3dcitydb/transportation/5.0

8

con

http://3dcitydb.org/3dcitydb/construction/5.0

9

tun

http://3dcitydb.org/3dcitydb/tunnel/5.0

10

bldg

http://3dcitydb.org/3dcitydb/building/5.0

11

brid

http://3dcitydb.org/3dcitydb/bridge/5.0

12

app

http://3dcitydb.org/3dcitydb/appearance/5.0

13

grp

http://3dcitydb.org/3dcitydb/cityobjectgroup/5.0

14

veg

http://3dcitydb.org/3dcitydb/vegetation/5.0

15

vers

http://3dcitydb.org/3dcitydb/versioning/5.0

16

wtr

http://3dcitydb.org/3dcitydb/waterbody/5.0

17

frn

http://3dcitydb.org/3dcitydb/cityfurniture/5.0

18

depr

http://3dcitydb.org/3dcitydb/deprecated/5.0

Die Namespaces stehen in engem Zusammenhang mit den thematischen Modulen, die im CityGML 3.0 CM definiert sind. Jeder Namespace ist mit einem alias verknüpft, der als Abkürzung für den Namespace dient und eindeutig über alle Einträge in der NAMESPACE Tabelle hinweg sein muss.

Der Namespace depr hat eine besondere Funktion: Er kennzeichnet veraltete Typen und Eigenschaften, die zur Speicherung von Inhalten aus CityGML 2.0 und 1.0 verwendet werden. Da CityGML 3.0 nicht vollständig abwärtskompatibel ist, können solche Inhalte nicht auf vordefinierte Typen und Eigenschaften in anderen Namespaces abgebildet werden. Die Verwendung des depr Namespace stellt sicher, dass veraltete Inhalte gespeichert werden können und damit eine volle Unterstützung von CityGML 2.0 und 1.0 möglich ist.

Die Liste der Namespaces in der NAMESPACE Tabelle ist nicht abschließend und kann durch benutzerdefinierte Namespaces erweitert werden, typischerweise im Rahmen einer Application Domain Extension (ADE). In diesem Fall muss der ade_id Fremdschlüssel auf die in der ADE Tabelle registrierte ADE verweisen, die den Namespace definiert.

OBJECTCLASS Tabelle

Die OBJECTCLASS Tabelle dient als zentrales Register für alle Feature-Typen, die von der VCDB v5 unterstützt werden. Jedes Feature, das in der FEATURE Tabelle gespeichert ist, muss einem Feature-Typ aus dieser Tabelle zugeordnet sein. Beim Aufsetzen einer neuen VCDB-Instanz wird die Tabelle mit Typdefinitionen für alle Feature-Klassen aus dem CityGML 3.0 Conceptual Model (CM) befüllt, einschließlich abstrakter Klassen.

Jeder in der OBJECTCLASS Tabelle registrierte Feature-Typ wird eindeutig durch seinen Namen und Namespace identifiziert, die in den Spalten classname und namespace_id gespeichert sind. Die namespace_id ist ein Fremdschlüssel, der auf einen Namespace in der NAMESPACE Tabelle verweist.

Die Flags is_abstract und is_toplevel legen fest, ob es sich bei dem Feature-Typ um eine abstrakte Klasse handelt bzw. ob der Typ ein Top-Level-Feature ist. Beide Angaben orientieren sich an den Definitionen im CityGML 3.0 CM. Für beide Flags steht der Wert 1 für true und 0 für false.

Abstrakte Feature-Typen dürfen nicht als Typ für Features in der FEATURE Tabelle verwendet werden.

Typvererbung wird durch die Spalte superclass_id abgebildet. Sie funguiert als Fremdschlüssel und verknüpft einen Subtyp mit seinem Supertyp. Die Vererbung ist transitiv, sodass Feature-Typen hierarchisch organisiert werden können.

Die OBJECTCLASS Tabelle kann durch benutzerdefinierte Feature-Typen, typischweise aus einer ADE, erweitert werden. Wie bereits beschrieben, muss der ade_id Fremdschlüssel auf die ADE in der ADE Tabelle verweisen, in welcher der Feature-Typ definiert ist. Es sollte sichergestellt werden, dass für benutzerdefinierte Feature-Typen der korrekte Supertyp angegeben wird.

JSON-basiertes Schema-Mapping

Zusätzlich zu den Typinformationen, die in den oben beschriebenen Spalten gespeichert sind, enthält die Spalte schema ein JSON-basiertes Schema-Mapping. Dieses liefert weitere Details zum Feature-Typ und dessen Abbildung auf das relationale Schema der VCDB v5, einschließlich der Feature-Attribute und ihrer Datentypen.

Das JSON-basierte Schema-Mapping ist entscheidend, um zu verstehen, wie Feature-Typen und ihre Eigenschaften in der VCDB v5 repräsentiert und abgefragt werden. Software-Tools können dieses Mapping automatisch analysieren und interpretieren, um mit der Datenbank zu interagieren.

Das folgende Beispiel zeigt die JSON-Definitionen für den Feature-Typ Road und den allgemeinen Supertyp AbstractObject.

  • tran:Road

  • core:AbstractObject

{
  "identifier": "tran:Road",
  "description": "A Road is a transportation space used by vehicles, bicycles and/or pedestrians.",
  "table": "feature",
  "properties": [
    {
      "name": "class",
      "namespace": "http://3dcitydb.org/3dcitydb/transportation/5.0",
      "description": "Indicates the specific type of the Road.",
      "type": "core:Code"
    },
    {
      "name": "function",
      "namespace": "http://3dcitydb.org/3dcitydb/transportation/5.0",
      "description": "Specifies the intended purposes of the Road.",
      "type": "core:Code"
    },
    {
      "name": "usage",
      "namespace": "http://3dcitydb.org/3dcitydb/transportation/5.0",
      "description": "Specifies the actual uses of the Road.",
      "type": "core:Code"
    },
    {
      "name": "section",
      "namespace": "http://3dcitydb.org/3dcitydb/transportation/5.0",
      "description": "Relates to the sections that are part of the Road.",
      "type": "core:FeatureProperty",
      "target": "tran:Section",
      "relationType": "contains"
    },
    {
      "name": "intersection",
      "namespace": "http://3dcitydb.org/3dcitydb/transportation/5.0",
      "description": "Relates to the intersections that are part of the Road.",
      "type": "core:FeatureProperty",
      "target": "tran:Intersection",
      "relationType": "contains"
    }
  ]
}
{
  "identifier": "core:AbstractObject",
  "description": "AbstractObject is the abstract superclass of all feature and object types.",
  "table": "feature",
  "properties": [
    {
      "name": "id",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the internal database ID of the object.",
      "value": {
        "column": "id",
        "type": "integer"
      }
    },
    {
      "name": "objectId",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the identifier of the object that is unique within the database. Using a globally unique identifier is recommended.",
      "value": {
        "column": "objectid",
        "type": "string"
      }
    },
    {
      "name": "identifier",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies an optional identifier of the object that is globally unique.",
      "value": {
        "column": "identifier",
        "type": "string"
      }
    },
    {
      "name": "codeSpace",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the code space of the identifier, typically a reference to the maintaining authority.",
      "value": {
        "column": "identifier_codespace",
        "type": "string"
      },
      "parent": 1
    },
    {
      "name": "envelope",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the minimum bounding box that encloses the entire object.",
      "value": {
        "column": "envelope",
        "type": "core:Envelope"
      }
    },
    {
      "name": "objectClassId",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the internal object class ID of the object.",
      "value": {
        "column": "objectclass_id",
        "type": "integer"
      }
    },
    {
      "name": "lastModificationDate",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Indicates the date and time at which the object was last updated in the database.",
      "value": {
        "column": "last_modification_date",
        "type": "timestamp"
      }
    },
    {
      "name": "updatingPerson",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the person who last updated the object in the database.",
      "value": {
        "column": "updating_person",
        "type": "string"
      }
    },
    {
      "name": "reasonForUpdate",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the reason for the last update of the object in the database.",
      "value": {
        "column": "reason_for_update",
        "type": "string"
      }
    },
    {
      "name": "lineage",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the lineage information of the object.",
      "value": {
        "column": "lineage",
        "type": "string"
      }
    },
    {
      "name": "description",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies a text description of the object.",
      "type": "core:StringOrRef"
    },
    {
      "name": "descriptionReference",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies a reference to a remote text description of the object.",
      "type": "core:Reference"
    },
    {
      "name": "name",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies a label or identifier of the object, commonly a descriptive name.",
      "type": "core:Code"
    }
  ]
}

Jeder Feature-Typ wird über ein JSON-Objekt beschrieben. Es enthält einen "identifier", der den Namespace-Alias und den Typnamen kombiniert, um eine eindeutige Identifizierung und Referenzierung zu ermöglichen. Zusätzlich besitzt das Objekt eine "description", die eine Definition des Typs auf Basis von CityGML 3.0 bereitstellt. Die "table" Eigenschaft gibt an, in welcher VCDB-Tabelle das Feature gespeichert wird – in der Regel ist dies die FEATURE Tabelle.

Das "properties" Array listet die Eigenschaften (Attribute und Relationen) des Feature-Typs auf, die selbst wieder über eigene JSON-Objekte beschrieben werden. Jede Eigenschaft hat einen "name", der dem Namen der Eigenschaft aus CityGML 3.0 entspricht, sowie einen "namespace", wie in der NAMESPACE Tabelle definiert. Diese Werte müssen für die Spalten name und namespace_id verwendet werden, wenn die Eigenschaft in der PROPERTY Tabelle gespeichert wird. Die CityGML 3.0 Definition der Eigenschaft ist als "description" verfügbar.

Um die vollständige Liste aller Eigenschaften eines bestimmten Feature-Typs zu erhalten, müssen die "properties" aller Supertypen rekursiv mit einbezogen werden.

Es gibt zwei Möglichkeiten, den Datentyp einer Eigenschaft anzugeben:

  1. Über den "type", der auf einen vordefinierten Datentyp aus der DATATYPE Tabelle mittels dessen Identifier verweist (Standardmethode).

  2. Über den "value", wodurch der Datentyp direkt inline im JSON-Objekt definiert wird.

Wird der Datentyp über "type" referenziert, dann beinhaltet dieser Datentyp alle weiteren Details zur Speicherung der Eigenschaft und ihrer Werte (siehe DATATYPE Tabelle). Definiert der Datentyp, dass die Eigenschaft in der PROPERTY Tabelle gespeichert werden soll (Standardverhalten), dann ist sie über die feature_id Spalte der PROPERTY Tabelle mit dem zugehörigen Feature verknüpft.

Beispiele für die Inline-Definition eines Datentyps mittels "value" finden sich im obigen JSON-Mapping von core:AbstractObject. Ein "value" enthält den Namen der Spalte ("column"), in welcher der Wert gespeichert wird, und den zugehörigen datenbank-spezifischen Datentyp ("type"). Standardmäßig wird davon ausgegangen, dass sich die Spalte in derselben Tabelle befindet, die über "table" für den Feature-Typ definiert wurde (siehe oben).

Falls der referenzierte Datentyp ("type") nicht in der PROPERTY Tabelle gespeichert wird oder die Spalte des inline-definierten "value" nicht zur Feature-Tabelle gehört, kann über das "join" bzw. "joinTable" Attribut zusätzlich die Zieltabelle definiert werden, in welcher die Eigenschaft gespeichert werden soll. Bei Verwendung von "join" wird die Zieltabelle direkt angegeben, während bei "joinTable" eine Zwischentabelle involviert ist, über welche die Zieltabelle verknüpft ist.

Das folgende Beispiel zeigt die "join" Definition für die "imageURI" Eigenschaft im Typ core:AbstractTexture:

{
  "name": "imageURI",
  "namespace": "http://3dcitydb.org/3dcitydb/appearance/5.0",
  "description": "Specifies the URI that points to the external texture image.",
  "value": {
    "column": "image_uri",
    "type": "string"
  },
  "join": {
    "table": "tex_image",
    "fromColumn": "tex_image_id",
    "toColumn": "id"
  }
}

Eigenschaften vom Typ core:FeatureProperty oder core:GeometryProperty werden verwendet, um ein Feature mit einem anderen Feature oder einer Geometrie zu verknüpfen. In der JSON-Definition solcher Relationen muss ein zusätzliches Attribut namens "target" enthalten sein. Der Wert von "target" ist der Identifier des referenzierten Feature-Typs bzw. Geometrie-Typs. Die folgenden Eigenschaften "boundary" und "lod1Solid" des Feature-Typs core:AbstractSpace veranschaulichen die Verwendung des "target" Attributs.

  • Feature-Eigenschaft

  • Geometrie-Eigenschaft

{
  "name": "boundary",
  "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
  "description": "Relates to surfaces that bound the space.",
  "type": "core:FeatureProperty",
  "target": "core:AbstractSpaceBoundary",
  "relationType": "contains"
}
{
  "name": "lod1Solid",
  "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
  "description": "Relates to a 3D Solid geometry that represents the space in Level of Detail 1.",
  "type": "core:GeometryProperty",
  "target": "core:AbstractSolid"
}

Zusätzlich zum Attribut "target" definiert eine core:FeatureProperty den Typ der Relation zum Ziel-Feature über das Attribut "relationType", das entweder den Wert relates oder contains annehmen kann. Die Bedeutung und Auswirkungen des Relationen-Typs werden im Zusammenhang mit der PROPERTY Tabelle hier erläutert.

Das VCDB-Softwarepaket enthält eine JSON Schema-Spezifikation, die die zulässige Struktur für das Schema-Mapping von Feature-Typen definiert. Diese Schema-Datei mit dem Namen schema-mapping.schema.json befindet sich im Ordner json-schema des Softwarepakets.

DATATYPE Tabelle

Ähnlich wie die OBJECTCLASS Tabelle für Feature-Typen, dient die DATATYPE Tabelle als Register für alle Datentypen, die von der VCDB v5 unterstützt werden. Alle Attribute und Relationen eines Features, die in der PROPERTY Tabelle gespeichert sind, müssen einen Datentyp aus dieser Tabelle referenzieren. Der Aufbau der DATATYPE Tabelle entspricht dem der OBJECTCLASS Tabelle. Sie wird beim Aufsetzen der VCDB v5 mit Typdefinitionen für alle Datentypen aus dem CityGML 3.0 CM befüllt, einschließlich abstrakter Datentypen.

Jeder in der DATATYPE Tabelle registrierte Datentyp wird eindeutig durch seinen Namen und Namespace identifiziert, die in den Spalten typename und namespace_id gespeichert sind. Die namespace_id ist ein Fremdschlüssel, der auf einen Eintrag in der NAMESPACE Tabelle verweist.

Das Flag is_abstract gibt an, ob es sich bei dem Datentyp um einen abstrakten Typ handelt, basierend auf der entsprechenden Definition im CityGML 3.0 CM. Ein Wert von 1 bedeutet true, und 0 repräsentiert false. Abstrakte Datentypen düfen – analog zu abstrakten Feature-Typen – nicht als Typ für Eigenschaften in der Tabelle PROPERTY verwendet werden.

Typvererbung wird durch die Spalte supertype_id umgesetzt. Sie fungiert als Fremdschlüssel und verknüpft einen Subtyp mit seinem Supertyp. Die Vererbung ist transitiv, sodass Datentypen hierarchisch organisiert werden können.

Die Tabelle DATATYPE kann durch benutzerdefinierte Datentypen erweitert werden. typischerweise aus einer ADE. Wie bei den Feature-Typen muss der ade_id Fremdschlüssel auf die in der ADE Tabelle registrierte ADE verweisen, in welcher der Datentyp definiert ist. Es ist sicherzustellen, dass für benutzerdefinierte Datentypen der korrekte Supertyp angegeben ist.

JSON-basiertes Schema-Mapping

Zusätzlich zu den Typinformationen in den beschriebenen Spalten enthält die Spalte schema ein JSON-basiertes Schema-Mapping für jeden Datentyp. Dieses Schema-Mapping definiert, wie der Datentyp auf das relationale Schema der VCDB v5 abgebildet wird – etwa in welcher Tabelle und Spalte ein Attributwert gespeichert werden muss und welcher datenbank-spezifische Datentyp dafür zu verwenden ist.

Wie bei Feature-Typen ist das JSON-basierte Schema-Mapping entscheidend, um zu verstehen, wie Datentypen und ihre Werte in der VCDB v5 repräsentiert und abgefragt werden. Das JSON-Format kann von Software-Tools einfach analysiert und interpretiert werden, was eine automatische Interaktion mit der Datenbank ermöglicht.

Primitive Datentypen für einfache Attribute – wie Ganzzahlen, Gleitkommazahlen, Zeichenketten oder Zeitstempel – sind wie im folgenden Beispiel für den Typ core:String definiert.

{
  "identifier": "core:String",
  "description": "String is a basic type that represents a sequence of characters.",
  "table": "property",
  "value": {
    "column": "val_string",
    "type": "string"
  }
}

Jeder Datentype verfügt über einen eindeutigen "identifier", der aus dem Namespace-Alias und dem Typnamen zusammengesetzt ist, sowie über eine "description", die die Definition des Typs gemäß CityGML 3.0 enthält. Das Attribut "table" gibt die VCDB-Tabelle an, in der der Datentyp gespeichert wird – in der Regel ist dies die Tabelle PROPERTY. Für einfache Datentypen beschreibt das JSON-Objekt "value", in welcher Spalte ("column") der Attributwert gespeichert wird und welcher datenbank-spezifische Datentyp ("type") dabei verwendet wird.

Neben einfachen Datentypen unterstützt die VCDB auch komplexe Datentypen. Diese können sowohl einen einfachen Wert als auch verschachtelte Eigenschaften enthalten, die wiederum selbst einfache oder komplexe Datentypen haben können.

  • core:Code

  • core:ExternalReference

  • con:Height

{
  "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"
      }
    }
  ]
}
{
  "identifier": "core:ExternalReference",
  "description": "ExternalReference is a reference to a corresponding object in another information system, for example in the German cadastre (ALKIS), the German topographic information system (ATKIS), or the OS UK MasterMap.",
  "table": "property",
  "properties": [
    {
      "name": "targetResource",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the URI that points to the object in the external information system.",
      "type": "core:URI"
    },
    {
      "name": "informationSystem",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies the URI that points to the external information system.",
      "value": {
        "column": "val_codespace",
        "type": "string"
      }
    },
    {
      "name": "relationType",
      "namespace": "http://3dcitydb.org/3dcitydb/core/5.0",
      "description": "Specifies a URI that additionally qualifies the ExternalReference. The URI can point to a definition from an external ontology (e.g. the sameAs relation from OWL) and allows for mapping the ExternalReference to RDF triples.",
      "value": {
        "column": "val_string",
        "type": "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"
      }
    }
  ]
}

Die verschachtelten Eigenschaften eines komplexen Datentyps werden im "properties" Array als separate JSON-Objekte aufgeführt. Jede Eigenschaft besitzt einen "name", der dem Namen aus CityGML 3.0 entspricht, sowie einen "namespace", dessen Wert aus der NAMESPACE Tabelle stammt. Die Definition der Eigenschaft gemäß CityGML 3.0 ist unter "description" angegeben.

Der Datentyp einer verschachtelten Eigenschaft kann auf zwei Arten spezifiziert werden:

  1. Als einfacher Typ, der direkt über das "value" Objekt definiert wird (siehe oben).

  2. Als Referenz auf einen Datentyp aus der DATATYPE Tabelle – hierzu wird das "type" Attribut verwendet, das den "identifier" des Datentyps angibt.

Komplexe Datentypen müssen nicht zwingend einen "value" besitzen, sondern können ausschließlich aus verschachtelten "properties" bestehen (siehe Beispiel core:ExternalReference). Alternativ kann eine der verschachtelten Eigenschaften über einen 0-basierten Index in das "properties" Array als "value" des Datentyps gekennzeichnet werden (siehe Beispiel con:Height).

Standardmäßig wird angenommen, dass sowohl der Wert des komplexen Datentyps als auch alle verschachtelten Eigenschaften in separaten Spalten derselben Zeile der zugehörigen Tabelle ("table") des Datentyps gespeichert werden. Um davon abzuweichen, können die Attribute "join" und "joinTable" verwendet werden, um für verschachtelte Eigenschaften eine andere Zieltabelle zu definieren. Bei Verwendung von "join" wird die Zieltabelle direkt angegeben, während bei "joinTable" eine Zwischentabelle involviert ist, über welche die Zieltabelle verknüpft ist.

Der oben gezeigte Datentyp core:ExternalReference ist ein Beispiel für eine kompakte Repräsentation, bei der alle verschachtelten Eigenschaften in verschiedenen val_* Spalten derselben Zeile in der PROPERTY Tabelle gespeichert werden.

Im Gegensatz dazu ist beim Typ con:Height eine Speicherung in einer einzigen Zeile nicht möglich, da die Datentypen der Unterattribute zum Teil dieselben val_* Spalten verwenden und es damit zu einem Konflikt kommen würde. Daher muss jede verschachtelte Eigenschaft in einer eigenen Zeile von PROPERTY gespeichert und mit der Parent-Zeile verknüpft werden, die den con:Height Datentyp selbst repräsentiert. Für den Standardfall, dass Datentypen in der PROPERTY Tabelle gespeichert werden, wird hierfür ein Self-Join mit der PROPERTY Tabelle über den parent_id Fremdschlüssel definiert (siehe "join" Attribut im Beispiel). Hieraus ergibt sich eine hierarchische Struktur für komplexe Datentypen in der PROPERTY Tabelle. Ein Beispiel zur Speicherung eines Attributs vom Typ con:Height in der PROPERTY Tabelle findet sich hier.

Die vollständige JSON Schema-Spezifikation zur Definition von Datentypen ist in der Datei schema-mapping.schema.json enthalten, die im Ordner json-schema des VCDB-Softwarepakets bereitgestellt wird.

DATABASE_SRS Tabelle

Die DATABASE_SRS Tabelle enthält Informationen über das Koordinatenreferenzsystem (CRS) der VCDB v5-Instanz. Dieses CRS wird während des Aufsetzens der Datenbank festgelegt und gilt für alle in der VCDB gespeicherten Geometrien (mit wenigen Ausnahmen, etwa bei impliziten Geometrien). Die DATABASE_SRS Tabelle enthält nur zwei Spalten mit den folgenden Bedeutungen:

Spalte Beschreibung

srid

Die datenbankspezifische SRID (Spatial Reference ID) des für die VCDB-Instanz definierten CRS. In der Regel entspricht die SRID dem EPSG-Code.

srs_name

Der OGC-konforme Name des CRS. Der srs_name wird beispielsweise beim Export von Daten in CityGML/CityJSON-Dateien verwendet.

Das Koordinatenreferenzsystem kann jederzeit nach dem Aufsetzen der Datenbank mittels der Funktion citydb_pkg.change_schema_srid geändert werden. Eine direkte Änderung der Werte in der Tabelle DATABASE_SRS hat hingegen keine Auswirkung auf die in der Datenbank gespeicherten Geometrien. Weitere Informationen dazu finden sich im Abschnitt zu den Datenbankfunktionen.

ADE Tabelle

Das relationale Schema der VCDB v5 unterstützt das Application Domain Extension (ADE) Konzept von CityGML vollständig und ermöglicht damit die Speicherung anwendungsspezifischer Daten, die über die vordefinierten Feature- und Datentypen von CityGML hinausgehen. Die ADE Tabelle dient als zentrales Register für ADEs, die der Datenbank hinzugefügt werden. Jeder ADE-Eintrag erhält eine eindeutige id als Primärschlüssel. Die Spalten name, version und description enthalten den Namen, die Versionsnummer und eine Beschreibung der ADE als Metadaten.

Im Kontext der VCDB v5 besteht eine ADE aus einer Sammlung benutzerdefinierter Feature-Typen, Datentypen und Namespaces. Diese Erweiterungen sind mit ihrer entsprechenden ADE über den ade_id Fremdschlüssel in den Tabellen OBJECTCLASS, DATATYPE und NAMESPACE verknüpft (Referenz auf die id Spalte der ADE Tabelle).

Obwohl die ADE-Unterstützung im relationalen Schema der VCDB v5 bereits implementiert ist, steht derzeit noch kein Werkzeug zur Verfügung, mit dem sich eine ADE automatisch in der ADE Tabelle registrieren und die zugehörigen Feature-Typen, Datentypen und Namespaces aus dem ADE-Datenmodell ableiten lassen. Auch das mitgelieferte Kommandozeilenwerkzeug vcdb-tool unterstützt aktuell werder den Import noch den Export von ADE-Daten in die VCDB v5. Wir arbeiten bereits an entsprechenden Erweiterungen!