75
3D-Geodatenbank Berlin Dokumentation V1.0 Institut für Kartographie und Geoinformation der Universität Bonn Prof. Dr. Lutz Plümer Dr. Thomas H. Kolbe Dr. Gerhard Gröger Jörg Schmittwilken Viktor Stroh lat/lon Gesellschaft für raumbezogene Informationssysteme mbH Dr. Andreas Poth Ugo Taddei

3D-Geodatenbank Berlin · 3D-Geodatenbank Berlin Dokumentation V1.0 Institut für Kartographie und Geoinformation der Universität Bonn Prof. Dr. Lutz Plümer Dr. Thomas H. Kolbe

  • Upload
    lamcong

  • View
    237

  • Download
    0

Embed Size (px)

Citation preview

3D-Geodatenbank Berlin

Dokumentation V1.0

Institut für Kartographie und Geoinformation der Universität Bonn

Prof. Dr. Lutz Plümer

Dr. Thomas H. Kolbe

Dr. Gerhard Gröger

Jörg Schmittwilken

Viktor Stroh

lat/lon Gesellschaft für raumbezogene Informationssysteme mbH

Dr. Andreas Poth

Ugo Taddei

3D-Geodatenbank Berlin

i

Inhaltsverzeichnis 1 Einleitung 11.1 Features 11.2 System- und Entwurfsentscheidungen 3 2 Datenmodellierung 52.1 UML-Diagramm der 3D-Stadtmodellierung 52.1.1 Basisklassen 52.1.2 Geometriemodell und Texturen 72.1.3 Generische Objekte und Prototypen 92.1.4 Gebäudemodell 102.1.5 Digitales Geländemodel 122.1.6 Orthophotos 142.2 Relationales Datenbankschema 152.2.1 Abbildungsregeln, Schemakonventionen 152.2.2 Rasterdatenverwaltung mit Oracle 10g Spatial 172.2.3 Datenbankschema 18 3 Versions- und Historienverwaltung 353.1 Konzept der Versionen und CityModelAspects 353.2 Umsetzung in Oracle 383.2.1 AddPlanning 403.2.2 UpdatePlanning 413.2.3 DiscardPlanning 413.2.4 AcceptPlanning 413.2.5 AddPlanningAlternative 423.2.6 UpdatePlanningAlternative 423.2.7 DiscardPlanningAlternative 423.2.8 GetDiff 433.2.9 GetAllDiff 433.2.10 GetConflicts 433.2.11 GetAllConflicts 443.2.12 RefreshPlanningAlternative 443.2.13 DeleteAllPlanningAlternatives 443.2.14 DeleteTermPlanningAlternatives 443.2.15 AddCityModelAspect 453.2.16 DeleteCityModelAspect 453.2.17 AddPAtoCMA 453.2.18 RemovePAfromCMA 463.2.19 DeleteAllCityModelAspects 463.3 Administrationsprogramm „PlanningManager“ 463.3.1 Planungen 473.3.2 Planungsalternativen 483.4 Das Menü Extras 503.5 Konfliktmanagement 513.5.1 Differenzen 513.5.2 Konflikte 513.6 Nutzung in Anwendungsprogrammen 51

3D-Geodatenbank Berlin Inhaltsverzeichnis

ii

4 Werkzeug für den Datenimport und –export 524.1 Systemvoraussetzungen 524.2 Benutzerschnittstelle 524.2.1 Der Login-Dialog 534.3 Import 544.3.1 Konzept zum Importieren von Shapefiles 544.3.2 Durchführung des Shapefile-Imports 554.3.3 Import von Rasterdaten 554.4 Export 574.4.1 Export von Shapefiles 574.4.2 Export von Rasterdaten 584.5 Erläuterung der Import-Konvertierungsprozeduren 584.5.1 REALIT_MULTIPATCH 584.5.2 RSS_GRUNDRISSE_MPATCH 604.5.3 RSS_BUILDING_MPATCH 624.5.4 EXTRUDE-Prozedur 64 5 Nutzungsbeispiele 655.1 Direkter Zugriff über SQL 655.2 Java-Schnittstelle 67

3D-Geodatenbank Berlin

1

1 Einleitung

Dieses Dokument beschreibt den Aufbau und die Bestandteile der 3D-Geodatenbank zur Speicherung und Verwaltung des virtuellen 3D-Stadtmodells von Berlin. Sie wurde vom Institut für Kartographie und Geoinformation der Universität Bonn (IKG) in Kooperation mit der Fa. lat/lon GmbH im Auftrag der Berliner Senatsverwaltung für Wirtschaft, Arbeit und Frauen und der Berlin Partner GmbH (ehemals Wirtschaftsförderung Berlin International) entwickelt.

Das der Datenbank zugrunde liegende Anwendungsschema orientiert sich an der Modellie-rung von CityGML, dem Austauschformat für 3D-Stadtmodelle, das von der Special-Interest-Group 3D (SIG 3D) der Initiative Geodateninfrastruktur NRW (GDI NRW) derzeit entwickelt und standardisiert wird. Von den in CityGML enthaltenen Konzepten wurde die DGM-, Ge-bäude- und Gruppierungsmodellierung vollständig für die Level-of-Detail-Stufen 1-3 umge-setzt. Für weitere, auch künftig zu ergänzende Objektarten unterstützt die Datenbank die ge-nerische Repräsentation beliebiger Geoobjekte des Stadtraumes.

1.1 Features • Unterstützung dreier unterschiedlicher Arten von Mehrfachrepräsentationen:

Levels-of-Detail, Planungsversionen und Historie. Jedes Geoobjekt sowie das DGM und die Luftbilder können in drei verschiedenen Auflösungs- bzw. Genauigkeitsstufen (Levels-of-Detail, LoD) gespeichert werden. Mit aufsteigendem LoD erhalten Objekte nicht nur eine genauere und feinere Geometrie, sondern erfahren auch eine themati-sche Verfeinerung.

Das Versions- und Historienmanagement erfolgt unter Verwendung des Oracle Work-space Managers und ist weitgehend transparent für Anwendungsprogramme, die mit der Datenbank arbeiten. Zur Administration von Planungsgebieten und den darin ent-haltenen Planungsvarianten wurde das Werkzeug „PlanningManager“ entwickelt, das der 3D-Geo-DB beiliegt. Ferner werden in der Datenbank gespeicherte Prozeduren (Stored Procedures) bereit gestellt, die Anwendungsprogrammen die bequeme Admi-nistration von Planungsalternativen bzw. Versionen ermöglichen.

• Implementierung auf Basis von Oracle 10g Spatial. Für die Repräsentation aller Vektor- und Rastergeometrien wird ausnahmslos auf die von Oracle Spatial zur Ver-fügung gestellten Datentypen zurückgegriffen. Damit werden projektbezogene Spezi-allösungen vermieden. Verschiedene Geoinformations- und Architektursoftwaresys-teme erlauben zudem den direkten Zugriff auf in Oracle gespeicherte Geometrie-Objekte und können darüber unmittelbar auf die Daten der 3D-Geodatenbank zugrei-fen.

• Komplexe Digitale Geländemodelle: DGMs können in der 3D-Geodatenbank auf vier unterschiedliche Weisen repräsentiert werden: regelmäßige Raster, unregelmäßige Dreiecksvermaschungen (TINs), 3D-Massenpunkte und 3D-Bruchkanten. Für jeden Level-of-Detail kann ein komplexes DGM definiert werden, das sich aus einer belie-bigen Zahl von DGM-Komponenten und –Typen zusammensetzt. Dabei ist es ist mög-lich, bestimmte Arten der DGM-Repräsentation für das gleiche geographische Gebiet miteinander zu kombinieren (z.B. Massenpunkte und Bruchkanten oder Raster und Bruchkanten). Rasterbasierende DGMs können beliebig groß sein und werden mit Hil-fe der Oracle 10g GeoRaster-Funktionalität aus Einzelkacheln zu einem Gesamtraster zusammengesetzt.

3D-Geodatenbank Berlin 1. Einleitung

2

• Verwaltung großer Luftbilder: Es können beliebig große Luftbilder gespeichert und verwaltet werden. Mit Hilfe der Oracle 10g GeoRaster-Funktionalität können geka-chelte, homogene Einzelbilder in der Datenbank zu einem Gesamtbild aggregiert wer-den und blattschnittfreie Ausschnitte ausgegeben werden.

• Differenzierte Gebäudemodellierung: Gebäude können in der 3D-Geodatenbank von einem Grobmodell bis hin zu geometrisch und semantisch sehr fein ausmodellier-ten Strukturen verwaltet werden. Das zugrunde liegende Datenmodell setzt die Ci-tyGML-Modellierung für Gebäude vollständig von Level-of-Detail 1 bis 3 um. Ge-bäude können durch einfache, monolithische Objekte repräsentiert werden oder sich aus einer beliebig tiefen Aggregation von Gebäudeteilen zusammensetzen. Gebäude-anbauten wie Balkone und Treppen können genauso wie die einzelnen Flächen thema-tisch klassifiziert werden und mit Sachattributen versehen werden. Dies erlaubt es u.a. die Gebäudegrundflächen als solche zu markieren, damit diese später zur Ableitung von SmartBuildings oder zur Herleitung einer neuen Extrusionsgeometrie etc. ver-wendet werden kann.

Gebäude können Adressen zugeordnet werden, die auch in der 3D-Geo-DB gespei-chert werden. Zur Modellierung von Gebäudekomplexen können Gebäude zu speziel-len Gebäudegruppen aggregiert werden.

• Repräsentation generischer und prototypischer 3D-Objekte: Generische Objekte erlauben die Speicherung und Verwaltung von 3D-Geoobjekten, die keine Gebäude sind wie z.B. Straßenmöbel, Brücken, Vegetationsobjekte o.ä. oder nur in einem prop-rietären Dateiformat vorliegen. Damit können unmittelbar Dateien aus anderen Soft-waresystemen wie Architektur- oder Grafikprogrammen (uninterpretiert) in die Da-tenbank importiert werden. Anwendungssysteme, die diese Daten nutzen möchten, müssen allerdings in der Lage sein, diese Dateiformate nach dem Auslesen aus der 3D-Geodatenbank interpretieren zu können.

Prototypische Objekte dienen zur speichereffizienten Verwaltung von Objekten, die in großer Zahl im Stadtmodell vorkommen und sich dabei in ihrer Geometrie und Er-scheinungsform nicht unterscheiden. Beispiele sind Straßenmöbel wie Laternen, Ver-kehrsschilder oder Bänke, können aber auch Vegetationsobjekte wie Sträucher, be-stimmte Baumtypen o. ä. umfassen. Jede Instanz eines prototypischen Objekts kann für jeden Level-of-Detail auf ein eigenes Prototyp-Objekt verweisen.

Die Geometrien (und Erscheinungsformen wie Texturen, Farben etc.) sowohl von ge-nerischen Objekten als auch Prototypen können entweder als Oracle-Spatial-Objekte oder in proprietären Dateiformaten gespeichert werden. In letzterem Fall kann für je-des Objekt eine eigene Datei gespeichert werden, wobei der Dateityp (MIME-Typ), die Koordinatentransformationsmatrix zur Einpassung des Objekts in das Weltkoordi-natensystem sowie das Zielkoordinatensystem der Transformation mit angegeben werden muss.

• Erweiterbare Objektattributierung: Alle Objekte in der 3D-Geodatenbank können mit beliebig vielen zusätzlichen generischen Attributen ergänzt werden. Damit ist es möglich, den Objekten jederzeit weitere Sachinformationen sowie auch weitere räum-liche Eigenschaften hinzuzufügen. In Verbindung mit dem Konzept der generischen 3D-Objekte ergibt sich damit eine sehr flexible Speicherungsmöglichkeit neuer Ob-jektarten, die im Datenmodell nicht explizit ausmodelliert sind. Jedes zusätzliche Att-ribut besteht aus einem Tripel von Attributname, Datentyp und Wert. Die unterstütz-ten Datentypen sind dabei: String, Ganz- und Fließkommazahlen, Datum und Uhrzeit,

3D-Geodatenbank Berlin 1. Einleitung

3

Binärobjekt (BLOB, z.B. zur Speicherung einer Datei), Oracle-Spatial-Geometrie oder texturierbare 3D-Volumenkörper und 3D-Flächen(aggregate).

• Freie, auch rekursive Gruppierung von Geoobjekten: Geoobjekte können beliebig gruppiert werden, wobei die Aggregate benannt werden können und selber wieder Geoobjekte darstellen. Als solche dürfen sie auch mit beliebigen weiteren Attributen versehen werden (s.o.). Objektgruppen dürfen als Bestandteile auch Objektgruppen besitzen, wodurch eine beliebig tiefe Aggregationstiefe ermöglicht wird. Zu jedem Objekt einer Gruppierung kann noch explizit die Rolle angegeben werden, die es in der Gruppe spielt (qualifizierbare Assoziation).

• Externe Verweise für alle Geoobjekte: Alle Geoobjekte können mit beliebig vielen Verweisen auf korrespondierende Objekte in externen Datenquellen versehen werden. Damit können z.B. zu den Gebäuden die IDs der entsprechenden ALK- oder später auch ALKIS-Objekte gespeichert werden. Jeder Verweis besteht aus der Bezeichnung des externen Datenbestands (z.B. ALK) und der darin verwendeten Objekt-ID.

• Flexible 3D-Geometrien: Die Geometrie von Gebäuden und generischen 3D-Objek-ten kann durch die Kombination von Volumenkörpern und Flächen sowie einer belie-bigen, auch rekursiven Aggregation davon repräsentiert werden. Die Flächen können auf beiden Seiten unterschiedlich texturiert oder eingefärbt sein und beinhalten auch Transparenzinformationen. Weitere Geometrietypen (beliebige Oracle-Spatial-Geo-metrie) können den Geoobjekten durch die Verwendung generischer Attribute hinzu-gefügt werden.

• Programm zum Import und Export von Shapefiles und Rasterdaten: Für die 3D-Geo-DB wurde ein Werkzeug entwickelt, das den Import und Export von Raster-DGMs, Luftbildern und 3D-Shapefiles ermöglicht. Mit Hilfe des Werkzeugs können beliebige Ausschnitte des in der Datenbank gehaltenen Gesamt-DGMs bzw. Gesamt-luftbilds in Form georeferenzierter TIFF-Bilder blattschnittfrei ausgegeben werden. Da beim Import von Geoobjekten wie z.B. Gebäuden aus verschiedenen Systemen die konkrete Struktur der Shapefiles i.d.R. unterschiedlich ist, wurde ein flexibler Konver-tierungsmechanismus realisiert: Die Interpretation der in den Shapefiles enthaltenen Daten wird durch in der Datenbank gespeicherte Prozeduren realisiert. Mitgeliefert werden Prozeduren zum Import der Gebäude aus den Shapefiles der Fa. Real.IT sowie der Fa. RSS. Weitere Prozeduren für andere Shapefile-Typen können der Datenbank später hinzugefügt werden. Auf diese Weise könnten künftig auch z.B. Digitale Ge-ländemodelle in Form von Dreiecksvermaschungen (TINs) über Shapefiles importiert werden.

• Automatische Propagierung von Änderungen: In der 3D-Geodatenbank realisierte Trigger-Mechanismen sorgen dafür, dass bei Änderungen von Geometrien diese – wo nötig – an alle mit dem Objekt in Relation stehenden Geoobjekte weiter propagiert werden. Dies ist z.B. sinnvoll zur automatischen Aktualisierung der BoundingBox al-ler Geoobjekte, in denen ein Objekt mit geänderter Geometrie enthalten ist.

1.2 System- und Entwurfsentscheidungen Die 3D-Geodatenbank wird unter Verwendung von Oracle Spatial 10g realisiert. Neben vie-len allgemeinen Gründen, die für die Verwendung eines kommerziellen und weit verbreiteten Relationalen Datenbankmanagementsystems (RDBMS) sprechen, bietet Oracle Spatial 10g die folgenden speziellen Leistungsmerkmale, die eine effiziente Implementierung der benötig-ten Funktionalitäten erst ermöglichen:

3D-Geodatenbank Berlin 1. Einleitung

4

• Oracle Spatial 10g unterstützt räumliche Datentypen von 2D bis 4D. Die meisten Ope-rationen und Selektionsfilter berücksichtigen bislang zwar nur die ersten beiden Di-mensionen der Geometriekoordinaten, allerdings reichen die unterstützten räumlichen 3D-Indizes bereits für die am häufigsten benötigten Selektionskriterien aus. Der Spati-al-Datentyp wird zudem auch unmittelbar von kommerziellen GIS, die eine DB-Anbindung ermöglichen wie z.B. ArcGIS/ArcSDE der Fa. ESRI, unterstützt, so dass ein solches System auch direkt auf die 3D-Geo-DB zugreifen könnte.

• Das Oracle RDBMS stellt in der Version 10g Methoden zur effizienten Verwaltung sehr umfangreicher georeferenzierter Rasterdaten zur Verfügung. Damit ist es mög-lich, das gesamte DGM sowie das gesamte Luftbild von Berlin jeweils als ein homo-genes Objekt ohne Kachelung in der Datenbank zu speichern.

• Mit dem Workspace Manager stellt Oracle eine umfassende Komponente zum Versi-ons- und Historienmanagement bereit. Dieses erfolgt weitgehend transparent für die Anwendungen, die mit der Datenbank arbeiten.

• Mit Hilfe von Stored Procedures und Trigger-Mechanismen können Regeln imple-mentiert werden, die Änderungen an Objekten an davon ebenfalls betroffene Objekte in der Datenbank (transparent für den Benutzer) propagieren.

Nach der Entscheidung über die Verwendung von Oracle Spatial 10g wurden noch die fol-genden Entwurfsentscheidungen gefällt:

• Die Abbildung des objektorientierten Datenmodells auf eine Oracle-Datenbank erfolgt als relationales Schema. Über die Verwendung der Oracle Spatial Datentypen hinaus kommen keine objektrelationalen Modellierungsmöglichkeiten von Oracle zum Ein-satz, da diese in der Version 10g nicht in Verbindung mit dem Oracle Workspace Ma-nager genutzt werden können. Ein weiterer Grund, der für die Verwendung einer rein relationalen Modellierung spricht, ist die Möglichkeit, die 3D-Geo-DB künftig direkt an kommerzielle GIS-Systeme wie ArcGIS (unter Verwendung von ArcSDE) anzu-koppeln, die alle nur relationale Datenbankstrukturen unterstützen.

• Gekachelt vorliegende, homogen strukturierte Rasterdaten (Luftbilder, Digitales Ge-ländemodell) werden in der Datenbank zu jeweils einem Rasterdatenobjekt aggregiert. Konkret bedeutet dies, dass aus allen Luftbild- bzw. DGM-Kacheln ein einziges Ras-terobjekt erzeugt wird. Dieses Vorgehen erlaubt die effiziente und blattschnittfreie Ausgabe beliebiger geographischer Ausschnitte durch eingebaute Funktionen des Ora-cle RDBMS. Nutzer der Geodatenbank brauchen sich dadurch nicht mit der bei der Datenerfassung durchgeführten Kachelung auseinander zu setzen.

• Der zur Verwaltung von Rasterdaten verwendete Datentyp GeoRaster ist in Oracle ob-jektrelational implementiert. GeoRaster-Objekte können deshalb (derzeit) nicht unter die Kontrolle des Versionsmanagements gestellt werden (s.o.). Aus diesem Grund sind in der 3D-Geodatenbank die Luftbilder sowie rasterbasierende Digitale Geländemo-delle bislang nicht versionierbar. Luftbilder und DGMs können zwar geändert werden, die Änderungen wirken sich aber unmittelbar auf alle Versionen des Stadtmodells aus. Aus der Sicht der Speichereffizienz wäre die Versionierung von Rasterdaten jedoch ohnehin problematisch zu bewerten, da jede (noch so kleine) Änderung an einem Luft-bild oder dem DGM das Anlegen einer Versionskopie des mehrere Gigabytes großen Objektes zur Folge hätte.

3D-Geodatenbank Berlin

5

2 Datenmodellierung 2.1 UML-Diagramm der 3D-Stadtmodellierung In diesem Abschnitt wird das 3D-Stadtmodell auf der abstrakten Ebene graphischer UML-Klassendiagramme beschrieben. Diese bilden die Grundlage für die implementierungsabhän-gige Realisierung des Modells mit relationalen Datenbanksystemen, die im folgenden Ab-schnitt 2.2 dargelegt wird. UML-Diagramme können aber auch die Basis für andere Imple-mentierungen bilden, z.B. für die Definition eines Austauschformats basierend auf XML oder GML. Die einzelnen UML-Diagramme des 3D-Stadtmodells sind in den Abbildungen 2.1 bis 2.4 und 2.6 wiedergegeben.

2.1.1 Basisklassen Die Basisklasse aller thematischen Objekte des Stadtmodells – z.B. Gebäude, Gebäudeteile, Wände, Fenster, Orthophotos, Dreiecksnetz - ist die Klasse CityObject (vgl. Abb. 2.1). Alle diese thematischen Objekte verfügen somit über die Basisfunktionalität der Klasse CityOb-ject, die in diesem Abschnitt beschrieben wird. Ein CityObject verfügt zunächst über Metadaten in Form einer BoundingBox, die die unge-fähre Lage des Objekts durch den umschreibenden dreidimensionalen Quader angibt, wo-durch das Auffinden von Objekten unterstützt wird. Die Bounding Box wird durch die ISO 19107-Klasse GM_Envelope realisiert. Weiterhin können zu einem CityObject Bezüge auf Vorkommen desselben Realweltobjekts in anderen Datenbanken oder Datenbeständen ange-ben werden (Fremdbezug, ExternalReference). Diese Bezüge können für Datenverknüpfun-gen, oder die Bereitstellung ergänzender Angaben genutzt werden. Ein Gebäude kann z.B. einen Fremdbezug zu dem entsprechenden Katasterobjekt in ALK/ALKIS haben, über den Eigentümerinformationen bezogen werden können. Ein Fremdbezug besteht aus der Angabe des fremden Systems, z.B. ALK/ALKIS oder ATKIS, und der ID des Objekts in diesem Sys-tem. Fremdbezüge sind optional, ein Cityobjekt kann über mehrere Fremdbezüge verfügen. Die Attribute der Klasse CityObject dienen zur Aufnahme weiterer Metadaten. Im einzelnen sind dies:

• das Datum der Erzeugung des Objekts in der Datenbank (creationDate)

• das Löschdatum in der Datenbank (terminationDate)

• das letzte Änderungsdatum in der Datenbank (lastModificationDate)

• Angaben zur Person, die diese Änderung veranlasst hat (updatingPerson)

• der Grund dieser aktuellsten Änderung (reasonForUpdate)

• Angaben zur Herkunft der Daten (lineage) Bis auf das Erzeugungsdatum sind alle diese Attribute optional.

3D-Geodatenbank Berlin 2. Datenmodellierung

6

Abbildung 2.1: UML-Diagramm der Basisklassen sowie der Prototypen und generischen Objekte

3D-Geodatenbank Berlin 2. Datenmodellierung

7

