Appearance-Modul

Das Appearance-Modul ermöglicht die Speicherung und Zuweisung von Texturen und Farben zu flächenhaften Geometrien in der VCDB v5. Es setzt das CityGML Appearance-Konzept um, bei dem Appearances als Container für Oberflächendaten (Surface Data) fungieren, die den Geometrien von Stadtobjekten zugewiesen werden, um deren visuelle und beobachtbare Eigenschaften zu definieren.

image appearanceModule
Figure 1. Appearance-Modul des relationalen Schemas der VCDB v5.

APPEARANCE Tabelle

Die APPEARANCE Tabelle ist die zentrale Komponente des Appearance-Moduls. Jeder Eintrag in dieser Tabelle repräsentiert eine eindeutige Appearance. Obwohl Appearance in CityGML als Feature- Typ definiert ist, werden Appearances nicht in der FEATURE Tabelle gespeichert. Dies liegt daran, dass Appearances visuelle und beobachtbare Eigenschaften von Oberflächen definieren und somit konzeptuell unterschiedlich zu Stadtobjekten und räumlichen Features sind, die in der FEATURE Tabelle gespeichert werden.

Die Spalten objectid, identifier und identifier_codespace in der APPEARANCE Tabelle dienen der Speicherung von eindeutigen Identifiern eines Appearance-Objekts und erfüllen denselben Zweck wie in der FEATURE Tabelle. Die objectid ist ein String-Identifier, der zur eindeutigen Referenzierung eines Appearance-Objeks 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 Appearance-Objeks zwischen verschiedenen Systemen und potenziell mehreren Versionen. Ü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.

Jede Appearance ist mit einem bestimmten Theme für ihre Oberflächendaten verknüpft, das in der Spalte theme als String gespeichert wird. Geometrien können Oberflächendaten aus unterschiedlichen Themes zugewiesen werden. Ein NULL-Wert für theme ist zulässig.

Appearances können auf drei Arten mit Features oder impliziten Geometrien verknüpft werden:

  1. Lokale (feature-spezifische) Appearances: Eine Appearance kann als Eigenschaft eines Features gespeichert werden, dessen Geometrien über die Appearance Texturen oder Farben zugewiesen werden. Die Verbindung zwischen einem Feature in der FEATURE Tabelle und der zugehörigen Appearance erfolgt über eine entsprechende Appearanc-Property in der PROPERTY Tabelle. Die APPEARANCE Tabelle enthält zusätzlich einen feature_id Fremdschlüssel, der auf das Feature verweist. Dadurch sind bidirektionale Abfragen zwischen einem Feature und seinen Appearances möglich.

  2. Implizite Geometrien: Eine Appearance kann einer impliziten Geometrie zugewiesen sein, die als Vorlage für mehrere Features dient (z.B. ein 3D-Baummodell, das von mehreren Baum-Objekten verwendet wird). In diesem Fall verweist die Appearance über den Fremdschlüssel implicit_geometry_id auf den zugehörigen Eintrag in der IMPLICIT_GEOMETRY Tabelle.

  3. Globale Appearances: Eine Appearance kann mehreren Geometrien von verschiedenen Stadtobjekten gemeinsam zugewiesen werden. Da solche Appearances nicht nur für ein einzelnes Feature gelten, werden sie in CityGML als globale Appearances bezeichnet. Um eine Appearance als global zu kennzeichnen, muss is_global auf 1 (true) gesetzt werden und sowohl feature_id als auch implicit_geometry_id müssen NULL sein. Globale Appearance dürfen nicht von einzelnen Features über eine Appearance-Property in der PROPERTY Tabelle referenziert werden.

Die Speicherung globaler Appearances in der Datenbank sollte vermieden werden, da sie den Aufwand der Datenverwaltung beträchtlich erhöhen und die Export-Performance negativ beeinflussen. Das mit der VCDB ausgelieferte vcdb-tool wandelt globale Appearances deshalb beim Datenimport automatisch in lokale Appearances um.

SURFACE_DATA Tabelle

