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.

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 |
|
2 |
dyn |
|
3 |
gen |
|
4 |
luse |
|
5 |
pcl |
|
6 |
dem |
|
7 |
tran |
|
8 |
con |
|
9 |
tun |
|
10 |
bldg |
|
11 |
brid |
|
12 |
app |
|
13 |
grp |
|
14 |
veg |
|
15 |
vers |
|
16 |
wtr |
|
17 |
frn |
|
18 |
depr |
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:
-
Über den
"type"
, der auf einen vordefinierten Datentyp aus derDATATYPE
Tabelle mittels dessen Identifier verweist (Standardmethode). -
Ü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:
-
Als einfacher Typ, der direkt über das
"value"
Objekt definiert wird (siehe oben). -
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 |
---|---|
|
Die datenbankspezifische SRID (Spatial Reference ID) des für die VCDB-Instanz definierten CRS. In der Regel entspricht die SRID dem EPSG-Code. |
|
Der OGC-konforme Name des CRS. Der |
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!
|