CityObjects können nach beliebigen, benutzerdefinierten Kriterien zu Gruppen zusammenge-fasst werden. Eine CityObjectGroup setzt sich aus beliebig vielen CityObjects zusammen. Beispiele für die Nutzung einer CityObjectGroup wären alle Gebäude in einem bestimmten Stadtteil, oder alle Kirchen. Eine Gruppe kann einen Namen (z.B. „Kirchen in Moabit“) und einen Typ (z.B. „Sehenswürdigkeiten“) haben, sowie eine Beschreibung. Die Rolle, die ein CityObject in einer Gruppierung spielt, kann durch den Rollennamen angegeben werden. z.B. die Rolle „älteste Kirche in Moabit“ in der Gruppe „Kirchen in Moabit“. Ein konkretes City-Object kann in mehreren Gruppierungen auftauchen, und auch jeweils verschiedene Rollen haben. Das Gebäude in der Gruppe „Kirchen in Moabit“ mit der Rolle „älteste Kirche in Mo-abit“ kann z.B. auch in der Gruppe „Gebäude des Architekten XY“ auftreten, und dort die Rolle „weniger sehenswertes Gebäude des Architekten XY“ spielen. Da eine CityObjectGroup auch ein CityObject ist, verfügt diese über alle Eigenschaften von CityObjects, wie den Fremdbezug, die BoundingBox, oder weitere Metadaten. Insbesondere kann auch eine Gruppe wieder Teil einer Gruppe sein, so dass beliebig verschachtelte Grup-pierungen möglich sind. Die Gruppen „Gebäude des Architekten XY“ und „Gebäude des Ar-chitekten ABC“ könnten z.B. zu der Gruppe „Architektonisch interessante Gebäude“ zusam-mengefasst werden. Anwendungsprogramme, die die Erzeugung einer Gruppe und die Einfügung von CityObjects in diese ermöglichen, müssen sicherstellen, dass dabei keine zyklischen Gruppenzugehörig-keiten entstehen. Eine Gruppe darf nicht Teil von sich selber sein, oder indirekt eine Gruppe enthalten, die die oberste Gruppe wiederum enthält. Auf Ebene des Schemas können solche zyklischen Zugehörigkeiten nicht aufgedeckt werden.

2.1.2 Geometriemodell und Texturen Die geometrische Beschreibung der Objekte des Stadtmodells basiert weitgehend auf der ISO-Norm 19107, mit einer Ergänzung. In Abb. 2.2 ist die Teilmenge der ISO 19107-Klassen dargestellt, die verwendet werden. Diese sind zum Teil hinsichtlich der gegenseitigen Durch-dringungsfreiheit von Volumenkörpern und anderer topologischer Eigenschaften sehr strikt definiert; im Kontext des 3D-Stadtmodells werden diese Eigenschaften aus pragmatischen Gründen etwas flexibler gehandhabt. GM_Composite ist die allgemeinste Klasse, die dann verwendet werden kann, wenn der Typ des Raumbezugs offen gehalten werden soll. Dieser kann in diesem Fall entweder ein zusammengesetzter Volumenkörper (ISO-Klasse: GM_CompositeSolid) für volumenhafte Objekte oder eine zusammengesetzte Oberfläche (GM_CompositeSurface) für flächenhafte Objekte sein. Ist der Typ des Raumbezugs festge-legt, können direkt die Klassen GM_CompositeSolid oder GM_CompositeSurface zur Anga-be der Geometrie verwendet werden. Eine GM_CompositeSurface ist eine Zusammenfassung von mehreren, aber mindestens einer GM_OrientableSurface. Im ISO-Modell dürfen sich diese einzelnen GM_OrientableSurface nur in den Rändern berühren, sie müssen aber ein zusammenhängendes Geometrieobjekt bil-den. Im 3D-Stadtmodell wird diese Eigenschaft des Zusammenhangs jedoch nicht notwendi-gerweise gefordert. Eine GM_OrientableSurface ist eine Fläche, die im dreidimensionalen Raum beliebig positioniert ist. Im Kontext des Stadtmodells sind diese Flächen planar, d.h. alle Punkte des Randes und des Inneren der Fläche müssen in einer Ebene liegen. Es handelt sich um orientierbare Flächen. d.h. man kann eindeutig zwei Seiten, eine vordere (front) und eine hintere (back) unterscheiden. Soll eine Seite (oder beide Seiten) mit einer Textur verse-hen sein, so wird eine TexturedSurface verwendet. Hier kann differenziert für jede Seite (back oder front) die eigentliche Textur in Form eines Rasterbildes, die Farbe als RGB-Werte und zur Positionierung der Textur auf der Fläche die Texturkoordinaten angegeben werden.

3D-Geodatenbank Berlin 2. Datenmodellierung

8

Die RGB-Werte müssen jeweils im Bereich zwischen 0 und 1 liegen. Die frontOpacity und die backOpacity1 geben jeweils für die entsprechende Seite den Grad der Transparenz an. Auch diese beiden Werte müssen im Bereich zwischen 0 und 1 liegen, wobei 1 voll deckend bedeutet und 0 vollständig transparent.

Das Konzept der Texturkoordinaten ist dem Standard X3D, dem Nachfolger von VRML, ent-nommen. Da weder in ISO 10107 noch in GML ein geeignetes Konzept für die Texturierung verfügbar ist, musste die Klasse TexturedSurface ergänzt werden.

Während GM_CompositeSurfaces zur Repräsentation flächenhafter CityObjects verwendet werden, dienen GM_CompositeSolids zur Modellierung volumenhafter Objekte wie z.B. der von Gebäuden. Ein GM_CompositeSolid ist eine Zusammenfassung von mindestens einem GM_Solid. Im ISO-Modell müssen die Inneren dieser Solids disjunkt sein, und die Zusam-menfassung dieser Solids muss ein zusammenhängendes Gebilde sein. Diese strikten Eigen-schaften der Durchdringungsfreiheit und des Zusammenhanges werden im 3D-Stadtmodell jedoch nicht gefordert. Ein Solid ist ein Volumen, das von einem oder mehreren GM_CompositeSurface so begrenzt wird, dass das Volumen vollständig umschlossen wird.

Abbildung 2.2: UML-Diagramm der Klassen zur Repräsentation der Geometrie

1 Die front- und backOpacity müssen im UML-Diagramm noch ergänzt werden.

3D-Geodatenbank Berlin 2. Datenmodellierung

9

2.1.3 Generische Objekte und Prototypen Neben denjenigen CityObjects, die zu einer Unterklasse wie z.B. Building gehören und deren Struktur und Attribute somit festgelegt sind, können CityObjects, die nicht in ein solches Schema passen, flexibel als GenericCityElement mit beliebigen Attributen (CityObjectGene-ricAttribute) repräsentiert werden (vgl. Abb. 2.1).

Ein GenericCityElement hat einen Namen, einen Typ und einen Klassennamen (class), der die Art des Objekts (Ampel, Baum,...) festlegt. Eine beliebige Menge von Attributen kann durch Zuordnung beliebig vieler CityObjectGenericAttribute, geerbt von CityObject, erfol-gen, die jeweils einen Attributnamen haben. Der Typ des Attributs kann durch die Wahl der jeweiligen Unterklasse (StringAttribute, IntAttribute) festgelegt werden. Der Wert wird dann von dem entsprechenden value aufgenommen.

Zur Repräsentation der Geometrie eines GenericCityElement gibt es prinzipiell zwei Alterna-tiven. Zunächst kann diese wie bei den üblichen Objekten des Stadtmodells wie Gebäuden durch Verweis auf einen GM_Composite realisiert werden, die in Abschnitt 2.1.2 näher erläu-tert wurden. Diese Repräsentation kann für die einzelnen Detaillierungsgrade (LoD) unter-schiedlich sein, weswegen die Beziehung zur Geometrie durch die Angabe der LOD-Stufe differenziert wird: lodX_GeometryProperty, mit X aus {1,2,3}. Zum anderen kann die Geo-metrie jedoch auch in einem ‚fremden’ Schema vorliegen, z.B. als VRML-Datei, als Shapefile oder als DXF-Datei, und für jeden Detaillierungsgrad unterschiedlich sein. In diesem Fall ist für jeden LoD das Geometrieformat im Attribut lodXNativeFormat als Mime-Type (z.B.„model/vrml“ für ein VRML-Objekt) angegeben, und die Geometrie ist im entsprechen-den Format als BLOB2 über die Beziehung lodX_NativeProperty zugeordnet, für jeden LoD. Da viele Geometrieformate nicht über eine Georeferenzierung verfügen und somit in einem lokalen Bezugssystem vorliegen („Nullpunkt in der linken unteren Ecke“), kann eine Trans-formationsmatrix (lodXTransformationmatrix, für jeden LoD X) angegeben werden, durch die die Geometrie aus dem lokalen in das georeferenzierte System des 3D-Stadtmodells trans-formiert werden kann. Das Koordinatenreferenzsystem, in dem die Koordinaten nach der Transformation vorliegen, kann für jeden LoD X in dem Attribut lodX_SRS3 abgelegt wer-den, unter Nutzung der entsprechenden Spezifikation ISO 19111 für solche Systeme.

CityObjects wie generische Objekte oder Gebäude haben i. d. R. eine eigene, georeferenzierte Geometrie, die individuell die absolute Lage des Objekts im Raum beschreibt. Oft müssen jedoch eine Vielzahl gleichförmiger identischer Objekte repräsentiert werden, die sich nicht durch Ihre Gestalt, sondern nur durch die Lage unterscheiden. Beispiele hierzu sind Aus-schmückungen wie Bäume oder Parkbänke, aber auch Gebäude einer gleichförmigen Sied-lung. Hier wäre es ineffizient, für jedes Objekt die unter Umständen sehr umfangreiche und komplexe Geometrie individuell abzulegen. Stattdessen kann hier das Konzept des Prototypen genutzt werden, bei dem die Geometrie nur einmal für die ganze Klasse von Objekten, z.B. für die Klasse „Eiche“, abgelegt, wird (vgl. Abb. 2.1). Diese Klasse wird durch Objekte Pro-totyp repräsentiert, der Klassenname ergibt sich aus dem Attribut class. Jedes individuelle Objekt wird nun durch ein PrototypeCityElement repräsentiert, das einen Verweis auf seine „Klasse“, differenziert nach LoD durch die Beziehung lodX_property, hat. Das individuelle Objekt hat keine eigene Geometrie, sondern bezieht diese von seinem Prototypen, so dass diese durch Angabe einer Transformationsmatrix – differenziert nach LoD - in die tatsächli-che Lage des Objekts transformiert werden kann. Auch hier gibt das Attribut lodX_SRS4 für jeden LoD X das Koordinatenreferenzsystem nach der Transformation an. Die Geometrie des Prototypen kann entweder im üblichen Stadtmodell-Format vorliegen (geometry_Property),

2 Ein BLOB (Binary Large Object) ist ein Datentyp, der binäre Daten jedes Typs aufnehmen kann. 3 Diese Attribute müssen im UML-Diagramm noch ergänzt werden. 4 Diese Attribute müssen im UML-Diagramm noch ergänzt werden.

3D-Geodatenbank Berlin 2. Datenmodellierung

10

oder in einem Fremdsystem. Im letzteren Fall ist sie als BLOB repräsentiert (nativeProperty), und der Typ der Geometrie ergibt sich aus dem Attribut nativeFormat (Mime-Typ) des Proto-typen. Die Attributwerte der individuellen Objekte werden durch die von CityObject geerbten CityObjectGenericAttribute repräsentiert.

Das Konzept der CityObjectGenericAttribute kann auch dazu genutzt werden, spezifische Unterklassen von CityObject wie z.B. Building flexibel – insbesondere zur Laufzeit des Sys-tems – um Attribute zu ergänzen, die im entsprechenden Schema nicht vorgesehen sind.

2.1.4 Gebäudemodell Im Zentrum des Gebäudemodells (vgl. Abb. 2.3) steht die Klasse AbstractBuilding, die zur Repräsentation eines Gebäudes dient. AbstractBuilding ist eine abstrakte Unterklasse von CityObject und erbt somit deren Eigenschaften und Metadaten (vgl. Abschnitt 2.1.1). Die Geometrie eines AbstractBuilding wird durch die Beziehungen zu der Klasse GM_Composite realisiert. Es ist für jeden der drei Detailierungsgrade LoD1 bis LoD3 eine eigene Geometrierepräsentation vorgesehen, realisiert durch die Beziehungen lod1GeometryProperty, .., lod3GeometryProperty. Dasselbe Gebäude kann somit zugleich mehrere räumliche Repräsentationen in verschiedenen Detaillierungsstufen haben. Im LoD1 ist die räumlich Repräsentation durch einen GM_Solid repräsentiert, während in den LoD2 und 3 neben der Verwendung von GM_Solids auch die Modellierung flächenhafter Bestand-teile wie Dachüberstände durch GM_Surfaces möglich ist.

Als Attribute eines AbstractBuilding sind der Name, die Funktion (z.B. Wohnhaus, Kir-che),das Baujahr, die Dachform als Aufzählungstyp (z.B. 1 = Flachdach, 2= Satteldach,...), die gemessene Höhe, und die Anzahlen der ober- bzw. unterirdischen Stockwerke vorgese-hen. Einem Gebäude können mehrere Adressen zugeordnet sein.

Das Gebäudemodell erlaubt sowohl die Repräsentation einfacher Gebäude, die nur aus einem Teil bestehen, als auch die von komplexen Bestandteilsbeziehungen zwischen Gebäudeteilen, z.B. eines Gebäudes, das aus drei Teilen – einem Haupthaus, einer Garage und einem Anbau – besteht. Die Teile können wiederum aus Teilen bestehen usw. Diese Modellierungen wer-den durch die Unterklassen Building und BuildingPart von AbstractBuilding ermöglicht. Im Fall eines einfachen, einteiligen Hauses liegt nur ein Building vor, dass alle Attribute und Beziehungen von AbstractBuilding erbt. Ein solches Building kann aber als Bestandteile auch BuildingParts haben, die ebenfalls alle Eigenschaften von AbstractBuilding erben. Insbeson-dere können die BuildingParts wiederum BuildingParts als Bestandteile haben, durch die Ver-erbung der Aggregationsbeziehung. Somit ergibt sich eine baumartige Hierarchie, an deren Wurzel ein Building steht, und deren Nichtwurzelknoten BuildingParts sind. Die Attributwer-te sind in der Regel in der unteren Hierarchieebene belegt, da durchaus jedes Teil ein eigenes Baujahr und eine eigene Funktion haben kann. Die Funktion kann aber ebenfalls auch in der Wurzel der Hierarchie definiert sein und gilt somit für das ganze Gebäude. Die einzelnen BuildingParts innerhalb eines Building dürfen sich gegenseitig nicht durchdringen, und müs-sen ein zusammenhängendes Objekt bilden.

Buildings können zu einem Gebäudekomplex (BuildingGroup) zusammengefasst werden, der als Attribute einen Namen und eine Funktion hat. Genau ein Gebäude des Komplexes kann als Hauptgebäude ausgezeichnet sein.

Bestandteile von Gebäuden, die nicht die Bedeutung eines Gebäudeteils haben, werden als Gebäudecharakteristik (BuildingCharacteristic) modelliert, z.B. Balkone, Fahrstuhlaufbauten auf Dächern oder Dachgauben. Diese kommen erst in den LoD 2 und 3 vor und haben dort eine eigene Geometrie, realisiert als GM_Composite. Die Gebäudecharakteristik ist durch eine Aggregationsbeziehung (outerCharacteristic) mit dem zugehörigen Gebäude verknüpft.

3D-Geodatenbank Berlin 2. Datenmodellierung

11

Abbildung 2.3: UML-Diagramm des Gebäudemodells

3D-Geodatenbank Berlin 2. Datenmodellierung

12

Sowohl Gebäudekomplexe als auch Gebäudecharakteristiken sind CityObjects und erben so-mit alle deren Eigenschaften, einschließlich der Fremddatenbeziehung.

In den LoD 2 und 3 können die Begrenzungsflächen von Gebäuden als eigenständige themati-sche Objekte modelliert werden. Dazu werden die Unterklassen der Klasse BoundarySurface – Wand-, Boden- und Dachflächen – verwendet. Abschlussflächen (ClosureSurface) können genutzt werden, um offene Gebäude wie z.B. Hangars abzuschließen und so z.B. Volumenbe-rechnungen zu ermöglichen. Alle thematischen Begrenzungsflächen haben eine eigene Geo-metrie, repräsentiert durch flächenhafte GM_Composites. Geometrisch sind diese Flächen auch in der Begrenzung der Solids vertreten, die das entsprechende übergeordnete themati-sche Objekt, i.d.R ein Gebäude, repräsentieren. Diese geometrischen Flächen müssen redun-danzfrei abgelegt sein, d.h. eine solche GM_Composite muss sowohl Teil der Geometrie des Gebäudes sein als auch zugleich die thematische Begrenzungsfläche repräsentieren.

Im LoD3 kommen Öffnungen (Opening) wie Türen oder Fenster als spezielle Begrenzungs-flächen hinzu. Diese sind mit der sie enthaltenen Begrenzungsfläche (Wand oder Dach) durch die Beziehung openingProperty verknüpft. Eine Öffnung, die eine Türe ist, kann mit der ent-sprechenden Adresse verknüpft sein (Relation addressProperty).

Eine Adresse mit den üblichen Attributen (Straßenname, Hausnummer, Postleitzahl, Stadtna-me) wird durch die Klasse Address repräsentiert und kann einem Gebäude oder einer Tür zu-geordnet werden.

2.1.5 Digitales Geländemodell Das Stadtmodell verfügt über ein sehr flexibles Digitales Geländemodell (DGM), das die Kombination heterogener, in verschiedenen Detaillierungsgraden vorliegender DGM-Typen (Raster, TIN, Bruchkanten, Massenpunkte) erlaubt.

Ein zu einem bestimmten Stadtmodell passendes DGM wird durch ein Objekt Relief reprä-sentiert. Dieses ist ein CityObject und hat als Attribut einen Namen und die LOD-Stufe, zu der das DGM passt (LODGroup). Ein Relief besteht aus mehreren ReliefComponent, wobei jeder dieser Komponenten, die ebenfalls CityObjects sind, einen Namen und die LoD-Stufe beinhaltet. Die einzelnen geometrischen Ausprägungen der Komponenten werden durch die vier Unterklassen von ReliefComponent definiert: Bruchkanten, Dreiecksvermaschungen (TIN), Raster, und Massenpunkte. Geometrisch sind diese Ausprägungen durch entsprechen-de ISO 19107 bzw. GML-Klassen definiert: Bruchkanten durch einzelne GM_LineStrings, TINs durch GM_Triangle, und Massenpunkte durch GM_Point.

Ein Relief kann durchaus ReliefComponents mit heterogenem Typ und auch verschiedenen LoDs beinhalten. Ein Relief im LoD2 kann z.B. einige LoD3-TIN-ReliefComponents neben einer LoD2-Raster-ReliefComponent enthalten. Gegebenenfalls kann in einigen Bereichen auch nur ein LoD1-Raster im Relief vorhanden sein. Wenn dieses Relief zu einem LoD2-Stadtmodell passt, wird der Wert des Attributs LoDGroup des Gesamtreliefs auf 2 gesetzt.

Ein Raster ist durch die GML3-Klasse RectifiedGridCoverage definiert, die auch die Reprä-sentation nicht achsenparalleler Raster ermöglicht. Bei der Verwaltung von Rastern ist eine Besonderheit zu beachten, die sich aus der Zweistufigkeit des Importvorganges ergibt. Dabei werden zunächst einzelne, kleinere Rasterkacheln importiert, die dann in einem zweiten Schritt zu einem Gesamtraster kombiniert werden. Um zwischenzeitlich diese kleineren Ras-ter (Tiles) abzulegen, dient die Beziehung importetRasterTiles zwischen Raster und Recti-fiedGridCoverage. Das im zweiten Importschritt erzeugte Gesamtraster wird dann als Recti-fiedGridCoverage angelegt, das über die Beziehung rasterProperty verknüpft ist.

Um die einzelnen Komponenten eines Raster, die in verschiedenen LoD vorliegen können, geometrisch voneinander abzugrenzen, dient das Gültigkeitspolygon einer Komponente (ex-

3D-Geodatenbank Berlin 2. Datenmodellierung

13

tent). Dieses legt den Bereich fest, in dem die Komponente gültig ist. Abb. 2.5 zeigt als Bei-spiel ein Raster mit drei Komponenten: einem groben Raster und zwei darin liegenden hoch-aufgelösten TINS (TIN 1 und 2). Das Gültigkeitspolygon des Rasters ist blau skizziert, wäh-rend die Gültigkeitspolygone der TINs grün und rot umrandet sind. Das Gültigkeitspolygon des Rasters hat hier zwei Löcher bzw. Aussparungen, in denen zwar auch das Raster vorhan-den ist, es aber nicht gültig ist und stattdessen die höher aufgelösten TINs zur Repräsentation des Geländes verwendet werden. Die beiden Gültigkeitspolygone der TINs liegen dabei exakt in den beiden Löchern des Gültigkeitspolygon des Rasters.

Im einfachsten und auch häufigsten Fall entspricht das Gültigkeitspolygon eines Rasters exakt seiner Bounding Box, also der räumlichen Ausdehnung des Rasters.

Abbildung 2.4: UML-Diagramm des DGM

3D-Geodatenbank Berlin 2. Datenmodellierung

14

TIN 1

TIN 2

Raster