Die SURFACE_DATA Tabelle speichert Oberflächendaten wie Texturen und Farben. Diese Oberflächendaten werden über die APPEAR_TO_SURFACE_DATA Tabelle mit einer Appearance verknüpft, die eine n:m-Beziehung (viele-zu-viele) herstellt.

Die folgenden Arten von Oberflächendaten werden unterstützt:

  • X3DMaterial: Repräsentiert ein Oberflächenmaterial und wird typischerweise zur Definition von Farben oder einfachen Materialeigenschaften verwendet.

  • ParameterizedTexture: Eine Textur, die über Texturkoordinaten oder eine lineare Transformation definiert, wie die Textur auf die Zieloberfläche angewandt wird.

  • GeoreferencedTexture: Eine Textur, die eine planimetrische Projektion und einen Raumbezug nutzt, um die Textur auf die Zieloberfläche abzubilden.

Die Spalte objectclass_id bestimmt den Typ der Oberflächendaten und fungiert als Fremdschlüssel zur OBJECTCLASS Metadatentabelle.

Alle Oberflächendaten-Arten nutzen die Spalten objectid, identifier und identifier_codespace zur Speicherung von eindeutigen Identifiern, so wie bereits für die APPEARANCE Tabelle beschrieben. Zusätzlich gibt die is_front Spalte an, ob die Oberflächendaten auf die Vorderseite (is_front = 1) oder Rückseite (is_front = 0) der referenzierten Flächengeometrie angewandt werden sollen.

Die übrigen Spalten der SURFACE_DATA Tabelle werden abhängig vom jeweiligen Typ der Oberflächendaten befüllt.

Speicherung von Materialeigenschaften

Die x3d_* Spalten definieren Materialeigenschaften gemäß dem Typ X3DMaterial.

Spalte Beschreibung

x3d_shininess

Gibt die Schärfe des Spiegelglanzes an (0..1).

x3d_transparency

Definiert die Transparenz des Materials (0.0 = undurchsichtig, 1.0 = vollständig transparent).

x3d_ambient_intensity

Gibt den minimalen Prozentsatz der diffusen Farbe an, der unabhängig von Lichtquellen sichtbar ist (0..1).

x3d_specular_color