Abbildung 2.5: Ein Relief, bestehend aus drei Komponenten, mit ihren Gültigkeitspolygonen (blau für das

Raster, und rot bzw. grün für die TIN-Komponenten.

2.1.6 Orthophotos Orthophotos werden im 3D Stadtmodell durch ähnliche Konzepte modelliert, wie sie auch für die Repräsentation von Rastern in DGMs (vg. Abschnitt 2.1.5) Verwendung finden. Das UML-Diagramm für Orthophotos ist in Abb. 2.6 dargestellt. Ein Objekt der Klasse Orthopho-to ist ein CityObject, hat eine LoD-Stufe, ein Befliegungsdatum und einen Namen. Realisiert wird ein Orthophoto durch die GML-Klasse RectifiedGridCoverage, die auch die Speiche-rung nicht achsenparalleler Photos ermöglicht. Aus Gründen des Imports ist hier die Speiche-rung mehrerer kleiner Orthophotos (Tiles) erforderlich, analog zu der Vorgehensweise bei DGM-Rastern (vgl. Abschnitt 2.1.5).

Abbildung 2.6: UML-Diagramm der Klassen zur Repräsentation von Orthophotos

3D-Geodatenbank Berlin 2. Datenmodellierung

15

2.2 Relationales Datenbankschema

2.2.1 Abbildungsregeln, Schemakonventionen

2.2.1.1 Abbildung der Klassen auf Tabellen In der Regel wird jede Klasse des UML-Diagramms auf genau eine Tabelle abgebildet; der Tabellenname ist identisch zu dem Klassennamen (führende Unterstriche für abstrakte Klas-sen werden weggelassen). Die skalaren Attribute der Klassen werden zu Spalten der entspre-chenden Tabelle mit identischem Namen. Die Typen der Attribute werden an Oracle-Datentypen angepasst.

Die Ausnahmen von der Regel, jede Klasse auf eine Tabelle abzubilden, sind:

• Die Klasse FT_Feature wird mit der Klasse CityObject zur Tabelle CITYOBJECT verschmolzen.

• Die Klasse FT_FeatureCollection und die Klasse CityModel fallen weg, da zurzeit nur ein einziges 3D-Stadtmodell in der 3D-Geo-DB repräsentiert werden muss und des-halb die Gruppierung zur FeatureCollection entfallen kann.

• Die Geometrieklassen der ISO 19107/19123 werden zu Attributen des Datentyps SDO_GEOMETRY oder SDO_GEORASTER.

• Die Klasse ReliefComponent wird mit den Klasse BreaklineLines, TIN, Raster und MassPoints verschmolzen und als Tabellen BREAKLINE_RELIEF, TIN_RELIEF, RASTER_RELIEF und MASSPOINT_RELIEF dargestellt.

• Die Klasse BLOB wird zum Attribut des Datentyps Blob.

• Die Klasse GM_Composite wird mit allen Unterklassen auf die Tabelle SURFA-CE_GEOMETRY abgebildet.

• Die Klasse CityObjectGenericAttrib wird mit allen Datentypenunterklassen in der Ta-belle CITYOBJECT_GENERICATTRIB zusammengefasst.

• Die Klassen Abstractbuilding, Building und BuildingPart werden auf die Tabelle BUILDING abgebildet.

• Die Klassen BoundarySurface und Unterklassen ClosingSurface, FloorSurface, Wall-Surface und RoofSurface werden auf die Tabellen THEMATIC_SURFACE und THEMATIC_SURFACE_GEOMETRY abgebildet.

2.2.1.2 Abbildung der Ober- Unterklassenbeziehung Bei der Umsetzung der Vererbung wird für jede Klasse eine Tabelle gebildet mit den unter Abschnitt 1 aufgeführten Ausnahmen. Jede Tabelle hat als Primärschlüssel ein Attribut mit dem Namen ID. Der Name des Primärschlüssel-Constraints ist der Tabellenname, gefolgt von „_PK“. Das ID-Attribut der Unterklassetabelle wird als Fremdschlüssel auf das ID-Attribut der Oberklassetabelle definiert. Diese Fremdschlüsselbeziehung wird nach dem Schema be-nannt:

• GEN_<SUBOBJECT_ID>_<OBJEKT_ID>_< laufende Nummer >

3D-Geodatenbank Berlin 2. Datenmodellierung

16

SUBOBJECT_ID ist der Primärschlüssel der Unterklassentabelle und OBJECT_ID ist der Primärschlüssel der Oberklassentabelle. Die laufende Nummer dient dazu, den Fremdschlüs-selnamen global eindeutig zu machen.

2.2.1.3 Abbildung der Aggregation Zur Abbildung der Aggregation wird in der Teileklassentabelle ein Attribut definiert, das als Fremdschlüssel auf den Primärschlüssel der Aggregatklassentabelle dient. Diese Fremd-schlüsselbeziehung wird nach dem Schema benannt:

• AGG_<FREMDSCHLÜSSEL_TEILEKLASSE>_ <PRIMÄRSCHLÜSSEL_AGGREGATKLASSE>_< laufende Nummer >

FREMDSCHLÜSSEL_TEILEKLASSE ist das Attribut in der Teileklassentabelle, das als Fremdschlüssel auf den Primärschlüssel der Aggregattabelle (PRIMÄRSCHLÜS-SEL_AGGREGATKLASSE) dient. Die laufende Nummer dient dazu, den Fremdschlüssel-namen global eindeutig zu machen.

2.2.1.4 Abbildung allgemeiner Relationen Zur Abbildung allgemeiner 1:n Relationen wird in der n-seitigen Tabelle ein Attribut defi-niert, das als Fremdschlüssel auf den Primärschlüssel der 1-seitigen Tabelle dient. Diese Fremdschlüsselbeziehung wird nach dem Schema benannt:

• REL_<FREMDSCHLÜSSEL_n-seitig>_ <PRIMÄRSCHLÜSSEL_1-seitig>_< laufende Nummer>

Die laufende Nummer dient dazu, den Fremdschlüsselnamen global eindeutig zu machen. Ggf. kann die laufende Nummer weggelassen werden.

2.2.1.5 Explizite Angabe der Klassenzugehörigkeit In der (Meta-)Tabelle OBJECTCLASS werden alle Klassennamen (Attribut CLASSNAME) des Schemas verwaltet. Die Relation von der Unter- zur Oberklasse wird als Attribut SU-PERCLASS_ID in der Unterklasse als Fremdschlüssel auf die ID der Oberklasse repräsen-tiert.

Die Tabelle OBJECTCLASS wird genutzt, um in den Oberklassentabellen die Zugehörigkeit zu einer Klasse effizient ermitteln zu können. Dazu gibt es in den Tabellen CITYOBJECT und RELIEFCOMPONENT ein Attribut CLASS_ID, das auf die entsprechende Tabelle OB-JECTCLASS verweist. Dadurch kann bei Betrachten eines Tupels z.B. in CITYOBJECT un-mittelbar die Unterklasse und – falls benötigt – der Klassenname ermittelt werden.

Wenn z.B. eine Reliefkomponente mit der ID 375 dargestellt werden soll, müsste in jeder der vier Tabellen BREAKLINE_RELIEF, TIN_RELIEF, MASSPOINT_RELIEF und RAS-TER_RELIEF nachgesehen werden, ob die ID dort vorhanden ist. Mit der Information über die Klassenzugehörigkeit in der Tabelle RELIEFCOMPONENT kann gezielt in der „richti-gen“ der vier Tabelle gesucht werden.

Die Information über die Klassenzugehörigkeit ist nicht nur in der höchsten Oberklasse CI-TYOBJECT vorhanden, sondern in den unteren Oberklassen (Z.B. RELIEFCOMPONENT). Dadurch kann ein Zugriff auf die Tabelle CITYOBJECT, in der alle Objekte der Datenbank repräsentiert sind, vermieden werden.

3D-Geodatenbank Berlin 2. Datenmodellierung

17

2.2.1.6 Einschränkung der Wertebereiche von Attributen Attribute mit eingeschränktem Wertebereich, z.B. LOD, die ganzzahlige Werte zwischen 1 und 3 annehmen können, können durch Constraints der Form:

• <Attributname>_CHK_< laufende Nummer> definiert werden, gefolgt von der Definition des Wertebereichs.

2.2.1.7 Sequenzen für die automatische Iteration der IDs Um die automatische Generierung der Zahlenreihen für die Vergabe der eindeutigen IDs zu ermöglichen, werden Oracle-Sequenzen mit dem Startwert und dem Iterationsschritt gleich 1 angelegt. Der Höchstwert einer ORACLE Sequenz entspricht der größten 28-stelligen Zahl. Die Benennung wird wie folgt realisiert:

• <Tabellenname>_SEQ Für alle Klassen die von CITYOBJECT abgeleitet sind, werden keine eigenen Sequenzen erstellt, da diese IDs den Cityobject-IDs entsprechen. Den Zugriff auf die Sequenz ermögli-chen die Methoden nextval und currval.

2.2.2 Rasterdatenverwaltung mit Oracle 10g Spatial Oracle 10g verwaltet Rasterdaten nicht unmittelbar in den Tabellen, in denen ein Feld vom Typ MDSYS.SDO_GEORASTER angelegt wurde. Statt dessen werden sogenannte RASTERDATATABLE (RDT) verwendet, die ein von Oracle vordefiniertes Schema aufwei-sen müssen. Aus Gründen der Übersichtlichkeit verfügt jede Tabelle, die ein Feld vom Typ MDSYS.SDO_GEORASTER aufweist, über eine eigene RDT. Hierbei wurde die Konvention angewendet, dass die einer Tabelle zugeordnete RDT den selben Namen plus das Postfix ‚RDT’ erhält (z.B.: ORTHOPHOTO ORTHOPHOTO_RDT).

Aufgrund der Größe des abzudeckenden Raums (Berlin) liegen die Rasterdaten nicht in einer einzigen großen TIFF-Datei sondern gekachelt in mehreren Dateien vor. Werden diese impor-tiert, liegt jede Kachel als eigenes Rasterobjekt vor. Diese können bei Anfragen nur getrennt behandelt werden. Soll z.B. ein Reliefausschnitt abgefragt werden, der sich über mehrere Ka-cheln erstreckt, ist es zunächst nicht möglich, diesen als ein Objekt abzufragen; für jede tan-gierte Kachel liefert die Oracle-Datenbank ein eigenes Rasterobjekt bzw. Bild zurück! Insbe-sondere bei der Abfrage größerer Raumausschnitte, bei denen u.U. mehrere hundert oder tau-send Kacheln betroffen sind, ist dies jedoch inakzeptabel.

Um dennoch eine gemeinsame Abfrage auf den gesamten Raum mit der Rückgabe nur eines Objekts zu ermöglichen, bietet das Georaster-Modul von Oracle 10g die Möglichkeit, über die Funktion sdo_geor.mosaic(..) aus den in einer Tabelle vorhandenen Kacheln ein einziges, großes GeoRaster zu erzeugen, das seinerseits in einer Tabelle abgelegt wird. Die Identifika-tion der Ursprungskacheln geht dabei verloren. Aufgrund der Größe der Ausgangsdaten ist diese Operation sehr aufwändig in Bezug auf Speicherbedarf und Rechenzeit und kann daher nicht bei jeder Aktualisierung einzelner Kacheln durchgeführt werden. Die Verwendung eines Triggers zur automatischen Neuberechnung des Gesamtrasters scheidet daher aus.

Betrachtet man die zu verwaltenden Rasterobjekte genauer, so ist davon auszugehen, dass es nur eine beschränkte Anzahl von Instanzen geben wird, deren Metadaten (Attribute) sich zu-dem eher selten ändern. Daher wurden neben den Tabellen RASTER_RELIEF und OR-THOPHOTO jeweils eine weitere Tabelle angelegt, in die zunächst alle vorhandenen Kacheln importiert werden. Updates auf einzelne Kacheln werden ebenfalls auf diese Tabelle(n) aus-geführt. Der verantwortliche Administrator entscheidet, wann er über die mosaic-Funktion das eigentliche Relief in der Tabelle RASTER_RELIEF bzw. ORTHOPHOTO aktualisiert.

3D-Geodatenbank Berlin 2. Datenmodellierung

18

Die Verwendung von Importtabellen und der mosaic-Funktion bringt einige grundsätzliche Implikationen mit sich, die es bei der Anwendungsentwicklung zu beachten gilt:

• Im erzeugten Gesamtraster sind die ursprünglichen Kacheln nicht mehr identifizierbar.

• Aktualisierungen des Gesamtrasters unmittelbar nach dem Einspielen einzelner Ka-cheln sind defacto ausgeschlossen.

• Die von CITYOBJECT geerbten Datumsfelder haben für die Gesamtraster nur eine begrenzte Aussagekraft.

• Die zusammenzufassenden Kacheln müssen geschlossen sein; es darf keine Lücken zwischen zwei benachbarten Kacheln geben.

• Sie müssen vollständig sein; der abgebildete Raumausschnitt muss vollständig mit Kacheln besetzt sein (ggf. durch leere Dummy-Kacheln).

• Die einzelnen Kacheln dürfen sich nicht überlappen.

• Alle Kacheln müssen die selbe räumliche Auflösung haben (kann ggf. manuell über die scale(..)-Funktion erreicht werden).

Nach dem Import bzw. dem Zusammenfassen von Rasterdaten über die Oracle-mosaic-Funktion liegen diese als ein großes Objekt in der Datenbank mit einer homogenen räumli-chen Auflösung vor. Dies erschwert den Export der Daten in einer anderen als der Original-auflösung (z.B. beim Erzeugen von Übersichtskarten). Daher sieht das GeoRaster-Modul von Oracle 10g vor, dass Raster über eine Pyramidenstruktur in unterschiedlichen Auflösungen vorgehalten werden können. Diese wird unmittelbar nach dem Import bzw. Update einer In-stanz von RASTER_RELIEF bzw. ORTHOPHOTO erstellt. Oracle bietet hierzu verschiede-ne Verfahren der Interpolationen der Rasterzellen an. Die Wahl des anzuwendenden Verfah-rens dürfte im wesentlichen von der Performanz und den zu erwartenden Artefakten abhän-gen. Als Standardverfahren verwenden die bereitgestellten Importmethoden eine bikubische Interpolation (höchstmögliche optische Qualität; relativ langsam)5.

Jedes Rasterobjekt kann in der 3D-Geodatenbank in drei verschiedenen Levels of Detail vor-gehalten werden. Zur Kennzeichnung dient das Feld LOD in den Tabellen ORTHOPHOTO und RASTER_RELIEF. Nicht jeder LOD muss dabei besetzt sein. Unabhängig davon können Rasterdaten für jeden LOD in verschiedenen räumlichen Auflösungsstufen angefragt werden. Die genaue Struktur der Tabellen zur Rasterdatenverwaltung wird in Abschnitt 2.2.3.6 aus-führlich dargestellt.

2.2.3 Datenbankschema Im folgenden Abschnitt werden die Tabellen des relationalen Schemas im Detail beschrieben. Graphisch ist das Schema in den Abbildungen 2.7 – 2.13 dargestellt. Die Beschreibung baut auf den Ausführungen zu den UML-Diagrammen in 2.1 auf und verweist darauf, soweit das Schema identisch die UML-Modellierung abbildet. Nur wenn sich durch die Umsetzung in Tabellenform Änderungen der Modellierung ergeben, werden diese im folgenden näher dargelegt.

2.2.3.1 Tabellen für Basisklassen Die Tabellen für die Basisklassen sind in Abbildung 2.7 wiedergegeben.

5 Bei einem Relief, das sich u.a. durch schroffe Kanten auszeichnet, führt die Verwendung des NearestNeighbor (NN) Verfahrens ggf. zu einer räumlichen Verschiebung oder u.U. auch zu einer Eliminierung derartiger Kanten. Die Verwendung einer (bi)kubischen Interpolation (CUBIC) glättet dagegen vorhandene Kanten.

3D-Geodatenbank Berlin 2. Datenmodellierung

19

Abbildung 2.7: Tabellen zur Realisierung der Basisklassen

3D-Geodatenbank Berlin 2. Datenmodellierung

20

CITYOBJECT, CITYOBJECT_SEQ CityObjects werden durch Einträge in der Tabelle CITYOBJECT repräsentiert. Die Felder sind identisch zu den Attributen der entsprechenden UML-Klasse. Die BoundingBox (Enve-lope) wird durch ein Feld mit Typ SDO_GEOMETRY realisiert, das ein achsenparalleles 2D-Polygon (SDO_GTYPE = 2003, SDO_ETYPE = 1003 und SDO_INTERPRETATION = 3) enthält6. Neu ist hier nur ein Feld CLASS_ID, das dazu dient, Informationen über die Klas-senzugehörigkeit des CityObject effizient verfügbar zu machen, und so sofort auf die richtige Tabelle für die Unterklasse zugreifen zu können.

Die nächste freie ID für die Tabelle CITYOBJECT wird durch die Sequenz CITYOBJ_SEQ bereitgestellt. OBJECTCLASS Der Fremdschlüssel CLASS_ID der Tabelle CITYOBJECT verweist auf den Schlüssel in der Tabelle OBJECTCLASS, die für jede Unterklasse von CityObject im UML-Diagramm einen Eintrag mit dem Klassennamen enthält. Die Oberklassenbeziehung wird durch das Feld SU-PERCLASS_ID realisiert, das auf die eindeutige Oberklasse – falls vorhanden – verweist. Die Klasse CityObject hat die ID 0. EXTERNALREFERENCE, EXTERNALREF_SEQ Die Tabelle EXTERNALREFERENCE setzt das Fremdbezugssystem um; dabei verweist der Fremdschlüssel CITYOBJECT_ID auf das zugehörige CityObject. Die Sequenz EXTER-NALREF_SEQ stellt die nächste freie ID für EXTERNALREFERENCE bereit. CITYOBJECT_GENERICATTRIB, CITYOBJECT_GENERICATT_SEQ Die Tabelle CITYOBJECT_GENERICATTRIB dient, wie in 2.1.3 beschrieben, zur Reprä-sentation des generischen Attributskonzepts. Es wurde jedoch auf die Erstellung einer Tabelle je Attributtyp verzichtet; stattdessen werden alle Typen durch eine einzige Tabelle CITYOB-JECT_GENERICATTRIB repräsentiert, wobei die Typen durch die Werte des Attributs DA-TATYPE differenziert werden. Diese Tabelle sieht für jeden Datentyp ein Feld vor. Es ist nur jeweils ein Feld belegt; Informationen über den Datentyp enthält das Feld DATATYPE, des-sen Inhalt die in der folgenden Tabelle dargelegte Bedeutung hat:

DATATYPE Attributtyp 1 STRING 2 INTEGER 3 REAL 4 DATE 5 BLOB 6 Oracle-Geometrie (SDO_GEOMETRY) 7 Geometrie durch Flächen in der Tabelle SURFACE_GEOMETRY

Die Beziehung des generischen Attributs zu seinem CityObject ergibt sich aus dem Fremd-schlüssel CITYOBJECT_ID (REL_CITYOBJ_ID_ID_1).

Die nächste freie ID für die Tabelle CITYOBJECT_GENERICATTRIB wird durch die Se-quenz CITYOBJECT_GENERICATT_SEQ bereitgestellt.

6 Langfristig sollte hier über die Verwendung dreidimensionaler BoundingVolumes nachgedacht werden.

3D-Geodatenbank Berlin 2. Datenmodellierung

21

IMPORT_PROCEDURES In der Tabelle IMPORT_PROCEDURES sind die Namen der zum Datenimport bereitgestell-ten Prozeduren abgelegt. Diese können durch Eintrag des Namens in diese Tabelle registriert werden und stehen dann in dem Werkzeug zum Datenimport zur Auswahl bereit, um z.B. je nach Art des importieren Shapefiles die erforderlichen Datenbankoperationen zum Füllen der Tabellen auszuführen.

2.2.3.2 Objektgruppen

CITYOBJECTGROUP, GROUPTOCITYOBJECT Das in Abschnitt 2.1.2. beschriebene Gruppierungskonzept wird durch die Tabellen in Abb. 2.8 umgesetzt. Die Unterklassenbeziehung zwischen der Gruppe (Tabelle CITYOB-JECTGROUP) und CityObject wird durch die Relation GEN_ID_ID_12 realisiert. Da es sich bei der Beziehung zwischen CityObjects und Gruppen um eine m:n-Beziehung handelt, wur-de die Tabelle GROUPTOCITYOBJECT eingeführt, die die IDs beider Tabellen zuordnet.

Abbildung 2.8: Tabellen zur Realisierung von Objektgruppen

3D-Geodatenbank Berlin 2. Datenmodellierung

22

2.2.3.3 Tabellen zur Repräsentation der Geometrie Die Repräsentation der Geometrie im DB-Schema (Abb. 2.7) unterscheidet sich wesentlich von der im UML-Diagramm, bietet jedoch dieselbe Funktionalität. SURFACE_GEOMETRY, SURFACE_GEOM_SEQ Im DB-Schema besteht die Geometrie zunächst aus planaren Flächen, die jeweils einem Ein-trag in der Tabelle SURFACE_GEOMETRY entsprechen. Die Geometrie wird in dem Feld GEOMETRY als SDO_GEOMETRY (jeweils ein planares Polygon, ggf. mit Aussparungen) abgelegt. Jede Fläche kann Texturen oder eine Farbe, jeweils auf beiden Seiten, haben. Für die Beschreibung dieser Attribute wird auf die der Klasse TexturedSurface im UML-Diagramm verwiesen.

Die SDO_GEOMETRY im Feld GEOMETRY der Tabelle SURFACE_GEOMETRY wird wie folgt eingeschränkt:

o der SDO_GTYPE muss den Typ Polygon haben, d.h. ein 3D-Polygon (SDO_GTYPE = 3003), und

o der SDO_ETYPE muss 1003/2003 mit SDO_INTERPRETATION = 1 sein (d.h. Po-lygon mit 3D-Koordinaten im Umring, begrenzt durch gerade Liniensegmente, ggf. mit Löchern).

o es kann auch ein Rechteck vorliegen (SDO_ETYPE=1003/2003, mit SDO_INTERPRETATION = 3), repräsentiert durch zwei Eckpunkte.

Flächen können zusammengefasst werden, um entweder einen Komplex aus Flächen oder die Begrenzung eines Volumenkörpers zu bilden. Die Zusammenfassung mehrerer Flächen, z.B. F1 bis Fn, wird so umgesetzt, dass ein neues Flächentupel Fn+1 erzeugt wird, dem keine Geo-metrie zugeordnet ist. Bei den Flächen F1 bis Fn verweist nun die PARENT_ID auf die ID von Fn+1. Dieser Baum mit Wurzel Fn+1 repräsentiert nun die Zusammenfassung der Flächen, d.h. eine CompositeSurface. Diese kann entweder geschlossen, sein, d.h. die Begrenzung eines Solid bilden. In diesem Fall ist der Wert des Feldes IS_SOLID in der Wurzel gleich 1. An-dernfalls ist er 0.

Zusammengefasste Flächen können wiederum mit anderen (zusammengesetzten) Flächen gruppiert werden, durch Erzeugen eines gemeinsamen Parent. So können beliebige Aggrega-tionen von Flächen, CompositeSurfaces, Solids, CompositeSolids flexibel gebildet werden.

Die nächste freie ID für die Tabelle SURFACE_GEOMETRY wird durch die Sequenz SUR-FACE_GEOM_SEQ bereitgestellt.

Beispiel: Die Geometrie in der Abbildung, bestehend aus sieben Flächen, die ein Volumen begrenzen, ist durch die folgenden Tabellenzeilen repräsentiert:

1

23

4

5

6 7

Abbildung 2.9: Sieben Surfaces, die ein geschlossenes Volumen bilden.

3D-Geodatenbank Berlin 2. Datenmodellierung

23

SURFACE_GEOMETRY ID PARENT_ID GEOMETRY IS_SOLID ...... ... ... ... ... ....... 8 NULL NULL 1 ....... 1 8 Geometrie der Fläche 1 0 ....... 2 8 Geometrie der Fläche 2 0 ....... 3 8 Geometrie der Fläche 3 0 ....... 4 8 Geometrie der Fläche 4 0 ....... 5 8 Geometrie der Fläche 5 0 ....... 6 8 Geometrie der Fläche 6 0 ....... 7 8 Geometrie der Fläche 7 0 ....... .... .... ....... ...... .......

Das thematische Objekt (z.B. Building), das durch diese Geometrie repräsentiert wird, würde dies durch einen Verweis auf die ID 8 zum Ausdruck bringen.

Sollen dagegen nur die beiden Dachflächen als CompositeSurface repräsentiert werden, erge-ben sich die folgenden Tupel:

SURFACE_GEOMETRY ID PARENT_ID GEOMETRY IS_SOLID ...... ... ... ... ... ....... 12 NULL NULL 0 ....... 6 12 Geometrie der Fläche 6 0 ....... 7 12 Geometrie der Fläche 7 0 ....... .... .... ....... ...... ......s

Hier würde das thematische Objekt (Dachfläche), das durch diese Geometrie repräsentiert wird, auf die ID 12 verweisen.

2.2.3.4 Tabellen für generische Objekte und Prototypen Die generischen Objekte und Prototypen, die auf UML-Ebene in Abschnitt 2.1.1 beschrieben wurden, sind durch die Tabellen in Abbildung 2.10 umgesetzt. PROTOTYPECITYELEMENT, PROTOTYPE, PROTOTYPE_SEQ Das PrototypeCityElement wird durch die Tabelle PROTOTYPECITYELEMENT realisiert, wobei die Unterklassenbeziehung zu CityObject durch die gemeinsame ID (Relation GEN_ID_ID_9) realisiert ist. Die Beziehung zu den zugehörigen Prototypen in jedem LoD werden durch die Fremdschlüssel LOD1_PROTOTYPE_ID bis LOD3_PROTOTYPE_ID dargestellt. Die Klasse Prototyp entspricht der Tabelle PROTOTYPE, die Attribute bzw. Fel-der sind identisch.

Die Geometrie eines Prototypen ergibt sich aus dem Fremdschlüssel SURFACE_ID, der auf die ID der Wurzel – des obersten Elements – eines Flächen/Volumenaggregats verweist (vgl. Abschnitt 2.2.3). Alternativ kann die SURFACE_ID gleich NULL sein, wenn stattdessen die Geometrie in einem nativen Format gegeben ist (vgl. Abschnitt 2.1.3).

Die nächste freie ID für die Tabelle PROTOTYPE wird durch die Sequenz PROTOTY-PE_SEQ bereitgestellt.

3D-Geodatenbank Berlin 2. Datenmodellierung

24

Abbildung 2.10: Tabellen für Prototypen und generische Klassen

3D-Geodatenbank Berlin 2. Datenmodellierung

25

GENERICCITYELEMENT Generische Objekte sind in der Tabelle GENERICCITYELEMENT repräsentiert. Die Felder sind größtenteils identisch zu den Attributen der UML-Klasse GenericCityElement. Die Ge-ometrie ergibt sich aus den drei Fremdschlüsseln LOD1_SURFACE_ID,..., LOD3_SUR-FACE_ID, die auf eine Fläche oder das oberste Element eines Flächen/Volumenaggregats verweisen (vgl. Abschnitt 2.2.3). Alternativ kann eine LODX_SURFACE_ID gleich NULL sein, wenn stattdessen die Geometrie in einem nativen Format gegeben ist (vgl. Abs. 2.1.3). CS_SRS Die Tabelle CS_SRS ist eine Oracle-Systemtabelle, in der Koordinatenreferenzsysteme mit ihrer Definition abgelegt sind. Jede Oracle-Geometrie verweist auf den entspechenden Eintrag durch Angabe der ID in dieser Tabelle, der SRID. Die Tabelle CS_SRS wurde um den Ein-trag für das Berliner Soldner-System erweitert. Für diese wurde die SRID 81989002 gewählt.

2.2.3.5 Gebäudemodell BUILDING Das in Abschnitt 2.1.4 abstrakt beschriebene Gebäudemodell wird durch die Tabellen in Abb. 2.11 umgesetzt. Die drei UML-Klassen AbstractBuilding, Building und BuildingPart wurden dabei zu einer einzelnen Tabelle BUILDING verschmolzen. Die Unterklassenbeziehung zu CITYOBJECT ergibt sich aus identischen IDs (Relation GEN_ID_ID_10).

Die Bedeutung und der Name der meisten Felder ist identisch zu denen der Attribute im UML-Diagramm, so dass hier darauf verwiesen werden kann. Die Geometrie wird durch die drei Fremdschlüssel LOD1_SURFACE_ID bis LOD3_SURFACE_ID repräsentiert, die auf Einträge in der SURFACE_GEOMETRY-Tabelle verweisen und die Geometrie in jeweils einem LoD umsetzen. Diese Fremdschlüssel verweisen auf eine Surface, die ein Flächenag-gregat – in der Regel ein Volumen – bildet (vgl. das Beispiel in 2.2.2.3). Zusätzlich können noch rein flächenhafte Bestandteile (z.B. Dachüberhänge) mit aggregiert sein.

Die Bestandteilshierarchie innerhalb eines Gebäudes wird durch den Fremdschlüssel BUIL-DING_AGGREGATE_ID realisiert (REL_BUILD_AGG_ID_ID), der auf das darüberliegen-de Gebäudeaggregat verweist, und NULL enthält, falls dieses nicht existiert. Somit ergibt sich auch bei den Gebäudeaggregaten eine Baumstruktur, wobei BUILDING_AGGREGATE_ID jeweils auf den Vorgänger im Baum zeigt. BUILDING_GROUP Gebäudegruppen sind in der Tabelle BUILDING_GROUP abgelegt. Die Zugehörigkeit eines Gebäudes zu einer Gruppe ergibt sich dabei durch den Fremdschlüssel BUIL-DING_GROUP_ID in der Tabelle BUILDING (REL_MBUILD_ID_ID). Die Beziehung ei-ner Gruppe zu ihrem Haupthaus wird durch den Fremdschlüssel MAINBUILDING_ID in der Tabelle BUILDING_GROUP repräsentiert. BUILDING_OPENING Öffnungen (UML-Klasse Opening) werden durch die Tabelle BUILDING_OPENING reprä-sentiert. Dabei wird ebenfalls auf eigene Tabellen für die Unterklassen verzichtet und diese Differenzierung durch das Feld TYPE bei BUILDING_OPENING (gültige Werte sind „Door“ und „Window“; es sind aber auch andere Werte möglich) geleistet. Die Unterklassen-beziehung der Öffnung zur THEMATIC_SURFACE ergibt sich durch gemeinsame IDs, und die Relation zur umgebenden Fläche durch den Fremdschlüssel SURROUNDING_SUR-FACE_ID in der Tabelle BUILDING_OPENING.

3D-Geodatenbank Berlin 2. Datenmodellierung

26

Abbildung 2.11: Tabellen für das Gebäudemodell

3D-Geodatenbank Berlin 2. Datenmodellierung

27

THEMATIC_SURFACE Thematische Begrenzungsflächen (UML-Klasse BoundarySurface) repräsentiert die Tabelle THEMATIC_SURFACE. Auf eigene Tabellen für die Unterklassen GroundSurface,... von BoundarySurface wurde in dem Tabellenschema verzichtet, stattdessen gibt das Feld Type der Tabelle THEMATIC_SURFACE die Art der Begrenzungsfläche an. Mögliche Werte für die-ses Feld Type sind die Namen der Unterklassen von BoundarySurface (“ClosureSurface“, “GroundSurface“, “WallSurface“, “RoofSurface“), es kann aber auch andere Werte enthalten.

Die Aggregationsbeziehung zwischen Gebäuden und den zugehörigen Begrenzungsflächen ergibt sich aus dem Fremdschlüssel BUILDING_ID der Tabelle THEMATIC_SURFACE, der auf die ID des zugehörigen Gebäudes verweist. THEMATIC_SURFACE_GEOMETRY Da die Relation zwischen THEMATIC_SURFACE-Tupeln und ihrer Geometrie eine m:n-Beziehung ist, wird diese durch eine eigene Tabelle THEMATIC_SURFACE_GEOMETRY umgesetzt, die einer THEMATIC_SURFACE ID eine SURFACE_GEOMETRY ID zuordnet und zugleich den LoD dieser Repräsentation im Feld LOD angibt.

Thematische Flächen und das zugehörige Gebäude müssen sich ihre Geometrie teilen, d.h. diese ist nur einmal vorhanden und wird gemeinsam genutzt. Die SURFACE_GEOMETRY, die z.B. ein Dach geometrisch definiert, muss zugleich Teil der Volumengeometrie des Ge-bäudes sein, zu der das Dach gehört.

Die nächste freie ID für die Tabelle THEMATIC_SURFACE_GEOMETRY wird durch die Sequenz THEMATIC_SURFACE_GEOM _SEQ bereitgestellt. Beispiel: In der Abb. 2.12 ist die Geometrie eines Gebäudes, das aus einem geschlossenen Volumenkörper und zwei Dachüberständen besteht, dargestellt. Soll das Dach im LoD2 als eigenständige THEMATIC_SURFACE modelliert werden, neben dem Gebäude mit einer LOD2-Geometrie, so ergeben sich die folgenden Tabellen:

SURFACE_GEOMETRY ID PARENT_ID GEOMETRY IS_SOLID ...... ... ... ... ... ....... 1 10 Geometrie der Fläche 1 0 ....... 2 10 Geometrie der Fläche 2 0 ....... 3 10 Geometrie der Fläche 3 0 ....... 4 10 Geometrie der Fläche 4 0 ....... 5 10 Geometrie der Fläche 5 0 ....... 6 10 Geometrie der Fläche 6 0 ....... 7 10 Geometrie der Fläche 7 0 ....... 8 11 Geometrie der Fläche 8 0 9 11 Geometrie der Fläche 9 0 10 11 NULL 1 ....... 11 NULL NULL 0 ....... .... .... ....... ...... .......

3D-Geodatenbank Berlin 2. Datenmodellierung

BUILDING ID ......... LOD2_SURFACE_ID ...... ... ......... ... ....... 333 ......... 11 ....... .... ......... .... .......

THEMATIC_SURFACE ID Name Typ BUILDING_ID ... ......... ... ....... 555 „Dachfläche_links“ „RoofSurface“ 333 556 „Dachfläche_rechts“ „RoofSurface“ 333 .... ......... .... .......

THEMATIC_SURFACE_GEOMETRY ID SURFACE_ID LOD THEMATIC_SURFACE_ID ... ......... ... ....... 123 7 2 556 124 8 2 556 125 9 2 555 126 6 2 555 .... ......... .... .......

In dDefiGebädurcmen BUILDie TERsprecrie iLOD

1

23

45

6 7

8

9

Abbildung 2.12: Sieben Surfaces, die ein geschlossenes Volumen bilden, sowie zwei Flächen (8und 9, rot hervorgehoben), die einen Dachüberstand repräsentieren.

28

em Beispiel dienen die SURFACE_GEOMETRIE-Tupel mit IDs 6 und 7 zugleich der nition der Dachflächen und der Geometrie des Aggregats, das den Volumenkörper des udes bildet. Die Flächen 1 – 7 werden zunächst zum Surface-Tupel 10 aggregiert und

h IS_SOLID=1 als geschlossener Volumenkörper angezeigt, der dann wiederum zusam- mit den Flächen 8 und 9 zum Surface-Tupel 11 aggregiert wird.

DING_CHARACTERISTIC UML-Klasse BuildingCharacteristic wird durch die Tabelle BUILDING_CHARAC-ISTIC umgesetzt, mit identischen Attributen bzw. Feldern. Die Beziehung zu dem ent-henden Gebäude ergibt sich aus dem Fremdschlüssel BUILDING_ID, und die Geomet-

n den LoD 2 und 3 durch die Fremdschlüssel LOD2_SURFACE_GEOMETRY und 3_SURFACE_GEOMETRY zur Tabelle SURFACE_GEOMETRY.

3D-Geodatenbank Berlin 2. Datenmodellierung

29

ADDRESS, ADDRESSTOBUILDING und ADDRESS_SEQ Adressen setzt die Tabelle ADDRESS um. Die m:n-Relation zu Gebäuden ergibt sich aus der Tabelle ADRESSTOBUILDING, die eine Gebäude-ID einer Adress-ID zuordnet. Einer Tür (Tabelle BUILDING_OPENING) kann eine Adresse durch den Fremdschlüssel ADDRESS_ID in der Tabelle BUILDING_OPENING zugewiesen werden.

Die nächste freie ID für die Tabelle ADDRESS wird durch die Sequenz ADDRESS_SEQ bereitgestellt.

2.2.3.6 Digitales Geländemodell Das Datenbankschema des Digitalen Geländemodells entspricht weitgehend der UML-Modellierung. (vgl. Abschnitt 2.1.5) RELIEF Ein Tupel in der Tabelle RELIEF repräsentiert ein komplexes Reliefobjekt, das aus verschie-denen Reliefkomponenten besteht. Es hat ein Attribut LODGROUP, das die Zugehörigkeit des komplexen Reliefobjekts zu einem Level of Detail (LOD) eines Stadtmodells beschreibt. Darüber hinaus besitzt es das Attribut NAME, das die Bezeichnung des Reliefs enthält. Die einzelnen Komponenten eines komplexen Reliefobjekts sind in den Tabellen BREAKLI-NE_RELIEF, MASSPOINT_RELIEF, TIN_RELIEF und RASTER_RELIEF abgelegt. Um das Datenbankschema flacher und effizienter zu halten wurde auf die Definition einer Ober-klassentabelle RELIEFCOMPONENT verzichtet. Jede Reliefkomponente hat ein Attribut LOD, das die Zugehörigkeit zu einem Detaillierungsgrad (Auflösung, Genauigkeit) be-schreibt. Die einzelnen Komponenten eines komplexen Reliefobjekts können durchaus zu verschiedenen LOD gehören und heterogen sein, d.h. eine Mischung aus TINs, Rastern und Massenpunkten. Die geometrische Abgrenzung zwischen diesen einzelnen Reliefkomponen-ten eines komplexen Reliefobjekts erfolgt durch Polygone (Attribut EXTENT), die den Gül-tigkeitsbereich der Reliefkomponente angeben. Jede Reliefkomponente hat ein Attribut NA-ME, das der Benennung der Komponente dient. Sowohl das Relief wie auch jede Reliefkom-ponente sind von CITYOBJECT abgeleitet und erhalten die gleiche ID wie das Cityobject. Der Fremdschlüssel-Constraint eines Reliefs auf die CITYOBJECT-Tabelle ist mit GEN_ID_ID_1 bezeichnet.

Die Tabellen RELIEF, BREAKLINE_RELIEF, MASSPOINT_RELIEF, TIN_RELIEF, RASTER_RELIEF, BREAKLINE, TRIANGLE und MASSPOINT werden unter Verwen-dung des Oracle Workspace Managers versioniert.

Geometrieattribute des Oracle-Datentyps SDO_GEOMETRY werden in den nachfolgend beschriebenen Reliefkomponenten auf folgende Wertebereiche beschränkt:

• Tabelle BREAKLINE_RELIEF – Attribut BREAKLINE_PROPERTY – SDO_GTYPE: MULTILINE

• Tabelle TIN_RELIEF – Attribut TIN_PROPERTY – SDO_GTYPE: MULTIPOLY-GON

• Tabelle MASSPOINT_RELIEF – Attribut MASSPOINT_PROPERTY – SDO_GTYPE: MULTIPOINT

• Die Rasterkomponententabellen BREAKLINE_RELIEF, MASSPOINT_RELIEF, RASTER_RELIEF, TIN_RELIEF – Attribut EXTENT – SDO_GTYPE: 3D-POLY-GON, d.h. die SDO_GEOMETRIE ist eingeschränkt auf SDO_GTYPE=3003, SDO_ETYPE=1003 und SDO_INTERPRETATION=1 oder SDO_INTERPRETA-TION = 3 für ein RECTANGLE.

3D-Geodatenbank Berlin 2. Datenmodellierung

30

Abbildung 2.13: Tabellen zur Realisierung des Digitalen Geländemodells

3D-Geodatenbank Berlin 2. Datenmodellierung

31

• Die Rasterimporttabelle RASTER_RELIEF_IMP – Attribut FOOTPRINT – SDO_GTYPE: 3D-POLYGON, d.h. die SDO_GEOMETRIE ist eingeschränkt auf SDO_GTYPE = 3003, SDO_ETYPE = 1003 und SDO_INTERPRETATION = 1 oder SDO_INTERPRETATION = 3 für ein RECTANGLE.

BREAKLINE_RELIEF und BREAKLINE Die Tabelle BREAKLINE speichert die Geometriekomponente einer Bruchkante in dem Att-ribut GEOMETRY. Über das Attribut BREAKLINE_RELIEF_ID wird auf die BREAKLI-NE_RELIEF Tabelle verwiesen. Der dazu gehörende Constraint trägt den Namen REL_BRKLINE_RLF_ID_ID.

Über den Fremdschlüssel RELIEF_ID wird eine Bruchkantenkomponente zu dem Gelände-modell (Relief) zugeordnet. Der dazu gehörende Constraint trägt den Namen AGG_BREAK-LINE_ID_ID. MASSPOINT_RELIEF und MASSPOINT Die Tabelle MASSPOINT speichert die Geometriekomponente der Geländemesspunkte in dem Attribut GEOMETRY. Über das Attribut MASSPOINT_RELIEF_ID wird auf die MASSPOINT_RELIEF Tabelle verwiesen. Der dazu gehörende Constraint trägt den Namen REL_MPOINT_RLF_ID_ID.

Über den Fremdschlüssel RELIEF_ID wird eine Bruchkantenkomponente zu dem Gelände-modell (Relief) zugeordnet. Der dazu gehörende Constraint trägt den Namen AGG_RE-LIEF_ID_ID_4. TIN_RELIEF und TRIANGLE Die Tabelle TRIANGLE speichert die Geometriekomponente eines TINs in dem Attribut GEOMETRY. Über das Attribut TIN_RELIEF_ID wird auf die TIN_RELIEF Tabelle ver-wiesen. Der dazu gehörende Constraint trägt den Namen REL_TIN_RLF_ID_ID.

Über den Fremdschlüssel RELIEF_ID wird eine Bruchkantenkomponente zu dem Gelände-modell zugeordnet. Der dazu gehörende Constraint trägt den Namen AGG_RE-LIEF_ID_ID_2. RASTER_RELIEF und RASTER_RELIEF_IMP Die Tabelle RASTER_RELIEF ist im Gegensatz zu den anderen Reliefkomponenten wegen der Verbindung zu der Objekttabelle (RASTER_RELIEF_RDT) mit den Rasterdaten nicht versioniert. Das Attribut RASTERPROPERTY ist vom Typ SDO_GEORASTER. In dem Attribut werden die DGM-Rasterdaten mit Hilfe der Stored Procedure mosaicRasterReliefIni-tial aus den einzelnen Rasterkacheln der Importtabelle RASTER_RELIEF_IMP erzeugt und gespeichert. Ein RASTER_RELIEF ist ein Cityobjekt und erhält einen Fremdschlüssel auf dessen ID Attribut. Die referentielle Integrität muss manuell sichergestellt werden, da die Ak-tivierung der Versionierung über den Oracle Workspace Manager keine Fremdschlüssel von den nicht versionierten auf versionierte Tabellen erlaubt.

Die Tabelle RASTER_RELIEF_IMP wird für den Import der einzelnen Rasterkacheln ver-wendet. Mit Hilfe der Stored Procedure mosaicRasterReliefInitial wird aus diesen Kacheln ein einzelnes Raster erzeugt und in der Tabelle RASTER_RELIEF abgelegt. Das Attribut FILENAME enthält den Namen der Datei, aus der die Kachel importiert wurde. Der geomet-rische Gültigkeitsbereich oder die Ausdehnung einer Kachel wird in dem Attribut FOOTPRINT abgespeichert. Die Tabelle ist nicht versioniert.

3D-Geodatenbank Berlin 2. Datenmodellierung

32

RASTER_RELIEF_RDT Die Tabelle RASTER_RELIEF_RDT wird vom Typ SDO_RASTER abgeleitet und dient als Container für die Rasterdaten der Tabelle RASTER_RELIEF. Diese Objekttabelle kann unter Oracle 10g nicht unter der Verwendung des Workspace Mananagers versioniert gespeichert werden. RASTER_RELIEF_IMP_RDT Die Tabelle RASTER_RELIEF_IMP_RDT wird vom Typ SDO_RASTER abgeleitet und dient als Container für die Rasterdaten der Tabelle RASTER_RELIEF_IMP. Die Objekttabel-le ist nicht versioniert. ID-Sequenzen Für die Objekte, die nicht von CITYOBJECT abgeleitet sind, werden folgende Sequenzen zur automatischen Inkrementierung der IDs angelegt:

Sequenz Zugehörige Tabelle BREAKLINE _SEQ BREAKLINE MASSPOINT_SEQ MASSPOINT TRIANGLE _SEQ TRIANGLE RASTER_RELIEF_IMP_SEQ RASTER_RELIEF_IMP RASTER_RELIEF_RDT_SEQ RASTER_RELIEF_RDT RASTER_RELIEF_RDT_IMP_SEQ RASTER_RELIEF_IMP_RDT

2.2.3.7 Orthophotos Die Modellierung des ORTHOPHOTO-Datenbankschemas entspricht weitgehend der UML-Modellierung. (vgl. Abschnitt 2.1.6) ORTHOPHOTO und ORTHOPHOTO_IMP Die Tabelle ORTHOPHOTO wird wegen der Verbindung zu der Objekttabelle ORTHO-PHOTO_RDT nicht versioniert. Das Attribut ORTHOPHOTOPROPERTY ist vom Typ SDO_GEORASTER. In dem Attribut werden die ORTHOPHOTOS mithilfe der Stored Pro-cedure mosaicOrthophotoInitial aus den einzelnen Orthophotokacheln der Importtabelle OR-THOPHOTO_IMP erzeugt und gespeichert. Ein Orthophoto ist ein Cityobjekt und erhält ei-nen Fremdschlüssel auf dessen ID-Attribut. Die referentielle Integrität muss manuell sicher-gestellt werden, da die Versionsverwaltung des Oracle Workspace Managers keine Fremd-schlüssel von den nicht versionierten auf versionierte Tabellen erlaubt.

Die Tabelle ORTHOPHOTO_IMP wird für den Import der einzelnen Rasterkacheln verwen-det. Mit Hilfe der Stored Procedure mosaicRasterReliefInitial wird aus diesen Kacheln ein einzelnes Raster erzeugt und in der Tabelle ORTHOPHOTO abgelegt. Das Attribut FILE-NAME erhält den Namen der Datei, aus der die Kachel importiert wurde. Der geometrische Gültigkeitsbereich oder die Ausdehnung einer Kachel wird in dem Attribut FOOTPRINT ab-gespeichert. ORTHOPHOTO_RDT Die Tabelle ORTHOPHOTO _RDT wird vom Typ SDO_RASTER abgeleitet und dient als Container für die Rasterdaten der Tabelle ORTHOPHOTO. Die Tabelle ist nicht versioniert.

3D-Geodatenbank Berlin 2. Datenmodellierung

33

Abbildung 2.14: Diagramm für die Tabellen für Orthophotos

3D-Geodatenbank Berlin 2. Datenmodellierung

34

ORTHOPHOTO_IMP_RDT Die Tabelle ORTHOPHOTO_IMP_RDT wird vom Typ SDO_RASTER abgeleitet und dient als Container für die Rasterdaten der Tabelle ORTHOPHOTO_IMP. Die Tabelle ist nicht versioniert. ID-Sequenzen Für die Objekte, die nicht von CITYOBJECT abgeleitet sind, werden folgende Sequenzen zur automatischen Inkrementierung der IDs angelegt:

Sequenz Tabelle ORTHOPHOTO_IMP_SEQ ORTHOPHOTO_IMP ORTHOPHOTO_RDT_SEQ ORTHOPHOTO_RDT ORTHOPHOTO_IMP_RDT_SEQ ORTHOPHOTO_IMP_RDT

3D-Geodatenbank Berlin

35

3 Versions- und Historienverwaltung 3.1 Konzept der Versionen und CityModelAspects Der Nutzen der 3D-Geodatenbank beschränkt sich nicht auf die reine Repräsentation des ak-tuellen Datenbestandes und die Verwaltung des zeitlichen Verlaufs dieser Daten (Historie). Vielmehr kann der Datenbestand dazu genutzt werden, bestimmte Stadtbereiche neu zu pla-nen. Diese Planungsvorhaben zeichnen sich dadurch aus, dass unterschiedliche Entwürfe und Modelle (Versionen) des selben räumlichen Ausschnitts existieren. Das in diesem Kapitel vorgestellte Datenbankschema bietet die Möglichkeit, räumlich festgelegte Planungsgebiete zu definieren und jedem Planungsgebiet beliebig viele Planungsalternativen zuzuordnen.

Zur Verdeutlichung des Nutzen und der Notwendigkeit der Versions- und Historienverwal-tung hier ein einführendes Beispiel:

Zum Zeitpunkt t wird beschlossen, Änderungsmaßnahmen in den Stadtteilen Prenzlauer Berg und Kreuzberg durchzuführen. Es werden hierfür Planungsgebiete definiert und räumlich ein-gegrenzt. Die Stadtplaner A und B planen jeweils eigene Entwürfe für das Gebiet Prenzlauer Berg. Die Stadtplaner I und II tun dies für das Gebiet Kreuzberg. Ihre Planungen beruhen alle auf dem gleichen Grunddatenbestand des Zeitpunkts t. Jeder Stadtplaner wird in seinen Pla-nungen bestehende Gebäude entfernen oder ändern und neue Gebäude hinzufügen. Teilweise werden die Stadtplaner A und B bzw. I und II das gleiche, im Grunddatenbestand befindliche Gebäude ändern.

Zur Präsentation von Teilergebnissen oder Abstimmung zwischen den Entwürfen für den Prenzlauer Berg und Kreuzberg ist es beispielsweise notwendig, die Planungen von A und I zu kombinieren und in einem gemeinsamen 3D-Stadtmodell darzustellen.

Ebenso kann es notwendig sein, die Planung vom Stadtplaner B noch einmal auf den mittler-weile überschriebenen Stand vom Zeitpunkt t1 zurückzusetzen oder den gesamten Datenbank-zustand incl. aller Planungen noch einmal von dem Stand zum (vergangenen) Zeitpunkt t2 zu betrachten.

Abbildung 3.1: Übersicht über Versions- und Historienverwaltung bei parallelen Planungen und die verwendeten Bezeichnungen

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

36

Alle im Beispiel beschriebenen Szenarien können mit dem im Folgenden dargestellten Daten-bankschema realisiert werden. Zur Historienverwaltung und Versionierung der Daten wird das Workspace Manager Konzept genutzt, das vom Oracle 10g DBMS bereitgestellt wird1.

Abbildung 3.1 zeigt die Hierarchie paralleler Planungen und verdeutlicht die im Folgenden verwendeten Bezeichnungen:

• LIVE ist der Originaldatenbestand (GeneralWorkspace) auf dessen Grundlage Pla-nungen durchgeführt werden.

• Planungen (Planning) sind räumlich festgelegte Gebiete.

• Planungsalternativen (PlanningAlternative) sind (beliebig viele) parallel existierende Varianten von Änderungen, die einer Planung zugeordnet sind.

• Ansichten (CityModelAspect) sind Sichten, die Planungsalternativen unterschiedlicher Planungen kombiniert darstellen. Hier darf maximal eine Planungsalternative pro Pla-nung gewählt werden.

Alle in der Abbildung als Oval dargestellten Objekte (GeneralWorkspace, PlanningAlternati-ve und CityModelAspect) werden als Workspaces des Oracle Workspace Managers realisiert und zusätzlich mit Metadaten in eigenen Tabellen verwaltet. Die Abhängigkeiten und Zu-sammenhänge der einzelnen Elemente zeigt das UML-Diagramm in Abbildung 3.2.

1 An dieser Stelle sei das offizielle Handbuch zum Oracle Workspace Manager erwähnt. Es ist unter der ID B10824-01 mit dem Titel „Application Develeoper’s Guide – Workspace Manager“ auf der Webseite der Fa. Oracle zu finden und bietet weitreichendere Informationen zum Umgang mit Workspaces.

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

37

Abbildung 3.2: UML-Diagramm mit Klassen, Attributen und Methoden für parallele Planungen.

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

38

3.2 Umsetzung in Oracle Zur Umsetzung des oben beschriebenen Konzepts der parallelen Planung unterschiedlicher Varianten werden Funktionen des Oracle Workspace Managers verwendet.

Das Datenbankschema der 3D-Geo-Datenbank wird um einige Tabellen zur Speicherung von Metadaten der Versionsverwaltung erweitert (vgl. Abb. 3.3). Die jeweiligen Spaltenbezeich-nungen und –typen sind dem grafischen Schema zu entnehmen, ihre Bedeutung und Funktion werden unten im Kapitel 3.3 (Administrationsprogramm PlanningManager) erläutert.

Abbildung 3.3: Datenbankschema für parallele Planungen.

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

39

Da die eigentliche Versionierung und Historienverwaltung vom Oracle Workspace Manager übernommen wird, dienen die Metadatentabellen und die zugehörigen Prozeduren einer „Ver-sionierung der Versionierung“. Zur Führung einer lückenlosen Versionsdokumentation und Historie werden zu keinem Zeitpunkt Daten gelöscht. So werden abgeschlossene Planungen und Planungsalternativen lediglich als „beendet“ gekennzeichnet. Die zugeordneten Workspaces werden aber nicht gelöscht. Wird bei der Abfrage der Datenbank ein Betrach-tungszeitpunkt aus der Vergangenheit gewählt, so kann der zu diesem Zeitpunkt gültige Da-tenbankbestand betrachtet werden.

Um die Integrität der Daten zu gewährleisten, ist ein direkter schreibender Zugriff auf die Tabellen durch Nutzer oder Anwendungsprogramme nicht vorgesehen. Aus diesem Grund werden eine Reihe von Prozeduren für diesen Zweck bereitgestellt. Sie werden in den nach-folgenden Kapiteln beschrieben. Mit diesen Prozeduren ist es Anwendungsprogrammen mög-lich, die Versionsverwaltung innerhalb ihrer Programmfunktionalität zu bedienen.

Es wird auch eine grafische Benutzerschnittstelle (PlanningManager, vgl. Kapitel 3.3) zur Verfügung gestellt, die ebenfalls auf diese Methoden zurück greift.

Hinweis: Für die Verwendung der Prozeduren mit SQL*Plus (Kommandozeile) muss der Parameter SERVEROUTPUT auf ON gesetzt sein (Befehl: SET SERVEROUTPUT ON), damit ein Rückgabewert angezeigt werden kann.

In den folgenden Kapiteln werden die einzelnen Prozeduren vorgestellt und erläutert. Tabelle 3.1 bietet einen Überblick über die Prozeduren.

Name der Funktion Beschreibung Kap.

AcceptPlanning Übernehmen einer Planungsalternative 3.2.4

AddPlanning Eröffnen einer Planung 3.2.1

DiscardPlanning Beenden einer Planung 3.2.3

UpdatePlanning Aktualisieren der Metadaten einer Planung 3.2.2

AddPlanningAlternative Eröffnen einer Planungsalternative 3.2.5

DeleteAllPlanningAlternatives Löschen aller Planungsalternativen u. Workspa-ces

3.2.13

DeleteTermPlanningAlternatives Löschen aller beendeten Planungsalternativen u. Workspaces

3.2.14

DiscardPlanningAlternative Beenden einer Planungsalternative 3.2.7

GetAllConflicts Abfrage der Konflikte aller Planungsalternativen 3.2.11

GetAllDiff Abfrage der Differenzen aller Planungsalternati-ven

3.2.9

GetConflicts Abfrage der Konflikte einer Planungsalternati-ven

3.2.10

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

40

GetDiff Abfrage der Differenzen einer Planungsalterna-tiven

3.2.8

RefreshPlanningAlternative Aktualisieren des Datenbestandes einer Pla-nungsalt.

3.2.12

UpdatePlanningAlternative Aktualisieren der Metadaten einer Planungsal-ternative

3.2.6

AddCityModelAspect Eröffnen eines CityModelAspects 3.2.15

AddPAtoCMA Hinzufügen einer Planungsalternative zu einem CMA

3.2.17

DeleteAllCityModelAspects Löschen aller CityModelAspects incl. Work-spaces

3.2.19

DeleteCityModelAspect Löschen eines CityModelAspects incl. Workspace

3.2.16

RemovePAfromCMA Entfernen einer Planungsalternative aus einem CMA

3.2.18

Tabelle 3.1: Übersicht über Prozeduren zur Verwaltung paralleler Planungen.

3.2.1 AddPlanning Die Prozedur beginnt eine Planung, indem ein Datensatz in der Tabelle PLANNING angelegt wird. Soll zu der Planung keine räumliche Begrenzung gespeichert werden, so ist der Parame-ter mit NULL anzugeben.

Syntax: AddPlanning(

title IN VARCHAR2, description IN VARCHAR2, executive IN VARCHAR2, spatialExtent IN MDSYS.SDO_GEOMETRY);

Parameter: title Kurzbezeichnung der Planung, die in Anwendungsprogrammen (z.B.

PlanningManager) in Menüs angezeigt wird. Diese sollte kurz und ein-deutig sein.

description Beschreibung der Planung (max. 4000 Zeichen)

executive Verantwortliche Person/Stelle für das Anlegen der Planung

spatialExtent räumliche Begrenzung des Planungsgebiets

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

41

3.2.2 UpdatePlanning Die Prozedur ändert die Parameter Titel, Beschreibung, Verantwortliche Stelle und Räumli-che Begrenzung einer bestehenden Planung. Alle vorherigen Inhalte werden überschrieben.

Syntax: UpdatePlanning( id IN NUMBER

title IN VARCHAR2, description IN VARCHAR2, executive IN VARCHAR2, spatialExtent IN MDSYS.SDO_GEOMETRY);

Parameter: id ID der Planung, deren Metadaten geändert werden sollen

title Kurzbezeichnung der Planung

description Beschreibung der Planung (max. 4000 Zeichen)

executive Verantwortliche Person/Stelle für das Anlegen der Planung

spatialExtent räumliche Begrenzung des Planungsgebiets

3.2.3 DiscardPlanning Die Prozedur beendet eine Planung, indem für alle Alternativen und für die Planung selber ein Terminierungsdatum gesetzt wird. Für die Workspaces der Planungsalternativen werden Sa-vepoints mit dem Namen "terminated" gesetzt. Die Workspaces werden nicht gelöscht!

Die Prozedur wird nur ausgeführt, wenn die Planung noch aktiv ist. Es werden nur aktive Al-ternativen beendet.

Syntax: DiscardPlanning(id IN NUMBER);

Parameter: id ID der zu beendenden Planung

3.2.4 AcceptPlanning Die Prozedur beendet eine Planung. Die ausgewählte Planungsalternative wird in den Eltern-workspace LIVE und damit in den Grunddatenbestand überführt. Anschließend wird für alle Alternativen und die Planung selber ein Terminierungsdatum gesetzt. Für die Workspaces der Alternativen werden Savepoints mit dem Namen "terminated" gesetzt. Die Workspaces wer-den nicht gelöscht!

Die Prozedur wird nur dann ausgeführt, wenn die Planung noch aktiv ist und kein Terminie-rungsdatum hat.

Syntax: AcceptPlanning(

planningId IN NUMBER, planningAlternativeId IN NUMBER);

Parameter: planningId ID der zu beendenden Planung

planningAlternativeId ID der zu übernehmenden Planungsalternative

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

42

3.2.5 AddPlanningAlternative Die Prozedur legt einen Datensatz in der Tabelle PLANNING_ALTERNATIVE an und er-zeugt einen Workspace. Der Workspacename setzt sich aus der Kennung 'PA', der ID der Pla-nung und der ID der Planungsalternative zusammen (z.B. PA_37_5) und wird aus dem Workspace LIVE abgeleitet.

Die Prozedur wird nur ausgeführt, wenn die angegebene Planung noch aktiv ist.

Syntax: AddPlanningAlternative(

planningId IN NUMBER , title IN VARCHAR2, description IN VARCHAR2, generator IN VARCHAR2, planner IN VARCHAR2);

Parameter: planningId ID der Planung, der eine Alternative hinzugefügt werden soll

title Kurzbezeichnung der Planungsalternative, die in Anwendungspro-grammen (z.B. PlanningManager) in Menüs angezeigt wird. Diese soll-te kurz und eindeutig sein.

description Beschreibung der anzulegenden Alternative (max. 4000 Zeichen)

generator Name desjenigen, der die Alternative in der Datenbank anlegt hat

planner Name des Autors dieser Alternative (Planer, Architekt)

3.2.6 UpdatePlanningAlternative Die Prozedur ändert die Parameter Titel, Beschreibung, Datenbankerzeuger und Planer einer bestehenden Planungsalternative. Alle existierenden Einträge werden überschrieben.

Syntax: UpdatePlanningAlternative(

id IN NUMBER, title IN VARCHAR2, description IN VARCHAR2, generator IN VARCHAR2, planner IN VARCHAR2);

Parameter: id ID der Planungsalternative, die geändert werden soll.

title Neue Kurzbezeichnung der Planungsalternative

description Neue Beschreibung der Planungsalternative (max. 4000 Zeichen)

generator Neuer Name desjenigen, der die Planungsalternative in der Datenbank anlegt hat

planner Neuer Name des Autors dieser Planungsalternative (Planer, Architekt)

3.2.7 DiscardPlanningAlternative Die Prozedur beendet eine Planungsalternative. In der Tabelle PLANNING_ALTERNATIVE wird ein Terminierungsdatum gesetzt, der zugehörige Workspace wird nicht gelöscht. Es wird

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

43

lediglich ein Savepoint mit dem Namen "terminated" gesetzt. Die Prozedur wird nur ausge-führt, wenn die Planung noch nicht beendet wurde.

Syntax: DiscardPlanningAlternative(id IN NUMBER);

Parameter: id ID der zu beendenden Planungsalternative

3.2.8 GetDiff Die Prozedur gibt die Gesamtzahl der Tupel zurück, die im angegebenen Workspace gegen-über dem Grunddatenbestand (Workspace LIVE) geändert wurden. Zur Berechnung wird die Summe der Differenzen über alle versionierten Tabellen (z.B. BUILDINGS, CITYOBJECT usw.) gebildet.

Diese Zahl ist einerseits ein Indikator für den Umfang der in der Planungsalternativen durch-geführten Änderungen am 3D-Stadtmodell. Andererseits gibt er Aufschluss über die Komple-xität der Übernahme einer Planungsalternative in den LIVE Workspace.

Syntax: GetDiff(workspace IN VARCHAR2);

Parameter: workspace Name des Workspaces (z.B. PA_21_3), dessen Differenzen zu LIVE

gezählt werden sollen

3.2.9 GetAllDiff Die Prozedur ruft die Prozedur GetDiff für alle Workspaces auf, die Planungsalternativen zugeordnet sind. Das Ergebnis gibt also einen Eindruck über den Bearbeitungsstand und –umfang aller Planungen, also der gesamten Datenbank.

Syntax: GetAllDiff();

Parameter: Keine

3.2.10 GetConflicts Die Prozedur gibt die Gesamtzahl der Tupel zurück, die sowohl im Workspace LIVE, als auch im angegebenen Workspace geändert wurden. Zur Berechnung wird die Summe der Konflikte über alle versionierten Tabellen (z.B. BUILDINGS, CITYOBJECT usw.) gebildet.

Die Funktion zeigt also an, ob eine Übernahme der Planungsalternative in den LIVE Workspace (Merge) oder ein Aktualisieren des Datenbestandes einer Planungsalternative mit dem LIVE Workspace (Refresh) möglich ist. Merge und Refresh können nur für Workspaces durchgeführt werden, zwischen denen keine Konflikte bestehen.

Syntax: GetConflicts(workspace IN VARCHAR2);

Parameter: workspace Name des Workspaces (z.B. PA_21_3)

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

44

3.2.11 GetAllConflicts Die Prozedur ruft die Prozedur GetConflicts für alle Workspaces auf, die Planungsalternati-ven zugeordnet sind. Das Ergebnis gibt einen Eindruck der Möglichkeit, die einzelnen Pla-nungen abzuschließen und in den Grunddatenbestand (Workspace LIVE) zu übernehmen.

Syntax: GetAllConflicts();

Parameter: Keine

3.2.12 RefreshPlanningAlternative Die Prozedur aktualisiert die Daten des Workspaces der angegebenen Planungsalternative mit denen des LIVE-Workspaces. Dies ist notwendig, wenn sich der Datenbestand in LIVE seit dem Anlegen der Planungsalternative geändert hat. Das ist beispielsweise dann der Fall, wenn eine andere Planungsalternative in den Workspace LIVE übernommen wurde. Änderungen im LIVE-Workspace werden nicht automatisch in die Kind-Workspaces (Planungsalternativen) übernommen!

Der Aufruf dieser Prozedur ist nur dann möglich, wenn keine Konflikte zwischen dem LIVE Workspace und dem Workspace der angegebenen Planungsalternative existieren. Es werden durch den Aufruf nur die Tupel der versionierten Tabellen geändert, die in LIVE jünger (neu-er) sind, als im Workspace der Planungsalternative. Die Anzahl dieser Tupel kann mit der Prozedur GetDiff vorab analysiert werden.

Vor der Aktualisierung des Workspaces wird ein Savepoint mit dem Namen "refreshed" ge-setzt (ggf. überschrieben), der es ermöglicht, das Datum des letzten Aufrufens der Prozedur zu speichern.

Syntax: RefreshPlanningAlternative(id IN NUMBER);

Parameter: id ID der Planungsalternative

3.2.13 DeleteAllPlanningAlternatives Die Prozedur löscht alle in der Tabelle PLANNING_ALTERNATIVE vermerkten Workspa-ces und die entsprechenden Tupel in der Tabelle. Es werden somit alle Planungsalternativen und ihre Workspaces gelöscht!

Achtung: Dies Prozedur löscht sämtliche Daten der Workspaces unwiderrufbar und dient dem Optimieren der Systemperformance bzw. dem Löschen des Datenbankinhalts.

Syntax: DeleteAllPlanningAlternatives();

Parameter: Keine

3.2.14 DeleteTermPlanningAlternatives Die Prozedur löscht alle in der Tabelle PLANNING_ALTERNATIVE vermerkten beendeten Workspaces und die entsprechenden Tupel in der Tabelle. Es werden somit alle beendeten Planungsalternativen und ihre Workspaces gelöscht!

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

45

Achtung: Dies Prozedur löscht sämtliche Daten der betroffenen Workspaces unwiderrufbar und dient dem Optimieren der Systemperformance und dem Ausdünnen bzw. Optimieren des Datenbestands!

Syntax: DeleteTermPlanningAlternatives();

Parameter: Keine

3.2.15 AddCityModelAspect Die Prozedur erzeugt einen neuen CityModelAspect, schreibt ein neues Tupel in die entspre-chende Tabelle und erzeugt einen neuen Workspace. Der Name des Workspaces setzt sich aus der Kennung 'CMA' und der ID des CityModelAspect zusammen (CMA_ CMAID).

CityModelAspects dienen lediglich der gleichzeitigen Betrachtung mehrerer Planungsalterna-tiven und sind somit temporärer Natur.

Syntax: AddCityModelAspect(

title IN VARCHAR2, description IN VARCHAR2, generator IN VARCHAR2, planningAlternativeId IN NUMBER);

Parameter: title Kurzbezeichnung der Ansicht

description Beschreibung der anzulegenden Ansicht (max. 4000 Zei-chen)

generator Name desjenigen, der die Ansicht anlegt hat

planningAlternativeId ID der darzustellenden Planungsalternative

3.2.16 DeleteCityModelAspect Die Prozedur löscht einen CityModelAspect. Die Tupel in den entsprechenden Metadatenta-bellen (CITY_MODEL_ASPECT und CITY_MODEL_ASPECT_COMPONENT) werden ebenso gelöscht wie der zugeordnete Workspace. Mit dem Löschen von CityModelAspects werden keine Bestands- oder Planungsdaten gelöscht.

Syntax: DeleteCityModelAspect(id IN NUMBER);

Parameter: id ID des zu entfernenden CityModelAspect

3.2.17 AddPAtoCMA Die Prozedur fügt eine Planungsalternative zu einem CityModelAspect hinzu. Die Prozedur wird nur ausgeführt, wenn die angegebene Planungsalternative und die zugehörige Planung noch aktiv sind. Falls schon eine Alternative der selben Planung verwendet wird, bricht die Prozedur ab.

Syntax: AddPAtoCMA(

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

46

cityModelAspectId IN NUMBER, planningAlternativeId IN NUMBER);

Parameter: cityModelAspectId ID des CityModelAspect, dem die Planungsalternative

zugeordnet werden soll.

planningAlternativeId ID der Planungsalternative

3.2.18 RemovePAfromCMA Die Prozedur entfernt eine Planungsalternative aus einem CityModelAspect.

Syntax: RemovePAfromCMA(

cityModelAslpectId IN NUMBER, planningAlternativeId IN NUMBER);

Parameter: cityModelAspectId ID des CityModelAspect, aus dem die Planungsalterna-

tive entfernt werden soll.

planningAlternativeId ID der zu entfernenden Alternative

3.2.19 DeleteAllCityModelAspects Die Prozedur löscht alle CityModelAspects. Die Tupel in den entsprechenden Metadaten-tabellen (CITY_MODEL_ASPECT und CITY_MODEL_ASPECT_COMPONENT) werden ebenso gelöscht wie die zugeordneten Workspaces. Da CityModelAspects nur als temporär definierte Sichten konzipiert sind, werden keine Bestands- oder Planungsdaten gelöscht.

Syntax: RemoveAllCMAWorkspaces();

Parameter: Keine

3.3 Administrationsprogramm „PlanningManager“ Zur einfacheren Verwaltung der Planungen, Planungsalternativen und CityModel-Aspekte dient die grafische Oberfläche PlanningManager. Das Programm setzt eine Java-Installation ab Version 1.4 voraus und kann ohne Installation per Doppelklick auf die Datei PlanningMa-nager.exe gestartet werden. Alternativ kann das Programm über die Kommandozeile gestartet werden. Bei diesem Aufruf können die Datenbankparameter übergeben werden, so dass beim Programmstart sofort eine Datenbankverbindung hergestellt wird. PlanningManager.exe <host> <port> <sid> <user> <password>

oder java –jar PlanningManager.jar <host> <port> <sid> <user> <password>

Anwendungsprogramme, die mit der 3D-Geo-Datenbank arbeiten, können sich durch diesen Kommandozeilenaufruf der Funktionalität des PlanningManagers bedienen. Dies ist gerade beim Arbeiten in oder mit unterschiedlichen Planungsalternativen notwendig. Näheres erfah-ren Sie im Kapitel 3.6 „Nutzung in Anwendungsprogrammen“.

Wird das Programm ohne die Parameter aufgerufen, so kann die Verbindung zur Datenbank über den Menüleistenpunkt „Datenbank“ – „verbinden“ hergestellt werden. Der Verbindungs-

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

47

status wird in der linken unteren Ecke des Programmfensters angezeigt („connected“ oder „disconnected“).

Beim Herstellen der Verbindung mit der Datenbank werden die existierenden und noch nicht terminierten Planungen und Planungsalternativen aus den entsprechenden Tabellen ausgele-sen und in einer Baumansicht dargestellt. Durch die Auswahl einer Planung oder einer Pla-nungsalternative werden die entsprechenden Metadaten angezeigt.

3.3.1 Planungen Im PlanningManager können alle nicht beendeten Planungen verwaltet werden. Abbildung 3.4 zeigt die Metadatenansicht einer Planung. Die gezeigten Informationen haben folgende Bedeutung:

• ID ID der Planung (automatisch fortlaufende Nummerierung)

• Titel Bezeichnung der Planung (256 Zeichen)

• Beschreibung Erläuterung zur Planung (4000 Zeichen)

• Ausführende Stelle Behörde / Betreuung der Planung (256 Zeichen)

• Begrenzung räumliches Begrenzungspolygon (2D) der Planung (Koordina-tenliste s.u.)

• Beginn Datum und Uhrzeit des Anlegens der Planung

• Ende Datum und Uhrzeit des Beendens einer Planung

Abb. 3.4: Anwendungsprogramm PlanningManager: Oberfläche zur Verwaltung von Planungen.

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

48

Grau hinterlegte Informationen werden automatisch generiert und können nicht vom Benutzer bearbeitet werden.

Die räumliche Begrenzung eines Planungsgebiets wird durch eine Liste von Koordinaten an-gegeben, die ein Polygon beschreiben, durch welches das Planungsgebiet begrenzt wird. Es sind folgende Trennzeichen zu verwenden:

• Das Dezimaltrennzeichen ist ein Punkt (“.“)

• Rechtswert und Hochwert werden durch ein Komma zu trennen (“,“)

• Koordinatenpaare (Punkte) sind durch Leerzeichen zu trennen (“ “) Die Eckpunkte des Polygons sind ausschließlich durch Rechts- und Hochwert zu beschreiben, eine Höhenangabe ist unzulässig. Das so eingegebene Polygon wird in der Tabelle PLAN-NING im entsprechenden Feld vom Typ MDSYS.SDO_GEOMETRY gespeichert.

Im Gegensatz zu Oracle Spatial muss bei der Eingabe der Polygonstützpunkte das erste Koor-dinatenpaar nicht noch einmal am Ende der Liste wiederholt werden.

Für die Verwaltung der Metadaten von Planungen stehen folgende Buttons zur Verfügung, die kontextabhängig aktiviert bzw. deaktiviert sind:

• Löschen Löschen der ausgewählten Planung. Eine Planung wird gelöscht, indem in der Tabelle PLANNING das aktuelle Datum in die Spalte TERMI-NATION_DATE des entsprechenden Tupels geschrieben wird. Das Tupel besteht also weiterhin. Die Planung wird im PlanningManager nicht mehr angezeigt.

• Neu Definieren einer neuen Planung. Eine neue Planung wird erzeugt, in-dem die eingegebenen und automatisch erzeugten Metadaten unter ei-ner neuen ID in die Tabelle PLANNING geschrieben werden.

Hinweis: Soll einer neuen Planung keine räumliche Begrenzung zuge-ordnet werden, so ist „null“ (ohne Anführungszeichen) in das entspre-chende Feld einzutragen oder das Feld leer zu lassen!

• Ändern Geänderte Einträge werden übernommen. Die geänderten Metadaten werden in die entsprechende Zeile der Tabelle PLANNING geschrie-ben.

3.3.2 Planungsalternativen Im PlanningManager können alle nicht beendeten Planungsalternativen verwaltet werden. Abbildung 3.5 zeigt die Metadatenansicht einer Planungsalternative. Die gezeigten Informati-onen haben folgende Bedeutung:

• ID ID der Planungsalternative (automatisch fortlaufende Num-merierung)

• Titel Bezeichnung der Planungsalternative (256 Zeichen)

• Beschreibung Erläuterung zur Planungsalternative (4000 Zeichen)

• In DB eingefügt von Name / Benutzername desjenigen, der die Planungsalternative in der Datenbank angelegt hat (256 Zeichen)

• Planer Name des Planers/Architekten der Planungsalternative (256 Zeichen)

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

49

• Workspacename Name des Workspaces der Planungsalternative. Der Name wird automatisch generiert und setzt sich aus der Kennung PA_, der ID der Planung, der diese Planungsalternative zuge-ordnet ist, und der ID der Planungsalternative zusammen. (PA_25_21 ist demnach der Workspace, welcher der Pla-nungsalternativen 21 zugeordnet ist. Die Planungsalternative 21 ist wiederum der Planung 25 zugeordnet.)

Durch Drücken des Buttons wird der Name des Workspaces in die Zwischenablage übernommen. So kann dieser leicht in andere Anwendungsprogramme übernommen werden.

Sollen Geodaten einer Planungsalternative geändert werden (in SQL*Plus oder einem Anwendungsprogramm), so muss vorab der entsprechende Workspace durch den Aufruf EXEC DBMS_WM.GoToWorkspace(’<Workspacename>’) ausgewählt werden.

• Beginn Datum und Uhrzeit des Anlegens der Planungsalternative

• Ende Datum und Uhrzeit des Beendens einer Planungsalternative

Grau hinterlegte Informationen werden automatisch generiert und können nicht vom Benutzer bearbeitet werden.

Abbildung 3.5: Anwendungsprogramm PlanningManager: Oberfläche zur Verwaltung von Planungs-alternativen

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

50

Für die Verwaltung der Metadaten von Planungsalternativen stehen folgende Buttons zur Ver-fügung, die kontextabhängig aktiviert bzw. deaktiviert sind:

• Übernehmen Übernehmen der ausgewählten Planungsalternative. Der Inhalt des ent-sprechenden Workspaces wird in den Workspace LIVE überführt. Der Datenbestand von LIVE (Grunddatenbestand) wird somit geän-dert! Weiterhin werden die Planungsalternative, alle konkurrierenden Planungsalternativen und die Planung selber durch Setzen des Beendi-gungsdatums beendet. Die entsprechenden Tupel verbleiben in den Ta-bellen PLANNING und PLANNING_ALTERNATIVE, sie werden je-doch nicht mehr im PlanningManager angezeigt.

• Löschen Löschen der ausgewählten Planungsalternative. Eine Planungsalternati-ve wird gelöscht, indem in der Tabelle PLANNING_ALTERNATIVE das aktuelle Datum in die Spalte TERMINATION_DATE des entspre-chenden Tupels geschrieben wird. Das Tupel besteht also weiterhin. Für den zugehörigen Workspace wird eine Rücksetzmarke (Savepoint) mit dem Namen „terminated“ gesetzt, der Workspace aber nicht ge-löscht. Die Planungsalternative wird im PlanningManager nicht mehr angezeigt.

• Neu Definieren einer neuen Planungsalternative. Eine neue Planungsalterna-tive kann nur erzeugt werden, wenn eine Planung ausgewählt ist, da ei-ne Alternative genau einer Planung zugewiesen wird. Eine Planungsal-ternative wird erzeugt, indem die eingegebenen und automatisch Meta-daten unter einer neuen ID in die Tabelle PLANNING_ALTER-NATIVE geschrieben werden. Es wird ein neuer Workspace in der Da-tenbank angelegt.

• Ändern Geänderte Einträge werden übernommen. Die geänderten Metadaten werden in die entsprechende Zeile der Tabelle PLANNING_ALTER-NATIVE geschrieben.

3.4 Das Menü Extras Einige Funktionalitäten für Planungsalternativen werden unter dem Menüpunkt Extras ange-boten. Bei Auswahl einer Planung ist der Menüpunkt inaktiv.

• Differenzen Abfrage der Anzahl der Differenzen zwischen dem Workspace LIVE und dem Workspace der gewählten Pla-nungsalternative (vgl. 3.2.8 Prozedur GetDiff). Der Aufruf der Funktion kann einige Zeit (Minuten) in Anspruch nehmen!

• Konflikte Abfrage der Anzahl der Konflikte zwischen dem Workspace LIVE und dem Workspace der gewählten Pla-nungsalternative (vgl. 3.2.10 Prozedur GetConflicts). Der Aufruf der Funktion kann einige Zeit (Minuten) in An-spruch nehmen!

• Aktualisierungsdatum Datum der letzten Aktualisierung des Workspaces der ge-wählten Planungsalternative (vgl. 3.2.12 RefreshPlannin-gAlternative. Wurde noch keine Aktualisierung durchge-führt, so wird das Datum des Anlegens der Planungsalter-native ausgegeben.

3D-Geodatenbank Berlin 3. Versions- und Historienverwaltung

51

• Aktualisieren Aktualisieren des Workspaces der Planungsalternative mit dem derzeitigen Datenbestand des Workspace LIVE.

3.5 Konfliktmanagement Planungsalternativen sind auf der Datenbankseite als Workspaces des Oracle Workspace Ma-nagers realisiert. Ein Workspace ist die logische Gruppierung der Änderungen von Zeilen von versionierten Tabellen (siehe „Oracle - Database Application Developer’s Guide – Workspace Manager“). Alle Workspaces für Planungsalternativen sind vom Workspace LIVE abgeleitet. Es existieren also parallel mehrere Versionen des Originaldatenbestandes LIVE, die den Pla-nungsalternativen entsprechen. Auf Ebene der jeweiligen Planungsalternativen wird der Da-tenbestand modifiziert.

3.5.1 Differenzen Die einzelnen Änderungen der Datensätze eines Workspaces führen sowohl zu Differenzen unter den Planungsalternativen (Workspaces), als auch zu Differenzen zum Originaldatenbe-stand, aus dem sie ursprünglich abgeleitet sind. Um einen Überblick zu bekommen, wie viele Datensätze im Falle der Übernahme einer Planungsalternative in den Originaldatenbestand LIVE (Merging) geändert werden müssen, kann im PlanningManager im Menü Extras der Menüpunkt Differenzen ausgewählt werden. Dort werden die Differenzen zwischen dem Workspace der aktuell gewählten Planungsalternative und dem LIVE Workspace analysiert.

3.5.2 Konflikte Wird ein Datensatz sowohl im Originaldatenbestand des LIVE Workspaces als auch im Workspace einer Planungsalternative geändert, so handelt es sich um einen Konflikt. Eine Überführung der Planungsalternative in den Originaldatenbestand ist bei Existenz von Kon-flikten nicht möglich. Im PlanningManager können Konflikte über das Menü Extras im Me-nüpunkt Konflikte ähnlich den Differenzen, gezählt werden.

Hinweis: Konflikte können immer dann auftreten, wenn die Tupel des Originaldatenbestand nach dem Anlegen einer Planungsalternative geändert werden, die auch in der Planungsalter-native geändert werden! Durch die räumliche Beschränkung der Planungen sind diese Fälle prinzipiell vermeidbar. Konflikte betreffen die Objektebene und müssen unbedingt vor dem Aktualisieren einer Planungsalternative oder der Übernahme einer Planungsalternative gelöst werden. Sinnvollerweise werden Konflikte einzeln gelöst. Dies sollte in einem Anwendungs-programm durch eine grafische Darstellung der beiden Objekte geschehen. Der PlanningMa-nager bietet keine Funktionalität zum Lösen von Konflikten.

3.6 Nutzung in Anwendungsprogrammen Ein Anwendungsprogramm muss, um auf eine Planungsalternative zugreifen zu können, vor der Abfrage der Datenbank in den entsprechenden Workspace der Planungsalternative wech-seln. Dies geschieht durch den SQL Aufruf

EXEC DBMS_WM.GoToWorkspace(’<Name>’)

Wobei <Name> durch den Namen des Workspaces (z.B. PA_32_25) zu ersetzen ist. Der Name des Workspaces einer Planungsalternative kann über das Administrationsprogramm PlanningManager angezeigt und in die Zwischenablage kopiert werden. Hier bietet sich der Aufruf des PlanningManagers mit Übergabe der Datenbankparameter aus dem Anwendungs-programm heraus an.

3D-Geodatenbank Berlin

52

4 Werkzeug für den Datenimport und –export Das Import-/Exportprogramm stellt Funktionen zum Einlesen und Ausgeben von Gebäuden, Digitalen Geländemodellen und Luftbildern zur Verfügung. DGMs und Luftbilder werden in Form von georeferenzierten Rasterdateien (TIFF-Format mit zusätzlichem Worldfile) verar-beitet. Gebäude werden als 3D-Shapefiles gelesen bzw. gespeichert.

Die Importfunktionalität dient dem Befüllen der 3D-Geodatenbank mit neuen Datensätzen. Importierte Geodaten werden dabei als neue Objekte unter Vergabe neuer, eindeutiger Ob-jekt-IDs der Datenbank hinzugefügt. Da keine Datensätze in der Datenbank ersetzt werden, ist der Importer als Werkzeug zur Datenfortführung allerdings nur begrenzt geeignet. Das Befül-len der Datenbank mit Rasterdaten erfolgt durch den Import einzelner Rasterdatenkacheln, die abschließend zu einem großen, homogenen Rasterdatenobjekt (Luftbild bzw. DGM) ver-schmolzen werden.

Mit der Exportfunktionalität können Auszüge der 3D-Geodatenbank generiert werden. Als Auswahlkriterium steht grundsätzlich die Angabe eines umschließenden Rechtecks (Boun-ding Box) zur Verfügung. Bei der Ausgabe von Gebäuden können darüber hinaus auch Ob-jekt-IDs oder die Zugehörigkeit von Gebäuden zu einer CityObject-Gruppierung als Selekti-onskriterium verwendet werden.

Für alle Import- und Exportvorgänge kann grundsätzlich der Oracle-Workspace explizit an-gegeben werden, aus dem die Daten ausgegeben werden bzw. in den die Daten importiert werden sollen (vgl. Kapitel 3). Damit ist beispielsweise möglich, Gebäudeentwürfe gezielt einer Planungsalternative hinzuzufügen.

4.1 Systemvoraussetzungen Das Import/Export-Werkzeug benötigt eine Java Runtime Environment Standard Edition ab der Version 1.4.2 (JRE 1.4.2). Diese kann über folgenden Link heruntergeladen werden:

http://java.sun.com/j2se/1.4.2/download.html

und muss vor dem Ausführen des Import/Export Tool installiert werden. Bitte beachten Sie, dass Sie die betriebssystemspezifische (z.B. Windows, Linux, Solaris) entsprechende JRE herunterladen. Für die JRE 1.4.2 werden ca. 15 MB Festplattenplatz benötigt.

Das Import/Export Tool benötigt ca. 9 MB Festplattenplatz und erfordert mindestens 256 MB Arbeitspeicher. Dieser reicht aus, um kleine Shapefiles (Richtwert: kleiner 10MB) oder Ras-terdaten (Richtwert: kleiner 50 MB) zu im- bzw. exportieren. Für den Import von großen Bil-dern, bspw. die gelieferten Bilder in Originalgröße, wird mindestens 1 GB Arbeitsspeicher vorausgesetzt.

Bitte beachten Sie, dass weiterer Festplattenplatz für den Export benötigt wird. Dieser hängt von der Größe des zu exportierenden Datensatzes ab. Als Richtwert gilt ein Wert von 500 MB für exportierte Daten. Diese können nach dem Export verschoben werden. Ferner wird beim Kacheln von Bildern temporärer Festplattenplatz benötig. Dieser hängt von der Größe des zu kachelnden Bildes ab. (Für die Kachelung sollte genau so viel temporärer Festplattenplatz vorhanden sein wie die Größe des Originalbild selbst.)

4.2 Benutzerschnittstelle Die Anwendung wird mit folgendem Aufruf gestartet: java.exe -Xms256m -Xmx1024m -jar berlin3d_tool.jar jdbc:oracle:thin:@<myserver>:1521:<myDBinstance>

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

53

Hinweis: Für das Betriebssystem Windows besteht die Möglichkeit auch die Programme „javaw.exe“ bzw. „start java.exe“ zu nutzen. Das Kommandofenster zum Start der Applikation wird dadurch geschlossen.

Der angegeben Aufruf startet das Programm mit vier Parametern: den Parametern der Java Virtual Maschine (JVM) für den Hauptspeicher (256 MB als Anfangswert bzw. 1GB maximaler Arbeitspeicher), dem jar-Parameter für die Anwendung und den Datenbank-parametern. Bei Letzteren sind die Parameter <myserver> durch die IP Adresse des Datenbankservers und <myDBinstance> durch die SID der Datenbank zu ersetzen. Der Systemadministrator sollte diese Werte ggf. anpassen.

Alle benötigten Systembibliotheken befinden sich im Unterverzeichnis ./libs/. Diese werden automatisch geladen. Nach erfolgreichem Start erscheint die graphische Benutzerschnittstelle (vgl. Abb. 4.1).

4.2.1 Der Login-Dialog Um Daten zu importieren bzw. exportieren muss sich der Benutzer zuerst bei der Datenbank anmelden. Dazu klickt er auf die Schaltfläche Einloggen, gibt seinen Login-Namen und sein Paßwort ein, und bestätigt die Eingabe mit OK (vgl. Abb. 4.2).

Abbildung 4.1 Das Import/Export Tool

Abbildung 4.2 Anmeldemaske

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

54

Anschließend stellt die Anwendung eine Verbindung zur Datenbank her. Ist die Verbindung aufgebaut, werden die Auswahlliste der Import-Konvertierungsprozeduren (mit Titel „Proze-durbeschreibung“ bzw. „Prozedurname“) und die Auswahlbox „CityObjectGroup“ freige-schaltet. Die Prozedurauswahlliste wird beim Import von Shapefiles verwendet. Sie wird im Folgenden beschrieben.

4.3 Import

4.3.1 Konzept zum Importieren von Shapefiles Für den Import von Geodaten über 3D-Shapefiles musste ein flexibler Konvertierungsmecha-nismus realisiert werden, da die konkreten Attribute und Geometrierepräsentation jeweils von dem Anwendungsprogramm abhängen, das die Shapefiles erzeugt hat. Im Rahmen des initia-len Aufbaus des Berliner 3D-Stadtmodells sind bereits drei unterschiedliche Arten von 3D-Shapefiles zu unterstützen. Beispielsweise sind die Gebäude des Stadtteils Ostkreuz im Sha-pefile der Fa. RealIT als 3D-Multipatches gespeichert, wobei jeder Datensatz genau ein Ge-bäude repräsentiert. Das Shapefile der Fa. RSS des gleichen geographischen Gebiets reprä-sentiert hingegen einzelne Gebäudeteile, wobei die Geometrie in Form von 3D-Grundriss-polygonen gegeben ist. Die Auswahl und Benennung der thematischen Attribute ist ebenfalls verschieden. Der Import von Shapefiles erfolgt aus diesen Gründen in zwei Schritten:

1. Einlesen des Shapefiles in die Datenbank im Rohformat

2. Erzeugen der 3D-Geoobjekte

Im ersten Schritt werden alle Datensätze des Shapefiles uninterpretiert in die Datenbank ko-piert. Für jeden Datensatz wird dabei in der Tabelle CITYOBJECT ein neues Tupel erzeugt, wobei die CLASS_ID auf 0 gesetzt wird. An letzterem kann man in der Tabelle CITYOB-JECT grundsätzlich jene Tupel erkennen, die durch den Importer geladen und noch nicht in-terpretiert wurden, da reguläre CITYOBJECTS eine CLASS_ID>0 besitzen müssen. Für je-des einzelne Attribut des Datensatzes wird dann ein Tupel in der Tabelle CITYOB-JECT_GENERICATTRIB angelegt, wobei je nach Attributdatentyp im Shapefile der entspre-chende Datentyp im Tabellenfeld DATATYPE gesetzt wird und der Attributwert in die zuge-hörige Tabellenspalte STRVAL, INTVAL, REALVAL, DATEVAL oder GEOMVAL ge-schrieben wird. Jedes Tupel erhält zudem im Attribut ATTRNAME den jeweiligen Spalten-namen des Shapefiles und im Attribut CITYOBJECT_ID den Verweis auf den zugehörigen Datensatz in CITYOBJECT. Da Shapefiles pro Datensatz genau eine Geometrie besitzen, wird somit auch genau ein entsprechendes Tupel in CITYOBJECT_GENERICATTRIB pro Datensatz erzeugt. Die Geometrie wird als Oracle-Geometrie (Datentyp MDSYS.SDO_GEO-METRY) gespeichert. Für ein Shapefile mit 375 Datensätzen, das 10 Attribute besitzt (inkl. Geometrie), würden demnach 375 Tupel in CITYOBJECT angelegt und insgesamt 3750 Tu-pel in CITYOBJECT_GENERICATTRIB.

Der zweite Schritt besteht darin, die eingelesenen Daten des Shapefiles zu interpretieren und entsprechende Geoobjekte in der Datenbank daraus zu erzeugen. Da dieser Schritt abhängig vom jeweiligen Shapefiletyp bzw. –hersteller ist, muss für jeden Typ eine eigene Konvertie-rungsprozedur vorgesehen werden. Diese Prozeduren werden als Stored Procedure (PL/SQL-Prozedur ohne Übergabe- und Rückgabeparameter) in der Datenbank gespeichert und jeweils durch einen Eintrag in der Tabelle IMPORT_PROCEDURES registriert. Alle registrierten Konvertierungsprozeduren werden im Import-/Exportprogramm nach dem Einloggen in die Datenbank in einer Auswahlliste präsentiert. Der Vorteil dieser Vorgehensweise besteht darin, dass die Datenbank jederzeit – im laufenden Betrieb – um weitere Konvertierungsprozeduren für neue Shapefile-Typen weiterer GIS-Anwendungen ergänzt werden kann, ohne dass dazu eine neue Version des Import-/Exportprogramms installiert werden muss.

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

55

Die mitgelieferten Konvertierungsprozeduren für die drei zu unterstützenden Shapefile-Typen der Firmen RSS und RealIT werden in Abschnitt 4.5 ausführlich beschrieben.

4.3.2 Durchführung des Shapefile-Imports Für den Import von Shapefiles wird vorausgesetzt, dass der Benutzer sich vorher angemeldet hat. Zuerst klickt der Benutzer auf die Schaltfläche Gebäude, und anschließend auf Öffnen, um ein Shapefile zu öffnen. Gültige Shapefiles sind nur solche, die PolygonZ (Shapetyp 15) oder Multipatches (Shapetyp 31) enthalten. Nach erfolgter Wahl und erfolgreicher Analyse eines Shapefiles wird die Schaltfläche „Import“ freigeschaltet. Nun darf der Benutzer die Da-ten importieren. Zuvor kann er mittels Eingabe ins Textfeld Workspace den Datenbank-Workspace ändern. Das ist notwendig, wenn die Daten für eine Planungsalternative importiert werden sollen. Der entsprechende Workspacename kann mit dem PlanningManager ermittelt und in die Zwischenablage kopiert werden (vgl. 3.3.2). Außerdem kann der Benutzer die nach dem Import aufzurufende Konvertierungsprozedur auswählen. Ein Textfeld unter der Auswahlliste beschreibt die Prozedur näher.

Das Betätigen der Schaltfläche Import startet den Import. Der Benutzer wird nun nach der Datenherkunft gefragt (Abb. 4.3). Diese darf nicht leer sein und nicht mehr als 255 Zeichen enthalten. Der eingegebene Wert wird im Feld LINEAGE aller neu erzeugten Cityobjects gespeichert. Nach Eingabe der Datenherkunft zeigt ein Fortschrittfenster an, wieviele Objekte bereits importiert wurden.

Im Menü Optionen kann man bestimmen, nach wie vielen Objekt ein „commit“ aufgerufen werden soll. Defaulteingabe ist Commit nach 100 Objekten. Dies ist der optimale Wert. Commit nur am Ende des Imports bewirkt einen schnellen Import. Sollte dabei aber etwas nicht in Ordnung sein, z.B. ungültige Daten, dann können unter Umständen die Daten fehler-haft importiert sein. Ein Commit nach jedem Objekt ist langsamer, dafür aber robuster, da dabei nur fehlerhafte Objekte nicht importiert werden. Es wird empfohlen, diese Option nicht zu ändern.

Während eines laufenden Importvorgangs sollte weiterhin keine andere Aktion mit dem Im-port-/Export Tool durchgeführt werden.

4.3.3 Import von Rasterdaten Das Speicherkonzept der 3D-Geo-DB sieht vor, sowohl Luftbilder als auch DGMs für jeden Level-of-Detail als jeweils ein homogenes Rasterdatenobjekt in der Datenbank zu verwalten (vgl. Abschnitt 2.2.2). Um ein solches flächendeckendes Gesamtraster zu erzeugen, müssen die Rasterdaten in Form einzelner „Rasterdatenkacheln“ vorliegen, die zunächst einzeln mit dem Import-/Exportprogramm in die Datenbank geladen werden müssen. Nachdem alle Ka-cheln für einen Level-of-Detail in die Datenbank übertragen wurden, kann der Benutzer durch den Aufruf einer bestimmten Prozedur in der Datenbank das Gesamtraster erstellen lassen. Der Aufruf dieser Prozeduren wird in den folgenden Abschnitten 4.3.3.1 und 4.3.3.2 erläutert.

Abbildung 4.3: Maske zur Eingabe der Lineage

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

56

Um die Rasterdatenkacheln zu importieren, muss der Benutzer am System angemeldet sein. Es besteht die Möglichkeit, die Daten als Luftbilder oder als digitale Geländemodelle zu im-portieren. Voraussetzung hierfür ist, dass eine sog. Worlddatei (Worldfile) mit Koordinatenin-formation vorhanden ist. Diese Datei muss den gleichen Namen wie die Bilddatei haben und statt der Dateierweiterung „.tif“ (für TIFF Datei) „.tfw“ heißen.

Das Tool geht aus davon aus, dass im Worldfile das Trennzeichen für Dezimalstellen ein Punkt “.“ ist, und nicht das Komma! Kommata werden beim Einlesen automatisch in Punkte umgewandelt.

Nach erfolgreicher Auswahl eines TIFF-Bildes klickt der Benutzer auf Import, um den Einle-sevorgang zu starten. Dieser kann bei großen Dateien (500MB) abhängig von der Serverleis-tung und Netzwerkverbindung durchaus 15 Minuten in Anspruch nehmen. Bitte beachten Sie, dass Bilder einzeln hochgeladen werden müssen.

Sollte beim Einlesen sehr großer Rasterdatendateien eine Fehlermeldung bzgl. Speicherplatz-mangels auftreten, kann die Rasterdatendatei vor dem Import in kleinere Kacheln zerlegt wer-den (Richtwert: ab etwa 400MB). Dafür bietet das Tool unter dem Menüpunkt Optionen -> Tile Image eine Kachelungsfunktion. Klickt der Benutzer diesen Menüpunkt an, wird er auf-gefordert, dass zu kachelnde Bild anzugeben. Nach Eingabe des neuen Bildnamen, z.B. „neu-es_Bild“, wird das originale Bild nun in vier Teilbilder zerlegt, die in „neues_bild_0_0.tif“, „neues_bild_0_1.tif“, „neues_bild_1_0.tif“ und „neues_bild_1_1.tif“ benannt werden. Ent-sprechende Worldfile-Dateien werden automatisch generiert.

4.3.3.1 Mosaikbildung von DGMs Die Erstellung eines Gesamtrasterobjekts aus einzelnen Rasterkacheln wird vollständig inner-halb des Oracle-DBMS mittels Stored Procedures ausgeführt. Aufgrund der großen Daten-mengen, die dabei bewegt werden müssen, kann dieser Vorgang einige Stunden bis hin zu einem Tag dauern.

Die Durchführung des sogenannten „Mosaik-Vorgangs“ wird nicht über das Import-/Export-programm gesteuert, sondern muss über die Eingabe des entsprechenden Befehls in einer SQL-Eingabekonsole erfolgen, wie z.B. dem Oracle beiliegenden SQL*Plus oder der Enter-prise Manager Console. Dazu muss sich der Benutzer zunächst in dem Konsolenprogramm bei der 3D-Geodatenbank anmelden. Er kann dann die Prozedur „mosaicRasterReliefInitial“ aufrufen, die alle importierten DGM-Rasterkacheln – wie in einem Mosaik – zu einem Ge-samtrasterobjekt verschmilzt. Damit ein homogener Gesamtrasterdatensatz erzeugt werden kann, müssen verschiedene Voraussetzungen erfüllt sein. So müssen die Kacheln insgesamt ein rechteckiges Gebiet überlappungs- und klaffungsfrei abdecken. Ferner muss die räumliche Auflösung aller Kacheln identisch sein. Nähere Details zu den Voraussetzungen sind in Ab-schnitt 2.2.2 beschrieben.

Die Mosaik-Prozedur generiert über das eigentliche Gesamtraster hinaus ein RasterRelief-Objekt, das schließlich ersteres beinhaltet, sowie ein Relief-Objekt, welches das gesamte DGM für den angegebenen Level-of-Detail repräsentiert (vgl. Modellierung in Abschnitt 2.1.5 sowie DB-Schema in Abschnitt 2.2.3.6). Beide Geoobjekte sind CityObjects, die durch jeweils ein eigenes Tupel in der Tabelle CITYOBJECT sowie je ein zugehöriges Tupel in RASTER_RELIEF und RELIEF repräsentiert werden. Die ID-Werte für die beiden CITYOB-JECT-Tupel werden automatisch generiert und nach erfolgreichem Ablauf der Prozedur in dem Konsolenfenster angezeigt. Sie sollten in einer Datenbank-Dokumentation notiert wer-den, da sie für spätere Zugriffe (z.B. für den Export) wieder benötigt werden.

Die Syntax für den Aufruf der Mosaik-Prozedur lautet wie folgt: execute mosaicRasterReliefInitial(<Name>, <Typ>, <Herkunft>, <LOD>);

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

57

Der Parameter <Name> ist ein Textstring und bezeichnet den Namen des Gesamtrasters (z.B. ’Gesamt-DGM von Berlin’). <Typ> ist ebenfalls vom Typ String und dient zur näheren Be-schreibung der Art der Rasterdaten wie z.B. ’regelmäßiges Raster 0.5m’. Der Textstring <Herkunft> gibt Auskunft über die Datenquelle bzw. den Datenlieferanten (z.B. ’photogram-metrische Bildauswertung von HRSC-Daten, Fa. RSS GmbH’). Der Parameter <LOD> ist vom Typ Integer und darf eine ganze Zahl aus dem Intervall 1-3 sein. Er gibt an, welchem Level-of-Detail das DGM zuzuordnen ist.

Wenn zuvor alle DGM-Kacheln mit dem Import-/Exportprogramm in die Datenbank geladen wurden, könnte das LOD2-Gesamt-DGM von Berlin z.B. durch die Eingabe folgender Befeh-le in SQL*Plus erzeugt werden (bitte den 2. Befehl ohne Zeilenumbruch eingeben): set serveroutput on

execute mosaicRasterReliefInitial (’DGM von Berlin’, ’regelmäßiges Raster 0.5m Auflösung’, ’Photogrammetrische Auswertung, Fa. RSS GmbH’, 2);

4.3.3.2 Mosaikbildung von Luftbildern Die Zusammenstellung des Gesamtluftbildes aus einzelnen Luftbildkacheln erfolgt analog zu der Mosaikbildung von DGMs (siehe vorheriger Abschnitt). Auch hier muss der Benutzer eine in der 3D-Geo-DB befindliche Stored Procedure aufrufen. Diese Mosaik-Prozedur gene-riert ein Orthophoto-Objekt, das das Gesamtraster beinhaltet. Das Orthophoto-Objekt ist ein CityObject, das durch ein Tupel in der Tabelle CITYOBJECT sowie ein zugehöriges Tupel in ORTHOPHOTO repräsentiert wird. Der ID-Wert ist für die beiden Tupel identisch. Er wird automatisch generiert und nach erfolgreichem Ablauf der Prozedur in dem Konsolenfenster angezeigt. Er sollte in einer Datenbank-Dokumentation notiert werden, da er für spätere Zugriffe (z.B. für den Export) wieder benötigt wird. Die Syntax der Mosaik-Prozedur lautet wie folgt: execute mosaicOrthophotosInitial (<Name>, <Typ>, <Herkunft>, <LOD>);

Der Parameter <Name> ist ein Textstring und bezeichnet den Namen des Gesamtrasters (z.B. ’Luftbild von Berlin’). <Typ> ist ebenfalls vom Typ String und dient zur näheren Beschrei-bung der Art der Rasterdaten wie z.B. ’True Orthophoto’. Der Textstring <Herkunft> gibt Auskunft über die Datenquelle bzw. den Datenlieferanten (z.B. ’HRSC-Kamerabefliegung, Fa. RSS GmbH’). Der Parameter <LOD> ist vom Typ Integer und darf eine ganze Zahl aus dem Intervall 1-3 sein. Er gibt an, welchem Level-of-Detail das Luftbild zuzuordnen ist.

Wenn zuvor alle Luftbildkacheln mit dem Import-/Exportprogramm in die Datenbank geladen wurden, könnte das LOD2-Gesamtorthophoto von Berlin z.B. durch die Eingabe folgender Befehle in SQL*Plus erzeugt werden (bitte den 2. Befehl ohne Zeilenumbruch eingeben): set serveroutput on

execute mosaicOrthophotosInitial (’Luftbild von Berlin’, ’True Or-thophoto’, ’HRSC-Kamerabefliegung, Fa. RSS GmbH’, 2);

4.4 Export

4.4.1 Export von Shapefiles Beim Export von Gebäuden wird die komplexe Gebäudemodellierung auf die einfache Struk-tur von Shapefiles abgebildet. Dabei wird jedes einzelne Gebäudeteil als ein Geoobjekt mit dem Geometrietyp "3D-Multipatch" im Shapefile ausgegeben. Da das Shapefile-Format keine

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

58

Möglichkeit zur Aggregation der enthaltenen Geodatensätze bietet, werden Gebäude, die in der Datenbank aus mehreren Aggregationsebenen bestehen, bei der Ausgabe auf eine flache, einstufige Aggregation reduziert. Jedes Gebäudeteil erhält ein Attribut "Building_ID", das die Zugehörigkeit des Teils zu einem bestimmten Gebäude anzeigt. Die skalaren Attribute der Gebäudeteile wie z.B. Name, Geschossanzahlen usw. werden unmittelbar übertragen. Da Shapefiles keine texturierten Flächen zulassen, können Texturen nicht mitexportiert werden. Einzelnen Gebäudeflächen können in der Datenbank noch weitere thematische Informationen zugeordnet sein. Aufgrund der eingeschränkten Möglichkeiten des Shapefile-Formats, können auch diese Informationen beim Shapefile-Export nicht berücksichtigt werden.

Um Gebäudedaten als Shapefile zu exportieren, klickt der Benutzer nach erfolgreicher An-meldung auf die Export Schaltfläche. Hier hat er die Möglichkeit die Export-Bounding-Box (Raumausschnitt) zu bestimmen, in welcher sich die Gebäude befinden. Alternativ kann er die Gebäude IDs (als minimaler und maximaler Wert) eingeben oder die CityObjectGroup in der Auswahlliste bestimmen.

Nach Bestätigen der entsprechenden Schaltfläche wird der Benutzer nach der Zieldatei ge-fragt. Die „.shp“ Erweiterung fügt das Tool automatisch hinzu.

4.4.2 Export von Rasterdaten Der Export von Rasterdaten erfolgt ähnlich wie der von Shapefiles, nur dass hier die Angaben über Gebäude-IDs oder City Object Group irrelevant sind. Es werden bei der Auswahl des zu exportierenden Gebietes nur die Angaben zur Bounding Box berücksichtigt.

Der Benutzer wählt durch einen Klick auf die entsprechende Schaltfläche (Luftbilder bzw. DGM), ob er Luftbild- oder DGM-Daten exportieren möchte.

Nach Betätigen der Schaltfläche Export wird der Benutzer nach der Zieldatei gefragt. Die Dateiendung „.tif“ fügt das Tool automatisch zum Namen hinzu. Neben der Bilddatei wird auch eine Worlddatei mit dem gleichen Namen wie der des Bildes mit der Dateiendung „.tfw“ generiert, die die Georeferenzierungsinformationen zu dem Bild beinhaltet.

4.5 Erläuterung der Import-Konvertierungsprozeduren Dieser Abschnitt erläutert die PL/SQL Prozeduren, die für den Import der Shapefiles der Fir-men RealIT und RSS in die Berliner 3D-Geodatenbank benötigt werden.

Mit Hilfe des Import-/Exportprogramms werden Shapefiles mit 3D-Multipatch- sowie 3D-Polygon-Geometriedaten zunächst uninterpretiert in die 3D-Geo-DB eingelesen. Alle Attribu-te des Shapefiles werden ihrem Typ entsprechend in der CITYOBJECT_GENERICATTRIB gespeichert (siehe Abschnitt 4.3.1). Zur Konvertierung der eingelesenen Shapefiles in 3D-Gebäudeobjekte stehen derzeit die folgenden Prozeduren zur Verfügung: REALIT_MULTI-PATCH, RSS_GRUNDRISSE_MPATCH, RSS_BUILDING_MPATCH.

4.5.1 REALIT_MULTIPATCH Das von der Fa. RealIT gelieferte Shapefile besitzt neben dem Shape-Attribut mit 3D-Multipatch-Geometriedaten nur die Attribute “Building_I“, “X_ref“, “Y_ref“ und “Z_ref“ (siehe Abb. 4.4).

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

59

Abbildung 4.4: Shapefile im RealIT-Format

Das Import-/Exportprogramm importiert diese Attribute entsprechend als GEOM, BUIL-DING_I, X_REF, Y_REF und Z_REF in die Tabelle CITYOBJECT_GENERICATTRIB (siehe Abb. 4.5).

Abbildung 4.5: Importierte RealIT-Daten in der Tabelle CITYOBJECT_GENERICATTRIB

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

60

Die Prozedur REALIT_MULTIPATCH generiert aus den importierten Rohdaten schließlich 3D-Gebäude. Dabei werden folgende Attribute des Shapefiles in die Tabellen SURFACE_-GEOMETRY bzw. BUILDING übernommen: GEOM (SHAPE-Attribut in der Datei) und BUILDING_I (Name des Gebäudes). Nach der Generierung der entsprechenden Datensätze in der Building-Tabelle werden diese beiden Attribute aus der Tabelle CITYOBJECT_GENE-RICATTRIB gelöscht. Die anderen Attribute (X_REF, Y_REF und Z_REF) haben keine Ent-sprechung im Datenmodell und verbleiben deshalb als generische Attribute in der CITYOB-JECT_GENERICATTRIB-Tabelle.

Für die Bestimmung der zu konvertierenden Objekte in der Tabelle CITYOBJECT wird das Attribut CLASS_ID benutzt. Da es keine regulären CityObjects mit der CLASS_ID=0 gibt, wird dieser Wert zur Kennzeichnung importierter Shapefile-Rohdaten verwendet. Es werden zu jedem importierten Cityobject (CLASS_ID=0) die Flächengeometrien mit Hilfe der Stored Procedure GENERATE_SOLID aus der CITYOBJECT_GENERICATTRIB-Tabelle geholt und in der SURFACE_GEOMETRY-Tabelle abgespeichert. In der Tabelle BUILDING wird neben dem Verweis auf die Geometrie in der SURFACE_GEOMETRY-Tabelle (Solid-Aggregat) der Name des Gebäudes abgelegt. Dazu wird das Attribut “Building_I“ des Shape-files verwendet. Nach der Konvertierung wird schließlich die CLASS_ID der betreffenden Tupel in der Tabelle CITYOBJECT auf 10 (= Building) gesetzt.

4.5.2 RSS_GRUNDRISSE_MPATCH Das Shapefile mit Grundrisspolygonen der Fa. RSS GmbH besitzt neben dem Shape-Attribut mit 3D-Polygonen die Attribute “Id“, “AREA“, “PERIMETER“, “GEBT_ID“, “GEB_ID“, “HM_TRAUF“, “HM_RFIRSTN“ und “HM_PLATTE“ (siehe Abb. 4.6).

Abbildung 4.6: Shapefile im RSS-Format mit Grundrissdaten

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

61

Das Import-/Exportprogramm speichert die Attribute des Shapefiles entsprechend in der CI-TYOBJECT_GENERICATTRIB-Tabelle (siehe Abb. 4.7).

Abbildung 4.7: Importierte RSS-Grundrissdaten in der Tabelle CITYOBJECT_GENERICATTRIB

Für die abschließende Konvertierung wird die Prozedur RSS_GRUNDRISSE_MPATCH ver-wendet. Folgende Attribute des Shapefiles werden dabei in die Tabellen SURFACE_GEO-METRY bzw. BUILDING übernommen: GEOM (SHAPE-Attribut in der Datei), GEBT_ID (Name des Gebäudeteils), GEB_ID (Name des Gebäudes), HM_RTRAUF (Gebäudehöhe). Die Grundrisspolygone werden mit Hilfe der EXTRUDE-Prozedur zu 3D-Volumenkörpern extrudiert. Die dazu benötigte Höhe wird dem Attribut HM_RTRAUF entnommen.

Gebäude, die aus mehr als einem Gebäudeteil bestehen, werden als ein Gebäudeaggregat ab-gespeichert. Das Attribut GEBT_ID wird als Name für das Gebäudeteil übernommen. Es wird der Buchstabe „t“ angehängt, um es als Gebäudeteil zu kennzeichnen. Das Attribut GEB_ID wird als Name des Gebäudeaggregats oder Gebäudes, das nur aus einem Gebäudeteil besteht, übernommen. Der Wert des Attributs HM_RTRAUF wird als Gebäudehöhe abgespeichert.

Bei der Konvertierung werden nur solche Tupel in der Tabelle CITYOBJECT berücksichtigt, deren Attribut CLASS_ID = 0 ist. Nach der Konvertierung werden alle importierten Attribute aus der GENERICATTRIB-Tabelle gelöscht und die CLASS_ID der importierten Cityobjekte in der CITYOBJECT Tabelle auf 10 (= Building) gesetzt (vgl. Abb 4.8).

Abbildung 4.8: Inhalt der BUILDING-Tabelle nach dem Import der RSS-Grundrissdaten.

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

62

4.5.3 RSS_BUILDING_MPATCH Für den Import in die 3D-Geodatenbank wurde das Shapefile der Fa. RSS mit den ca. 67000 Gebäudegrundrissen des Berliner Zentrums mittels ArcScene extrudiert und gespeichert, so dass die Gebäudegeometrien durch 3D-Multipatches repräsentiert werden. Dieses Shapefile besitzt neben dem Shape-Attribut die weiteren Attribute “Id”, “AREA”, “PERIMETER”, “AOBJID”, “OBJART”, “OBJEKTART”, “HM_TRAUF”, “HM_RFIRSTN”, “HM_PLAT-TE”, “HMAX_DACH”, “HMIN_DACH” und “VEG” (siehe Abb. 4.9).

Abbildung 4.9: Shapefile im RSS-Format mit 3D-Gebäudedaten als Multipatches

Das Import-/Exportprogramm speichert die Attribute des Shapefiles entsprechend in der Ta-belle CITYOBJECT_GENERICATTRIB (siehe Abb. 4.10).

Abbildung 4.10: Importierte RSS-Multipatch-Daten in der Tabelle CITYOBJECT_GENERICATTRIB

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

63

Die Prozedur RSS_BUILDING_MPATCH generiert aus den importierten Rohdaten schließ-lich 3D-Gebäude. Dabei werden folgende Attribute des Shapefiles in die Tabellen SURFA-CE_GEOMETRY, BUILDING und EXTERNALREFERENCE übernommen: GEOM (Sha-pe-Attribut des Shapefiles), ID (Name des Gebäudes), OBJEKTART (Funktion des Gebäu-des), HM_RTRAUF (Gebäudehöhe) und AOBJID (ALK-Schlüssel).

Das Attribut “ID“ wird als Name, das Attribut “HM_RTRAUF“ als Höhe und das Attribut “OBJEKTART“ als Funktion des Gebäudes übernommen und in der Tabelle BUILDING ab-gespeichert. Der ALK-Verweis wird dem Attribut AOBJID entnommen und in die Tabelle EXTERNALREFERENCE zusammen mit der INFOSYS Bezeichnung ’urn:ALK’ abgelegt (siehe Abb. 4.11). Die Tabelle BUILDING erhält einen Verweis auf die Tabelle SURFA-CE_GEOMETRY, in der die Geometrie des Gebäudes mit Hilfe der Prozedur GENERA-TE_SOLID abgelegt wird.

Abbildung 4.11: Inhalt der Tabelle EXTERNALREFERENCE nach der Konvertierung der RSS-

Multipatch-Daten

Bei der Konvertierung werden nur solche Tupel in der Tabelle CITYOBJECT berücksichtigt, deren Attribut CLASS_ID = 0 ist. Nach der Konvertierung werden alle importierten Attribute aus der GENERICATTRIB-Tabelle gelöscht und die CLASS_ID der importierten Cityobjekte in der CITYOBJECT-Tabelle auf 10 (= Building) gesetzt (vgl. Abb 4.12).

Abbildung 4.12: Inhalt der Tabelle BUILDING nach der Konvertierung der RSS-Multipatch-Daten

3D-Geodatenbank Berlin 4. Werkzeug für den Datenimport und -export

64

4.5.4 EXTRUDE-Prozedur Die Prozedur EXTRUDE erzeugt für CityObjects mit Grundrissgeometrie (als CITYOB-JECT_GENERICATTRIB) die extrudierten Wand- und Dachflächen und speichert diese als CITYOBJECT_GENERICATTRIB ab. Dabei

• wird die Extrusionshöhe dem CITYOBJECT_GENERICATTRIB entnommen, dessen Name als Parameter “heightAttributeName“ übergeben wird (dieses muss vom Typ REAL sein),

• hat die Grundrissgeometrie als Attribut den Namen, der als Parameter “geometryAttribu-teName“ übergeben wird (Typ GEOMVAL, DATATYPE=6).

• Die Grundrissgeometrie muss ein Polygon ggf. mit Aussparungen (Löchern) sein, d.h. die SDO_GEOMETRY ist eingeschränkt auf SDO_GTYPE = 2003/3003, SDO_ETYPE = 1003/2003 und SDO_INTERPRETATION = 1.

• Die Prozedur geht davon aus, dass es nur ein Attribut dieses Namens gibt.

• Es werden nur CityObjects mit CLASS_ID = 0 berücksichtigt.

• Die erzeugte Boundary-Representation-Geometrie wird als CITYOBJECT_GENERIC-ATTRIB abgespeichert mit dem Namen, der als Parameter “newGeometryAttributeName“ übergeben wird.

• wird jede Fläche als einzelnes Attribut abgespeichert,

• jedes dieser Attribute hat als Wert eine SDO_GEOMETRY (DATATYPE = 6).

• Die Orientierung wird durch den Parameter “changeOrientation“ gesteuert: Falls die Grundrisspolygone richtig orientiert sind (Normale zeigt nach der "Rechte-Hand-Regel" nach unten=Außen), muss “changeOrientation“ FALSE sein, ansonsten TRUE. Dann wird die Orientierung der Grundrissfläche umgedreht.

• Die IDs der CITYOBJECT_GENERICATTRIB für ein CityObject sind nach Aufruf der Prozedur aufsteigend so angeordnet, dass zuerst das Grundrisspolygon, dann die Wandpo-lygone und zuletzt das Dachpolygon kommt.

• In dem Attribut “strval“ eines CITYOBJECT_GENERICATTRIB, das eine extrudierte Fläche repräsentiert, steht als Wert die Art der Fläche: Boden-, Wand- oder Dachfläche

• Jedes CityObject darf nur ein einzelnes Höhenattribut haben. Beispiel für Aufruf: exec extrude('GEOM', 'h', 'NEW_GEOM', false);

Beispiel für Aufruf für die Daten aus der Datei “Grundrisse_Ostkreuz_3D_Polygon.shp“: exec extrude('GEOM', 'HM_RTRAUF', 'NEW_GEOM', false);

3D-Geodatenbank Berlin

65

5 Nutzungsbeispiele 5.1 Direkter Zugriff über SQL Im Folgenden werden zwei Beispiele vorgestellt, über die Orthophotos (Beispiel 1) und Ge-bäude (Beispiel 2) aus der Datenbank selektiert werden können. Insbesondere bei der Extrak-tion von Rasterobjekten sind reinen SQL-Mechanismen oder auch SQL*Plus Grenzen gesetzt. So exportiert Oracle 10g von sich aus keine Bildformate; diese müssen erst mit einer Anwen-dung aus den gelieferten Rohdaten und Metainformationen erzeugt werden.

Beispiel 1 – Abfrage von Orthophotos Eine direkte Abfrage eines Rasterobjekts über eine SQL-Select-Anweisung analog zur Abfra-ge von Vektorgeometrien ist in Oracle 10g nicht vorgesehen. Stattdessen muss durch den Aufruf von Stored-Procedures ein entsprechender Raumausschnitt bei angegebener räumli-cher Auflösung aus einem Georaster ausgeschnitten und in eine Datenstruktur abgelegt wer-den. Über einen zusätzlichen Aufruf werden die Metainformationen zum ausgewählten Geo-raster selektiert. Diese enthalten u.a. Informationen zur verwendeten Farbtabelle und zum Raumbezug. Die von Oracle angebotene Methode zum Export eines Georasters in eine Datei kann an dieser Stellen nicht genutzt werden, da die meisten Nutzer über keinen direkten Zu-gang zum Datenbankrechner verfügen ( mdsys.sdo_geor.exportTo(...) ).

Grundsätzlich stehen zwei Methoden zur Verfügung, über die Ausschnitte aus einem Georas-ter selektiert werden können. Streng genommen handelt es sich dabei um dieselbe Methode, der jedoch unterschiedliche Arten von Parametern übergeben werden.

1. Selektion über Angabe der Pixelkoordinaten: Aus einem Georaster wird ein Teilraster ausgeschnitten/selektiert, wobei der Nutzer die Koordinaten des gewünschten Aus-schnitts in Pixel (minx, miny, maxx, maxy) angibt. declare geor sdo_georaster; lb blob; begin -- // lb must be created outside this method!!! -- // e.g. lb can be loaded from a already existing table -- // SELECT datacol INTO lb from TEMP_TABLE WHERE id = 1 -- // FOR UPDATE; SELECT orthophotoproperty INTO geor from ORTHOPHOTO where id = 1; sdo_geor.getRasterSubset(geor, 0 , sdo_number_array( 100 , 150 , 450

, 1000 ), null, lb ); end

Die Pixelkoordinaten werden der Methode sdo_geor.getRasterSubset(...) in Form eines Arrays übergeben. Ferner muss der Methode als erster Parameter mitge-teilt werden, aus welchem Georaster sie einen Ausschnitt extrahieren soll; zu diesem Zweck muss dieses zunächst über eine Select-Anweisung aus der fraglichen Rasterda-tentabelle bestimmt werden. Die WHERE-Bedingung dieser Selektion muss sicher stellen, dass genau ein Objekt selektiert wird.

Das Ergebnis der Abfrage eines Sub-Rasters wird im Beispiel auf die als letztes über-gebene und als BLOB definierte Variable ‚lb’ gelegt. Diese steht dann zur Verarbei-tung über weitere Stored Procedures bzw. SQL*Plus-Methoden oder bei externem Aufruf z.B. durch ein Java-Programm zur Verfügung. Wichtig ist, dass ‚lb’ zuvor er-zeugt wurde. Dies kann entweder durch das aufrufende Programm oder Selektion ei-nes bereits existierenden BLOBs aus der Datenbank geschehen.

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

66

2. Selektion über Angabe eines georeferenzierten Raumausschnitts (Envelopes): In die-sem Fall gibt der Nutzer anstelle der Pixelkoordinaten ein georeferenziertes Rechteck (mdsys.sdo_geometry) zur Bestimmung des zu selektierenden Raumausschnitts an. declare geor sdo_georaster; lb blob; begin -- // lb must be created outside this method!!! -- // e.g. lb can be loaded from a already existing table -- // SELECT datacol INTO lb from TEMP_TABLE WHERE id = 1 -- // FOR UPDATE; SELECT orthophotoproperty INTO geor from ORTHOPHOTO where id = 1; sdo_geor.getRasterSubset(geor, 0 , mdsys.sdo_geometry (2003, null, null, mdsys.sdo_elem_info_array (1,1003,3), mdsys.sdo_ordinate_array (-109,37,-102,40)), null , lb ); end