Setzt die Farbe der Spiegelreflexion im Hex-Format (#RRGGBB).

x3d_diffuse_color

Definiert die Farbe der diffusen Reflexion im Hex-Format (#RRGGBB).

x3d_emissive_color

Gibt die Farbe der Eigenemission (Selbstbeleuchtung) im Hex-Format (#RRGGBB) an.

x3d_is_smooth

Gibt an, ob das Material glatt (1) oder facettiert (0) ist.

Speicherung von Textureigenschaften

Textureigenschaften, die sowohl von ParameterizedTexture als auch von GeoreferencedTexture gemeinsam genutzt werden, werden in den tex_* Spalten gespeichert. Das zugehörige Texturbild wird in der TEX_IMAGE Tabelle abgelegt und über den tex_image_id Fremdschlüssel referenziert, sodass mehrere Textur-Objekte dasselbe Texturbild verwenden können.

Spalte Beschreibung

tex_texture_type

Definiert den Typ der Textur (specific, typical, unknown).

tex_wrap_mode

Legt fest, wie Texturen gekachelt werden (none, wrap, mirror, clamp, border).

tex_border_color

Definiert die Randfarbe der Textur im Hex-Format (#RRGGBBAA).

Speicherung von georeferenzierten Textureigenschaften

Die Orientierung und der Raumbezug, die spezifisch für GeoreferencedTexture sind, werden in den gt_* Spalten gespeichert.

Spalte Beschreibung

gt_orientation

Rotation und Skalierung des georeferenzierten Texturbildes als 2x2-Matrix, gespeichert als JSON-Array in zeilenweiser (Row-Major) Reihenfolge.

gt_reference_point

Definiert den 2D-Punkt, der das Zentrum des oberen linken Bildpixels in Weltkoordinaten repräsentiert.

SURFACE_DATA_MAPPING Tabelle

Die SURFACE_DATA_MAPPING Tabelle weist Oberflächendaten zu Geometrien zu, indem ein Eintrag aus der SURFACE_DATA Tabelle über die Fremdschlüssel surface_data_id und geometry_data_id mit der Zielgeometrie in der GEOMETRY_DATA Tabelle verknüpft wird.

Oberflächendaten werden typischerweise einzelnen Polygonen zugewiesen. Allerdings können die Geometrien in der GEOMETRY_DATA Tabelle auch komplexere Strukturen wie MultiPolygone oder Volumenkörper (Solids) repräsentieren. Diese Geometrien werden mit Hilfe der vordefinierten, räumlichen Datentypen der Datenbank gespeichert, die keine direkte Referenzierung einzelner Teile der Geometrie unterstützen. Um Oberflächendaten dennoch gezielt bestimmten Polygonen innerhalb solcher Geometrien zuzuweisen, werden die JSON-basierten Metadaten verwendet, die zusammen mit der Geometrie in GEOMETRY_DATA gespeichert sind. Diese Metadaten listen die einzelnen Bestandteile der Geometrie auf und weisen ihnen einen eindeutigen "objectId" Identifier zu, wodurch die Polygone innerhalb der Geometrie eindeutig referenzierbar werden.

Weitere Informationen zu den JSON-basierten Metadaten für Geometrien in der GEOMETRY_DATA Tabelle finden Sie hier.

Abhängig vom Typ der Oberflächendaten wird eine spezifische Zuordnung (Mapping) verwendet, um sie der Geometrie zuzuweisen. Diese Zuordnungen werden auch als JSON-Objekte definiert und in den entsprechenden Spalten der SURFACE_DATA_MAPPING Tabelle gespeichert. Die folgenden Beispiele zeigen die verschiedenen Mapping-Typen und deren Speicherung.

Zuweisung von Materialien

Zur Zuweisung eines X3DMaterial muss das JSON-Mapping die "objectId" Identifier der Ziel-Polygone als Attribute auflisten. Ein Wert von true gibt an, dass das X3DMaterial auf die entsprechende Oberfläche angewendet werden soll. Polygone, die das Material nicht erhalten sollen, können entweder weggelassen oder explizit mit false versehen werden. Das JSON-Mapping für Materialien wird in der material_mapping Spalte gespeichert.

Das folgende Beispiel weist ein X3DMaterial den Polygonen mit den Identifiern surface_A und surface_D innerhalb der Zielgeometrie zu.

{
  "surface_A": true,
  "surface_D": true
}

Zuweisung von Texturen über Texturkoordinaten

Eine ParameterizedTexture wird üblicherweise zugewiesen, indem Texturkoordinaten für alle Koordinaten des Ziel-Polygons angegeben werden. Jede Texturkoordinate (s, t) ist eine 2D-Position im Texturraum, der immer den Bereich von (0,0) bis (1,1) abdeckt – unabhängig von tatsächlicher Größe oder Seitenverhältnis des Texturbildes. Die linke untere Ecke des Texturbildes entspricht (0,0).

Im JSON-Mapping werden Texturkoordinaten als Double-Arrays [s,t] gespeichert. Die Texturkoordinaten für den äußeren Ring eines Polygons werden in einem weiteren Array gruppiert. Falls das Polygon Innenringe hat, werden separate Arrays nach demselben Muster für jeden Innenring angegeben. Alle Arrays für die einzelnen Ringe werden schließlich in einem weiteren Array zusammengefasst.

Ähnlich wie bei der Zuweisung von Materialien listet das JSON-Objekt die "objectId" Identifier der Ziel-Polygone auf und orndet ihnen das Array mit den Texturkoordinaten zu. Das Textur-Mapping wird in der texture_mapping Spalte gespeichert.

Das folgende Beispiel zeigt das Textur-Mapping für die Polygone surface_B und surface_C der Ziel-Geometrie. surface_B hat sowohl einen Außen- als auch einen Innenring, während surface_C nur einen Außenring besitzt.

{
  "surface_B": [
    [ [0.0, 0.5], [0.7, 0.3], …, [0.0, 0.5] ], // Außenring
    [ [0.1, 0.3], [0.6, 0.4], …, [0.1, 0.3] ]  // Innenring
  ],
  "surface_C": [
    [ [0.3, 0.5], [0.1, 0.1], …, [0.3, 0.5] ]  // Außenring
  ]
}
Regeln für Texturkoordinaten:

  • Für jede Koordinate in jedem Ring eines Polygon muss eine Texturkoordinate angegeben werden – auch für die letzte Koordinate, die den Ring abschließt und typischerweise mit der ersten Koordinate identisch ist.

  • Texturkoordinaten müssen in derselben Reihenfolge aufgelistet werden wie die Koordinaten des zugehörigen Rings.

  • Für jedes Polyon müssen Texturkoordinaten für den äußeren Ring angegeben werden. Falls Innenringe vorhanden sind, müssen auch für jeden Innenring Texturkoordinaten zugewiesen werden – und zwar in derselben Reihenfolge, wie die Ringe im Polygon auftreten.

Zuweisung von Texturen über lineare Transformationen

Alternativ kann eine ParameterizedTexture über eine 3x4-Transformationsmatrix zugewiesen werden, die Weltkoordinaten in Texturkoordinaten überführt. Die Matrix wird im JSON-Mapping als Array im Row-Major-Format gespeichert. Die Matrix-basierte Textur-Mappings werden in der world_to_texture_mapping Spalte gespeichert.

Das folgende Beispiel zeigt ein Textur-Mapping anhand einer 3x4-Transformationsmatrix für das Polygon surface_E.

{
  "surface_E": [
    -0.4, 0.0, 0.0, 183550.0,
     0.0, 0.0, 0.3333, -37.3333,
     0.0, 0.0, 0.0, 1.0
  ]
}

Zuweisung von georeferenzierten Texturen

Da die Orientierung und der Raumbezug einer GeoreferencedTexture bereits in der SURFACE_DATA Tabelle gespeichert sind, genügt es für ihre Zuweisung aus, die entsprechenden "objectId" Identifier der Ziel-Polygone aufzulisten und mit dem Wert true zu versehen – analog zur Zuweisung von Materialien. Polygone, die keine Textur erhalten sollen, werden entweder mit false belegt oder weggelassen. Textur-Mappings für georeferenzierte Texturen werden in der georeferenced_texture_mapping Spalte gespeichert.

{
  "surface_F": true,
  "surface_G": true
}

  • Wenn ein Mapping Identifier enthält, die nicht in den JSON-Metadaten der Zielgeometrie vorhanden sind, gilt das Mapping für diesen Identifier als ungültig.

  • Die JSON Schema-Spezifikationen für jedes Mapping sind im VCDB-Softwarepaket enthalten und befinden sich im Verzeichnis json-schema. Die Schema-Dateien sind nach den jeweiligen Spalten benannt (z.B. texture-mapping.schema.json).

TEXTURE_IMAGE Tabelle

Texturbilder für sowohl ParameterizedTexture als auch GeoreferencedTexture können als Binärdaten (Binary Blobs) in der image_data Spalte der TEX_IMAGE Tabelle gespeichert werden. In diesem Fall kann die Spalte image_uri den Dateinamen oder den ursprünglichen Pfad des Texturbildes enthalten. Soll das Texturbild nicht direkt in der Datenbank gespeichert werden, wird die image_data Spalte auf NULL gesetzt. In diesem Fall muss image_uri eine URI enthalten, die auf den Speicherort des Texturbildes verweist, von dem es abgerufen werden kann (z.B. eine externe URL).

Die Spalte mime_type gibt den MIME-Typ des Texturbildes an, um sicherzustellen, dass das Bild gemäß seinem Format korrekt verarbeitet werden kann (z.B. image/png für ein PNG-Bild oder image/jpeg für ein JPEG-Bild). Zusätzlich kann die Spalte mime_type_codespace einen optionalen Code-Space für den MIME-Typ speichern, um weitere Informationen zur Klassifizierung oder zum Kontext bereitzustellen.