Die übrigen Übergabeparameter sind identisch zur Selektion über Pixelkoordinaten.

Beispiel 2 – Abfrage von Gebäuden Die Abfrage von Gebäuden bzw. der zugeordneten Geometrien gestaltet sich auf der einen Seite einfacher als die Abfrage von Georastern, da einfache SQL-Ausdrücke verwendet wer-den können. Auf der anderen Seite ist die Selektion komplizierter, da die benötigten Informa-tionen auf mehrere Tabellen mit einer zum Teil rekursiven Struktur verteilt sind.

Das folgende Statement selektiert alle Gebäude mit ihren Attributen, deren ID in einem defi-nierten Wertebereich (9850 < ID < 9860) liegen: SELECT

a.LOD2_SURFACE_ID, a.NAME, a.FUNCTION, a.YEAR_OF_CONSTRUCTION,

a.ROOF_TYPE, a.MEASURED_HEIGHT, a.NO_OF_STOREYS_ABOVE_GROUND,

a.NO_OF_STOREYS_UNDER_GROUND, a.BUILDING_AGGREGATE_ID,

b.ID, b.CREATIONDATE, b.TERMINATIONDATE, b.LASTMODIFICATIONDATE,

b.UPDATINGPERSON, b.REASONFORUPDATE, b.LINEAGE

FROM building a, cityobject b

WHERE

a.LOD2_SURFACE_ID is not NULL and

a.ID = b.ID and

a.ID > 9850 and

a.ID < 9860

Zu beachten ist, dass das Feld a.LOD2_SURFACE_ID selektiert wird. Dieses enthält eine Referenz auf einen Eintrag in der Tabelle SURFACE_GEOMETRY, über die die Geometrien eines Gebäudes verfügbar sind. Neben LoD2 stehen auch noch Referenzen zu LoD1 und LoD3 zur Verfügung. Da i.d.R. davon zugehen ist, dass ein Gebäude über mehr als eine Ge-ometrie verfügt, ist das referenzierte Element in SURFACE_GEOMETRY mit großer Wahr-scheinlichkeit eine Aggregation von Surfaces (Flächen).

Das bedeutet, der entsprechende Eintrag verfügt selbst über keine Geometrie, statt dessen existieren in der selben Tabelle weitere Einträge die diesen als ,Parent’ führen (vgl. Abschnitt 2.2.3.3). Eine rekursive Anfrage über SURFACE_GEOMETRY sorgt dafür, dass alle ‚Kin-der’, Enkel’ etc. gefunden werden. Die Rekursion bricht dann ab, wenn ein selektierter Ein-trag über eine Geometrie verfügt (GEOMETRY is not NULL).

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

67

Selektion der Eltern-Geometrie: SELECT ID, GEOMETRY FROM SURFACE_GEOMETRY WHERE ID = $LOD2_SURFACE_ID$

($LOD2_SURFACE_ID$ zuvor selektierte ID der mit einem Gebäude verbundenen Geo-metrie für LoD 2)

Folgendes Statement wird in einer Rekursion aufgerufen bis die Bedingung GEOMETRY is not NULL erfüllt ist: SELECT ID, GEOMETRY FROM SURFACE_GEOMETRY WHERE PARENT_ID = $ID$

($ID$ aus der vorherigen Iteration bestimmte SURFACE_GEOMETRY-Schlüssel)

5.2 Java-Schnittstelle Im Folgenden wird eine mögliche Java-Schnittstelle zum Auslesen von Gebäuden aus der Oracle-Datenbank dargestellt. Das in diesem Kapitel vorgestellte Beispielprogramm wird Beispiel 2 aus Kapitel 5.a in ein Java-Programm umsetzen und so den Export von Gebäuden demonstrieren. Zum Ausführen des Beispielprogramms werden die folgenden Java-Libraries benötigt:

• deegree.jar • ojdbc14.jar • sdoapi.jar • sdoutl.jar • jts.jar

Alle Libraries liegen auf der mitgelieferten CD vor.

Das Beispielprogramm nutzt das Open Source Framework deegree, um die aus Oracle ausge-lesenen Objekte in lesbare Geometrien (XML) umzuwandeln (siehe http://www.deegree.org).

Die Methode selectBuildings(...) selektiert alle Gebäude sowie die relational verbunde-nen Cityobjects und Objectclasses deren ID größer der übergebenen Minimum-ID und kleiner der übergeben Maximum-ID sind. Das Ergebnis wird in einem Tabellenobjekt abgelegt und an die aufrufende Methode ( main(...) ) zurückgegeben. Diese ruft als nächstes die Methode selectSurfaceGeometries(...) auf, wobei die zuvor erzeugte Tabelle übergeben wird. Innerhalb von selectSurfaceGeometries(...) wird zunächst eine FeatureCollection erzeugt, in der die Gebäude später als Feature abgelegt werden sollen. Das Schema der Gebäude-Feature wird durch Aufruf der Methode createFeatureType() erzeugt. In der folgenden Schleife über jede Zeile der übergebenen Tabelle werden für jedes Gebäude zunächst alle zugehörigen alphanumerischen Attribute bestimmt und in FeatureProperties abgelegt. Als letztes werden durch den Block: Object id = table.getValueAt( i, 0 ); Table t1 = osa.performTableQuery( "select ID, GEOMETRY, IS_SOLID from " + "SURFACE_GEOMETRY where ID = " + id ); List list = new ArrayList(); if ( t1.getValueAt( 0, 1) == null ) { getChildrenGeometries( t1.getValueAt( 0, 0), list ); } else { list.add( t1.getValueAt( 0, 1) ); }

alle Flächen bestimmt, die mit einem Gebäude verbunden sind und anschließend in das Fea-tureProperty mit dem Namen ‚GEOM’ geschrieben. Aus den FeatureProperties wird ab-schließend ein Feature erzeugt und in der FeatureCollection abgelegt. Nach Beendigung der Schleife, wird die gefüllte FeatureCollection an die aufrufende Methode zurückgegeben und

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

68

dort in eine XML/GML2-Datei exportiert. Die Flächen eines Gebäudes werden dabei als Mul-tiPolygon wiedergegeben. import java.sql.Connection; import java.util.ArrayList; import java.util.List; import org.deegree.model.feature.Feature; import org.deegree.model.feature.FeatureCollection; import org.deegree.model.feature.FeatureProperty; import org.deegree.model.feature.FeatureType; import org.deegree.model.feature.FeatureTypeProperty; import org.deegree.model.geometry.GM_MultiSurface; import org.deegree.model.geometry.GM_Surface; import org.deegree.model.table.Table; import org.deegree_impl.io.DBConnectionPool; import org.deegree_impl.io.OracleSpatialAccess; import org.deegree_impl.io.shpapi.ShapeFile; import org.deegree_impl.model.feature.FeatureFactory; import org.deegree_impl.model.geometry.GeometryFactory; public class Object3DSelecter { private Connection con = null; public Object3DSelecter(Connection con) { this.con = con; } /** * selects all buildings of an objectclass and a given range of * range of ID-values */ public Table selectBuildings(String objectClass, int idMin, int idMax) throws Exception { OracleSpatialAccess osa = new OracleSpatialAccess( con ); Table table = osa.performTableQuery( "select a.LOD2_SURFACE_ID," + "a.NAME, a.FUNCTION, a.YEAR_OF_CONSTRUCTION, a.ROOF_TYPE, " + "a.MEASURED_HEIGHT,a.NO_OF_STOREYS_ABOVE_GROUND, " + "a.NO_OF_STOREYS_UNDER_GROUND, b.ID, b.CREATIONDATE, " + "b.TERMINATIONDATE, b.LASTMODIFICATIONDATE, " + "b.UPDATINGPERSON, b.REASONFORUPDATE, b.LINEAGE, " + "c.CLASSNAME, a.BUILDING_AGGREGATE_ID from " + "building a, cityobject b, OBJECTCLASS c where " + "a.LOD2_SURFACE_ID > -1 and " + "c.CLASSNAME = '" + objectClass +"' and c.ID = " + "b.CLASS_ID and a.ID = b.ID and a.ID > " + idMin + " and a.ID < " + idMax ); return table; } /** * selektiert die Wurzelgeometrie für jedes in der übergebenen Tabelle * enthaltene Gebäude * @param table * @return * @throws Exception */ public FeatureCollection selectSurfaceGeometries(Table table) throws Exception {

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

69

FeatureCollection fc = FeatureFactory.createFeatureCollection("FC",table.getRowCount()); FeatureType ft = createFeatureType(); OracleSpatialAccess osa = new OracleSpatialAccess( con ); for ( int i = 0; i < table.getRowCount(); i++ ) { String parentAttrib[] = null; if ( table.getValueAt(i, 16) != null ) { parentAttrib = getParentAttributes( table.getValueAt(i,16) ); } else { parentAttrib = new String[2]; } FeatureProperty[] fp = new FeatureProperty[18]; fp[0] = FeatureFactory.createFeatureProperty( "NAME", table.getValueAt( i, 1 ) ); fp[1] = FeatureFactory.createFeatureProperty( "FUNCTION", table.getValueAt( i, 2 ) ); fp[2] = FeatureFactory.createFeatureProperty( "YOC", table.getValueAt( i, 3 ) ); fp[3] = FeatureFactory.createFeatureProperty( "ROOFTYPE", table.getValueAt( i, 4 ) ); fp[4] = FeatureFactory.createFeatureProperty( "HEIGHT", table.getValueAt( i, 5 ) ); fp[5] = FeatureFactory.createFeatureProperty( "SAG", table.getValueAt( i, 6 ) ); fp[6] = FeatureFactory.createFeatureProperty( "SUG", table.getValueAt( i, 7 ) ); fp[7] = FeatureFactory.createFeatureProperty( "ID", table.getValueAt( i, 8 ) ); fp[8] = FeatureFactory.createFeatureProperty( "CREATION", table.getValueAt( i, 9 ).toString() ); fp[9] = FeatureFactory.createFeatureProperty( "TERM", table.getValueAt( i, 10 ) ); fp[10] = FeatureFactory.createFeatureProperty( "MOD", table.getValueAt( i, 11 ) ); fp[11] = FeatureFactory.createFeatureProperty( "UPDATEPERS", table.getValueAt( i, 12 ) ); String reason = (String)table.getValueAt( i, 13 ); if ( reason != null ) { int k = reason.length(); if ( k > 255 ) k = 255; reason = reason.substring( 0, k ); } fp[12] = FeatureFactory.createFeatureProperty( "REASON", reason ); fp[13] = FeatureFactory.createFeatureProperty( "LINEAGE", table.getValueAt( i, 14 ) ); fp[14] = FeatureFactory.createFeatureProperty( "CLASSNAME",

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

70

table.getValueAt( i, 15 ) ); fp[15] = FeatureFactory.createFeatureProperty( "P_NAME", parentAttrib[0] ); fp[16] = FeatureFactory.createFeatureProperty( "P_FUNCTION", parentAttrib[1] ); Object id = table.getValueAt( i, 0 ); Table t1 = osa.performTableQuery( "select ID, GEOMETRY, " + IS_SOLID from SURFACE_GEOMETRY where ID = " + id ); List list = new ArrayList(); if ( t1.getValueAt( 0, 1) == null ) { getChildrenGeometries( t1.getValueAt( 0, 0), list ); } else { list.add( t1.getValueAt( 0, 1) ); } GM_Surface[] surfs = (GM_Surface[])list.toArray( new GM_Surface[list.size()] ); GM_MultiSurface msurf = GeometryFactory.createGM_MultiSurface( surfs ); fp[17] = FeatureFactory.createFeatureProperty( "GEOM", msurf ); Feature feat = FeatureFactory.createFeature( "ID"+i, ft, fp ); fc.appendFeature(feat); } return fc; } /** * ermittelt die Attribute der 'Eltern-Gebäudes' falls ein * selektiertes Gebäude Bestandteil einer Aggregation ist * @param parentid * @return * @throws Exception */ private String[] getParentAttributes(Object parentid) throws Exception { OracleSpatialAccess osa = new OracleSpatialAccess( con ); Table table = osa.performTableQuery( "select parentid, name, " + "function from BUILDING where ID = " + parentid ); String[] parentAttrib = null; if ( table.getValueAt( 0, 0 ) != null ) { parentAttrib = getParentAttributes( table.getValueAt( 0, 0 ) ); } else { parentAttrib = new String[2]; parentAttrib[0] = (String)table.getValueAt( 0, 1 ); parentAttrib[1] = (String)table.getValueAt( 0, 2 ); } return parentAttrib; } /** * erzeugt den FeatureType, der das Schema eines Gebäudes beschreibt * @return */ private FeatureType createFeatureType() { FeatureTypeProperty[] ftp = new FeatureTypeProperty[18];

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

71

ftp[0] = FeatureFactory.createFeatureTypeProperty( "NAME", "java.lang.String", true ); ftp[1] = FeatureFactory.createFeatureTypeProperty( "FUNCTION", "java.lang.String", true ); ftp[2] = FeatureFactory.createFeatureTypeProperty( "YOC", "java.lang.Integer", true ); ftp[3] = FeatureFactory.createFeatureTypeProperty( "ROOFTYPE", "java.lang.Integer", true ); ftp[4] = FeatureFactory.createFeatureTypeProperty( "HEIGHT", "java.lang.Double", true ); ftp[5] = FeatureFactory.createFeatureTypeProperty( "SAG", "java.lang.Integer", true ); ftp[6] = FeatureFactory.createFeatureTypeProperty( "SUG", "java.lang.Integer", true ); ftp[7] = FeatureFactory.createFeatureTypeProperty( "ID", "java.lang.Integer", true ); ftp[8] = FeatureFactory.createFeatureTypeProperty( "CREATION", "java.lang.String", true ); ftp[9] = FeatureFactory.createFeatureTypeProperty( "TERM", "java.lang.String", true ); ftp[10] = FeatureFactory.createFeatureTypeProperty( "MOD", "java.lang.String", true ); ftp[11] = FeatureFactory.createFeatureTypeProperty( "UPDATEPERS", "java.lang.Integer", true ); // consider to skip because just 255 are accepted ftp[12] = FeatureFactory.createFeatureTypeProperty( "REASON", "java.lang.String", true ); ftp[13] = FeatureFactory.createFeatureTypeProperty( "LINEAGE", "java.lang.String", true ); ftp[14] = FeatureFactory.createFeatureTypeProperty( "CLASSNAME", "java.lang.String", true ); ftp[15] = FeatureFactory.createFeatureTypeProperty( "P_NAME", "java.lang.String", true ); ftp[16] = FeatureFactory.createFeatureTypeProperty( "P_FUNCTION", "java.lang.String", true ); ftp[17] = FeatureFactory.createFeatureTypeProperty( "GEOM", "org.deegree.model.geometry.GM_Object", true ); return FeatureFactory.createFeatureType(null, null, "Building", ftp); } /** * ermittelt in einer Rekursion alle zu einem Gebäude gehörenden * Flächen * @param id * @param list * @return * @throws Exception */ public List getChildrenGeometries(Object id, List list) throws Exception { OracleSpatialAccess osa = new OracleSpatialAccess( con ); Table table = osa.performTableQuery( "select ID, GEOMETRY from " + SURFACE_GEOMETRY where PARENT_ID = " + id); for ( int i = 0; i < table.getRowCount(); i++ ) { if ( table.getValueAt( i, 1) == null ) { getChildrenGeometries( table.getValueAt( i, 0), list ); } else { list.add( table.getValueAt( i, 1) ); } }

3D-Geodatenbank Berlin 5. Nutzungsbeispiele

72

return list; } public static void main(String[] args) throws Exception { DBConnectionPool pool = DBConnectionPool.getInstance(); Connection con = pool. acuireConnection( "oracle.jdbc.driver.OracleDriver", "jdbc:oracle:thin:@*****:1521:devs", "berlin3d", "****" ); Object3DSelecter bs = new Object3DSelecter( con ); Table table = bs.selectBuildings( "Building", 1, 12 ); FeatureCollection fc = bs.selectSurfaceGeometries(table); FileOutputStream fos = new FileOutputStream("e:/temp/out" ); GMLFeatureAdapter.export( fc, fos ); fos.close(); System.exit(0); } }