3D-Geodatenbank Berlin - Berlin Business Location Center

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
Inhaltsverzeichnis
1
1.1
1.2
Einleitung
Features
System- und Entwurfsentscheidungen
1
1
3
2
2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.1.6
2.2
2.2.1
2.2.2
2.2.3
Datenmodellierung
UML-Diagramm der 3D-Stadtmodellierung
Basisklassen
Geometriemodell und Texturen
Generische Objekte und Prototypen
Gebäudemodell
Digitales Geländemodel
Orthophotos
Relationales Datenbankschema
Abbildungsregeln, Schemakonventionen
Rasterdatenverwaltung mit Oracle 10g Spatial
Datenbankschema
5
5
5
7
9
10
12
14
15
15
17
18
3
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
3.2.9
3.2.10
3.2.11
3.2.12
3.2.13
3.2.14
3.2.15
3.2.16
3.2.17
3.2.18
3.2.19
3.3
3.3.1
3.3.2
3.4
3.5
3.5.1
3.5.2
3.6
Versions- und Historienverwaltung
Konzept der Versionen und CityModelAspects
Umsetzung in Oracle
AddPlanning
UpdatePlanning
DiscardPlanning
AcceptPlanning
AddPlanningAlternative
UpdatePlanningAlternative
DiscardPlanningAlternative
GetDiff
GetAllDiff
GetConflicts
GetAllConflicts
RefreshPlanningAlternative
DeleteAllPlanningAlternatives
DeleteTermPlanningAlternatives
AddCityModelAspect
DeleteCityModelAspect
AddPAtoCMA
RemovePAfromCMA
DeleteAllCityModelAspects
Administrationsprogramm „PlanningManager“
Planungen
Planungsalternativen
Das Menü Extras
Konfliktmanagement
Differenzen
Konflikte
Nutzung in Anwendungsprogrammen
35
35
38
40
41
41
41
42
42
42
43
43
43
44
44
44
44
45
45
45
46
46
46
47
48
50
51
51
51
51
i
3D-Geodatenbank Berlin
Inhaltsverzeichnis
4
4.1
4.2
4.2.1
4.3
4.3.1
4.3.2
4.3.3
4.4
4.4.1
4.4.2
4.5
4.5.1
4.5.2
4.5.3
4.5.4
Werkzeug für den Datenimport und –export
Systemvoraussetzungen
Benutzerschnittstelle
Der Login-Dialog
Import
Konzept zum Importieren von Shapefiles
Durchführung des Shapefile-Imports
Import von Rasterdaten
Export
Export von Shapefiles
Export von Rasterdaten
Erläuterung der Import-Konvertierungsprozeduren
REALIT_MULTIPATCH
RSS_GRUNDRISSE_MPATCH
RSS_BUILDING_MPATCH
EXTRUDE-Prozedur
52
52
52
53
54
54
55
55
57
57
58
58
58
60
62
64
5
5.1
5.2
Nutzungsbeispiele
Direkter Zugriff über SQL
Java-Schnittstelle
65
65
67
ii
3D-Geodatenbank Berlin
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 Modellierung von CityGML, dem Austauschformat für 3D-Stadtmodelle, das von der Special-InterestGroup 3D (SIG 3D) der Initiative Geodateninfrastruktur NRW (GDI NRW) derzeit entwickelt
und standardisiert wird. Von den in CityGML enthaltenen Konzepten wurde die DGM-, Gebäude- und Gruppierungsmodellierung vollständig für die Level-of-Detail-Stufen 1-3 umgesetzt. Für weitere, auch künftig zu ergänzende Objektarten unterstützt die Datenbank die generische 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 thematische Verfeinerung.
Das Versions- und Historienmanagement erfolgt unter Verwendung des Oracle Workspace Managers und ist weitgehend transparent für Anwendungsprogramme, die mit
der Datenbank arbeiten. Zur Administration von Planungsgebieten und den darin enthaltenen 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 Administration 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 Verfügung gestellten Datentypen zurückgegriffen. Damit werden projektbezogene Speziallösungen vermieden. Verschiedene Geoinformations- und Architektursoftwaresysteme erlauben zudem den direkten Zugriff auf in Oracle gespeicherte GeometrieObjekte und können darüber unmittelbar auf die Daten der 3D-Geodatenbank zugreifen.
•
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 beliebigen Zahl von DGM-Komponenten und –Typen zusammensetzt. Dabei ist es ist möglich, 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 Hilfe der Oracle 10g GeoRaster-Funktionalität aus Einzelkacheln zu einem Gesamtraster
zusammengesetzt.
1
3D-Geodatenbank Berlin
1. Einleitung
•
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 gekachelte, homogene Einzelbilder in der Datenbank zu einem Gesamtbild aggregiert werden 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 ausmodellierten Strukturen verwaltet werden. Das zugrunde liegende Datenmodell setzt die CityGML-Modellierung für Gebäude vollständig von Level-of-Detail 1 bis 3 um. Gebäude können durch einfache, monolithische Objekte repräsentiert werden oder sich
aus einer beliebig tiefen Aggregation von Gebäudeteilen zusammensetzen. Gebäudeanbauten wie Balkone und Treppen können genauso wie die einzelnen Flächen thematisch 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. verwendet werden kann.
Gebäude können Adressen zugeordnet werden, die auch in der 3D-Geo-DB gespeichert werden. Zur Modellierung von Gebäudekomplexen können Gebäude zu speziellen 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 proprietären Dateiformat vorliegen. Damit können unmittelbar Dateien aus anderen Softwaresystemen wie Architektur- oder Grafikprogrammen (uninterpretiert) in die Datenbank 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 Erscheinungsform nicht unterscheiden. Beispiele sind Straßenmöbel wie Laternen, Verkehrsschilder oder Bänke, können aber auch Vegetationsobjekte wie Sträucher, bestimmte 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 generischen Objekten als auch Prototypen können entweder als Oracle-Spatial-Objekte
oder in proprietären Dateiformaten gespeichert werden. In letzterem Fall kann für jedes Objekt eine eigene Datei gespeichert werden, wobei der Dateityp (MIME-Typ),
die Koordinatentransformationsmatrix zur Einpassung des Objekts in das Weltkoordinatensystem 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äumliche Eigenschaften hinzuzufügen. In Verbindung mit dem Konzept der generischen
3D-Objekte ergibt sich damit eine sehr flexible Speicherungsmöglichkeit neuer Objektarten, die im Datenmodell nicht explizit ausmodelliert sind. Jedes zusätzliche Attribut besteht aus einem Tripel von Attributname, Datentyp und Wert. Die unterstützten Datentypen sind dabei: String, Ganz- und Fließkommazahlen, Datum und Uhrzeit,
2
3D-Geodatenbank Berlin
1. Einleitung
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-Objekten kann durch die Kombination von Volumenkörpern und Flächen sowie einer beliebigen, 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-Geometrie) können den Geoobjekten durch die Verwendung generischer Attribute hinzugefügt werden.
•
Programm zum Import und Export von Shapefiles und Rasterdaten: Für die 3DGeo-DB wurde ein Werkzeug entwickelt, das den Import und Export von RasterDGMs, Luftbildern und 3D-Shapefiles ermöglicht. Mit Hilfe des Werkzeugs können
beliebige Ausschnitte des in der Datenbank gehaltenen Gesamt-DGMs bzw. Gesamtluftbilds 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 Konvertierungsmechanismus 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 Gelä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 aller 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 vielen 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ötigten Funktionalitäten erst ermöglichen:
3
3D-Geodatenbank Berlin
1. Einleitung
•
Oracle Spatial 10g unterstützt räumliche Datentypen von 2D bis 4D. Die meisten Operationen und Selektionsfilter berücksichtigen bislang zwar nur die ersten beiden Dimensionen der Geometriekoordinaten, allerdings reichen die unterstützten räumlichen
3D-Indizes bereits für die am häufigsten benötigten Selektionskriterien aus. Der Spatial-Datentyp wird zudem auch unmittelbar von kommerziellen GIS, die eine DBAnbindung 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öglich, das gesamte DGM sowie das gesamte Luftbild von Berlin jeweils als ein homogenes Objekt ohne Kachelung in der Datenbank zu speichern.
•
Mit dem Workspace Manager stellt Oracle eine umfassende Komponente zum Versions- 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 implementiert 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 folgenden 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 Einsatz, da diese in der Version 10g nicht in Verbindung mit dem Oracle Workspace Manager 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) anzukoppeln, die alle nur relationale Datenbankstrukturen unterstützen.
•
Gekachelt vorliegende, homogen strukturierte Rasterdaten (Luftbilder, Digitales Geländemodell) werden in der Datenbank zu jeweils einem Rasterdatenobjekt aggregiert.
Konkret bedeutet dies, dass aus allen Luftbild- bzw. DGM-Kacheln ein einziges Rasterobjekt erzeugt wird. Dieses Vorgehen erlaubt die effiziente und blattschnittfreie
Ausgabe beliebiger geographischer Ausschnitte durch eingebaute Funktionen des Oracle 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 objektrelational 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ändemodelle 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 Luftbild oder dem DGM das Anlegen einer Versionskopie des mehrere Gigabytes großen
Objektes zur Folge hätte.
4
3D-Geodatenbank Berlin
2
Datenmodellierung
2.1
UML-Diagramm der 3D-Stadtmodellierung
In diesem Abschnitt wird das 3D-Stadtmodell auf der abstrakten Ebene graphischer UMLKlassendiagramme beschrieben. Diese bilden die Grundlage für die implementierungsabhängige Realisierung des Modells mit relationalen Datenbanksystemen, die im folgenden Abschnitt 2.2 dargelegt wird. UML-Diagramme können aber auch die Basis für andere Implementierungen 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 CityObject, die in diesem Abschnitt beschrieben wird.
Ein CityObject verfügt zunächst über Metadaten in Form einer BoundingBox, die die ungefähre Lage des Objekts durch den umschreibenden dreidimensionalen Quader angibt, wodurch 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 angeben werden (Fremdbezug, ExternalReference). Diese Bezüge können für Datenverknüpfungen, 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 System. 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.
5
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.1: UML-Diagramm der Basisklassen sowie der Prototypen und generischen Objekte
6
3D-Geodatenbank Berlin
2. Datenmodellierung
CityObjects können nach beliebigen, benutzerdefinierten Kriterien zu Gruppen zusammengefasst 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 CityObject 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 Moabit“ 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 Gruppierungen möglich sind. Die Gruppen „Gebäude des Architekten XY“ und „Gebäude des Architekten ABC“ könnten z.B. zu der Gruppe „Architektonisch interessante Gebäude“ zusammengefasst 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örigkeiten 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 Durchdringungsfreiheit 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 festgelegt, können direkt die Klassen GM_CompositeSolid oder GM_CompositeSurface zur Angabe 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 bilden. Im 3D-Stadtmodell wird diese Eigenschaft des Zusammenhangs jedoch nicht notwendigerweise 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 versehen 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.
7
3D-Geodatenbank Berlin
2. Datenmodellierung
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, entnommen. 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 Zusammenfassung dieser Solids muss ein zusammenhängendes Gebilde sein. Diese strikten Eigenschaften 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.
8
3D-Geodatenbank Berlin
2. Datenmodellierung
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 (CityObjectGenericAttribute) 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, erfolgen, 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 Alternativen. 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äutert wurden. Diese Repräsentation kann für die einzelnen Detaillierungsgrade (LoD) unterschiedlich 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 Geometrie 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 entsprechenden 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 Transformationsmatrix (lodXTransformationmatrix, für jeden LoD X) angegeben werden, durch
die die Geometrie aus dem lokalen in das georeferenzierte System des 3D-Stadtmodells transformiert werden kann. Das Koordinatenreferenzsystem, in dem die Koordinaten nach der
Transformation vorliegen, kann für jeden LoD X in dem Attribut lodX_SRS3 abgelegt werden, 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 Ausschmückungen wie Bäume oder Parkbänke, aber auch Gebäude einer gleichförmigen Siedlung. 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 Prototyp 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ächliche 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.
Diese Attribute müssen im UML-Diagramm noch ergänzt werden.
4
Diese Attribute müssen im UML-Diagramm noch ergänzt werden.
3
9
3D-Geodatenbank Berlin
2. Datenmodellierung
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 Prototypen. 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 Systems – 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 Bestandteile wie Dachüberstände durch GM_Surfaces möglich ist.
Als Attribute eines AbstractBuilding sind der Name, die Funktion (z.B. Wohnhaus, Kirche),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 vorgesehen. 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 werden 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. Insbesondere können die BuildingParts wiederum BuildingParts als Bestandteile haben, durch die Vererbung der Aggregationsbeziehung. Somit ergibt sich eine baumartige Hierarchie, an deren
Wurzel ein Building steht, und deren Nichtwurzelknoten BuildingParts sind. Die Attributwerte 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üssen 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.
10
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.3: UML-Diagramm des Gebäudemodells
11
3D-Geodatenbank Berlin
2. Datenmodellierung
Sowohl Gebäudekomplexe als auch Gebäudecharakteristiken sind CityObjects und erben somit alle deren Eigenschaften, einschließlich der Fremddatenbeziehung.
In den LoD 2 und 3 können die Begrenzungsflächen von Gebäuden als eigenständige thematische 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. Volumenberechnungen zu ermöglichen. Alle thematischen Begrenzungsflächen haben eine eigene Geometrie, repräsentiert durch flächenhafte GM_Composites. Geometrisch sind diese Flächen
auch in der Begrenzung der Solids vertreten, die das entsprechende übergeordnete thematische Objekt, i.d.R ein Gebäude, repräsentieren. Diese geometrischen Flächen müssen redundanzfrei 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 Begrenzungsflä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 entsprechenden Adresse verknüpft sein (Relation addressProperty).
Eine Adresse mit den üblichen Attributen (Straßenname, Hausnummer, Postleitzahl, Stadtname) wird durch die Klasse Address repräsentiert und kann einem Gebäude oder einer Tür zugeordnet 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 entsprechende 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 LoD2Stadtmodell 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 Raster (Tiles) abzulegen, dient die Beziehung importetRasterTiles zwischen Raster und RectifiedGridCoverage. Das im zweiten Importschritt erzeugte Gesamtraster wird dann als RectifiedGridCoverage 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 (ex12
3D-Geodatenbank Berlin
2. Datenmodellierung
tent). Dieses legt den Bereich fest, in dem die Komponente gültig ist. Abb. 2.5 zeigt als Beispiel ein Raster mit drei Komponenten: einem groben Raster und zwei darin liegenden hochaufgelösten TINS (TIN 1 und 2). Das Gültigkeitspolygon des Rasters ist blau skizziert, während 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 vorhanden 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
13
3D-Geodatenbank Berlin
2. Datenmodellierung
Raster
TIN 1
TIN 2
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 Orthophoto ist ein CityObject, hat eine LoD-Stufe, ein Befliegungsdatum und einen Namen. Realisiert
wird ein Orthophoto durch die GML-Klasse RectifiedGridCoverage, die auch die Speicherung nicht achsenparalleler Photos ermöglicht. Aus Gründen des Imports ist hier die Speicherung 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
14
3D-Geodatenbank Berlin
2.2
2. Datenmodellierung
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 Klassen werden weggelassen). Die skalaren Attribute der Klassen werden zu Spalten der entsprechenden Tabelle mit identischem Namen. Die Typen der Attribute werden an OracleDatentypen 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 deshalb 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 SURFACE_GEOMETRY abgebildet.
•
Die Klasse CityObjectGenericAttrib wird mit allen Datentypenunterklassen in der Tabelle CITYOBJECT_GENERICATTRIB zusammengefasst.
•
Die Klassen Abstractbuilding, Building und BuildingPart werden auf die Tabelle
BUILDING abgebildet.
•
Die Klassen BoundarySurface und Unterklassen ClosingSurface, FloorSurface, WallSurface 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 benannt:
•
GEN_<SUBOBJECT_ID>_<OBJEKT_ID>_< laufende Nummer >
15
3D-Geodatenbank Berlin
2. Datenmodellierung
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üsselnamen 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 Fremdschlü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ÜSSEL_AGGREGATKLASSE) dient. Die laufende Nummer dient dazu, den Fremdschlüsselnamen 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 definiert, 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 SUPERCLASS_ID in der Unterklasse als Fremdschlüssel auf die ID der Oberklasse repräsentiert.
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 OBJECTCLASS verweist. Dadurch kann bei Betrachten eines Tupels z.B. in CITYOBJECT unmittelbar 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 RASTER_RELIEF nachgesehen werden, ob die ID dort vorhanden ist. Mit der Information über
die Klassenzugehörigkeit in der Tabelle RELIEFCOMPONENT kann gezielt in der „richtigen“ der vier Tabelle gesucht werden.
Die Information über die Klassenzugehörigkeit ist nicht nur in der höchsten Oberklasse CITYOBJECT 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.
16
3D-Geodatenbank Berlin
2. Datenmodellierung
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öglichen 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 aufweisen 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 importiert, 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 Kacheln erstreckt, ist es zunächst nicht möglich, diesen als ein Objekt abzufragen; für jede tangierte Kachel liefert die Oracle-Datenbank ein eigenes Rasterobjekt bzw. Bild zurück! Insbesondere bei der Abfrage größerer Raumausschnitte, bei denen u.U. mehrere hundert oder tausend 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 Identifikation 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 zudem eher selten ändern. Daher wurden neben den Tabellen RASTER_RELIEF und ORTHOPHOTO jeweils eine weitere Tabelle angelegt, in die zunächst alle vorhandenen Kacheln
importiert werden. Updates auf einzelne Kacheln werden ebenfalls auf diese Tabelle(n) ausgeführt. Der verantwortliche Administrator entscheidet, wann er über die mosaic-Funktion
das eigentliche Relief in der Tabelle RASTER_RELIEF bzw. ORTHOPHOTO aktualisiert.
17
3D-Geodatenbank Berlin
2. Datenmodellierung
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 Kacheln 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-mosaicFunktion liegen diese als ein großes Objekt in der Datenbank mit einer homogenen räumlichen Auflösung vor. Dies erschwert den Export der Daten in einer anderen als der Originalauflö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 Instanz von RASTER_RELIEF bzw. ORTHOPHOTO erstellt. Oracle bietet hierzu verschiedene Verfahren der Interpolationen der Rasterzellen an. Die Wahl des anzuwendenden Verfahrens dürfte im wesentlichen von der Performanz und den zu erwartenden Artefakten abhängen. 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 vorgehalten 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 ausfü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.
18
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.7: Tabellen zur Realisierung der Basisklassen
19
3D-Geodatenbank Berlin
2. Datenmodellierung
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 (Envelope) wird durch ein Feld mit Typ SDO_GEOMETRY realisiert, das ein achsenparalleles 2DPolygon (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 Klassenzugehö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 SUPERCLASS_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 EXTERNALREF_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 CITYOBJECT_GENERICATTRIB repräsentiert, wobei die Typen durch die Werte des Attributs DATATYPE 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, dessen Inhalt die in der folgenden Tabelle dargelegte Bedeutung hat:
DATATYPE
1
2
3
4
5
6
7
Attributtyp
STRING
INTEGER
REAL
DATE
BLOB
Oracle-Geometrie (SDO_GEOMETRY)
Geometrie durch Flächen in der Tabelle SURFACE_GEOMETRY
Die Beziehung des generischen Attributs zu seinem CityObject ergibt sich aus dem Fremdschlüssel CITYOBJECT_ID (REL_CITYOBJ_ID_ID_1).
Die nächste freie ID für die Tabelle CITYOBJECT_GENERICATTRIB wird durch die Sequenz CITYOBJECT_GENERICATT_SEQ bereitgestellt.
6
Langfristig sollte hier über die Verwendung dreidimensionaler BoundingVolumes nachgedacht werden.
20
3D-Geodatenbank Berlin
2. Datenmodellierung
IMPORT_PROCEDURES
In der Tabelle IMPORT_PROCEDURES sind die Namen der zum Datenimport bereitgestellten 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 CITYOBJECTGROUP) 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, wurde die Tabelle GROUPTOCITYOBJECT eingeführt, die die IDs beider Tabellen zuordnet.
Abbildung 2.8: Tabellen zur Realisierung von Objektgruppen
21
3D-Geodatenbank Berlin
2. Datenmodellierung
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 Eintrag 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 UMLDiagramm 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. Polygon 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 Geometrie 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. Andernfalls 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 Aggregationen von Flächen, CompositeSurfaces, Solids, CompositeSolids flexibel gebildet werden.
Die nächste freie ID für die Tabelle SURFACE_GEOMETRY wird durch die Sequenz SURFACE_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:
6
5
7
2
4
3
1
Abbildung 2.9: Sieben Surfaces, die ein geschlossenes Volumen bilden.
22
3D-Geodatenbank Berlin
SURFACE_GEOMETRY
ID PARENT_ID GEOMETRY
... ...
...
8 NULL
NULL
1 8
Geometrie der Fläche 1
2 8
Geometrie der Fläche 2
3 8
Geometrie der Fläche 3
4 8
Geometrie der Fläche 4
5 8
Geometrie der Fläche 5
6 8
Geometrie der Fläche 6
7 8
Geometrie der Fläche 7
.... ....
.......
2. Datenmodellierung
IS_SOLID
...
1
0
0
0
0
0
0
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, ergeben sich die folgenden Tupel:
SURFACE_GEOMETRY
ID PARENT_ID GEOMETRY
... ...
...
12 NULL
NULL
6 12
Geometrie der Fläche 6
7 12
Geometrie der Fläche 7
.... ....
.......
IS_SOLID
...
0
0
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. Felder 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 PROTOTYPE_SEQ bereitgestellt.
23
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.10: Tabellen für Prototypen und generische Klassen
24
3D-Geodatenbank Berlin
2. Datenmodellierung
GENERICCITYELEMENT
Generische Objekte sind in der Tabelle GENERICCITYELEMENT repräsentiert. Die Felder
sind größtenteils identisch zu den Attributen der UML-Klasse GenericCityElement. Die Geometrie ergibt sich aus den drei Fremdschlüsseln LOD1_SURFACE_ID,..., LOD3_SURFACE_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 Eintrag 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ächenaggregat – 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 BUILDING_AGGREGATE_ID realisiert (REL_BUILD_AGG_ID_ID), der auf das darüberliegende 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 BUILDING_GROUP_ID in der Tabelle BUILDING (REL_MBUILD_ID_ID). Die Beziehung einer 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 Unterklassenbeziehung der Öffnung zur THEMATIC_SURFACE ergibt sich durch gemeinsame IDs, und
die Relation zur umgebenden Fläche durch den Fremdschlüssel SURROUNDING_SURFACE_ID in der Tabelle BUILDING_OPENING.
25
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.11: Tabellen für das Gebäudemodell
26
3D-Geodatenbank Berlin
2. Datenmodellierung
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 dieses 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:nBeziehung 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 Gebä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
2
3
4
5
6
7
8
9
10
11
....
0
0
0
0
0
0
0
0
0
1
0
......
10
10
10
10
10
10
10
11
11
11
NULL
....
Geometrie der Fläche 1
Geometrie der Fläche 2
Geometrie der Fläche 3
Geometrie der Fläche 4
Geometrie der Fläche 5
Geometrie der Fläche 6
Geometrie der Fläche 7
Geometrie der Fläche 8
Geometrie der Fläche 9
NULL
NULL
.......
.......
.......
.......
.......
.......
.......
.......
.......
.......
.......
27
3D-Geodatenbank Berlin
BUILDING
ID .........
... .........
333 .........
.... .........
2. Datenmodellierung
LOD2_SURFACE_ID
...
11
....
THEMATIC_SURFACE
ID Name
Typ
... .........
...
555 „Dachfläche_links“ „RoofSurface“
556 „Dachfläche_rechts“ „RoofSurface“
.... .........
....
THEMATIC_SURFACE_GEOMETRY
ID SURFACE_ID LOD
... .........
...
123 7
2
124 8
2
125 9
2
126 6
2
.... .........
....
......
.......
.......
.......
BUILDING_ID
.......
333
333
.......
THEMATIC_SURFACE_ID
.......
556
556
555
555
.......
8
6
9
5
7
2
4
3
1
Abbildung 2.12: Sieben Surfaces, die ein geschlossenes Volumen bilden, sowie zwei Flächen (8
und 9, rot hervorgehoben), die einen Dachüberstand repräsentieren.
In dem Beispiel dienen die SURFACE_GEOMETRIE-Tupel mit IDs 6 und 7 zugleich der
Definition der Dachflächen und der Geometrie des Aggregats, das den Volumenkörper des
Gebäudes bildet. Die Flächen 1 – 7 werden zunächst zum Surface-Tupel 10 aggregiert und
durch IS_SOLID=1 als geschlossener Volumenkörper angezeigt, der dann wiederum zusammen mit den Flächen 8 und 9 zum Surface-Tupel 11 aggregiert wird.
BUILDING_CHARACTERISTIC
Die UML-Klasse BuildingCharacteristic wird durch die Tabelle BUILDING_CHARACTERISTIC umgesetzt, mit identischen Attributen bzw. Feldern. Die Beziehung zu dem entsprechenden Gebäude ergibt sich aus dem Fremdschlüssel BUILDING_ID, und die Geometrie in den LoD 2 und 3 durch die Fremdschlüssel LOD2_SURFACE_GEOMETRY und
LOD3_SURFACE_GEOMETRY zur Tabelle SURFACE_GEOMETRY.
28
3D-Geodatenbank Berlin
2. Datenmodellierung
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 UMLModellierung. (vgl. Abschnitt 2.1.5)
RELIEF
Ein Tupel in der Tabelle RELIEF repräsentiert ein komplexes Reliefobjekt, das aus verschiedenen 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 BREAKLINE_RELIEF, MASSPOINT_RELIEF, TIN_RELIEF und RASTER_RELIEF abgelegt. Um
das Datenbankschema flacher und effizienter zu halten wurde auf die Definition einer Oberklassentabelle RELIEFCOMPONENT verzichtet. Jede Reliefkomponente hat ein Attribut
LOD, das die Zugehörigkeit zu einem Detaillierungsgrad (Auflösung, Genauigkeit) beschreibt. 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 Reliefkomponenten eines komplexen Reliefobjekts erfolgt durch Polygone (Attribut EXTENT), die den Gültigkeitsbereich der Reliefkomponente angeben. Jede Reliefkomponente hat ein Attribut NAME, das der Benennung der Komponente dient. Sowohl das Relief wie auch jede Reliefkomponente 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 Verwendung 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: MULTIPOLYGON
Tabelle MASSPOINT_RELIEF – Attribut MASSPOINT_PROPERTY –
SDO_GTYPE: MULTIPOINT
•
•
Die Rasterkomponententabellen BREAKLINE_RELIEF, MASSPOINT_RELIEF,
RASTER_RELIEF, TIN_RELIEF – Attribut EXTENT – 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.
29
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.13: Tabellen zur Realisierung des Digitalen Geländemodells
30
3D-Geodatenbank Berlin
•
2. Datenmodellierung
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 Attribut GEOMETRY. Über das Attribut BREAKLINE_RELIEF_ID wird auf die BREAKLINE_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ändemodell (Relief) zugeordnet. Der dazu gehörende Constraint trägt den Namen AGG_BREAKLINE_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ändemodell (Relief) zugeordnet. Der dazu gehörende Constraint trägt den Namen AGG_RELIEF_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 verwiesen. 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ändemodell zugeordnet. Der dazu gehörende Constraint trägt den Namen AGG_RELIEF_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 mosaicRasterReliefInitial 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 Aktivierung 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 verwendet. 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 geometrische Gültigkeitsbereich oder die Ausdehnung einer Kachel wird in dem Attribut
FOOTPRINT abgespeichert. Die Tabelle ist nicht versioniert.
31
3D-Geodatenbank Berlin
2. Datenmodellierung
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 Objekttabelle 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
BREAKLINE _SEQ
MASSPOINT_SEQ
TRIANGLE _SEQ
RASTER_RELIEF_IMP_SEQ
RASTER_RELIEF_RDT_SEQ
RASTER_RELIEF_RDT_IMP_SEQ
Zugehörige Tabelle
BREAKLINE
MASSPOINT
TRIANGLE
RASTER_RELIEF_IMP
RASTER_RELIEF_RDT
RASTER_RELIEF_IMP_RDT
2.2.3.7 Orthophotos
Die Modellierung des ORTHOPHOTO-Datenbankschemas entspricht weitgehend der UMLModellierung. (vgl. Abschnitt 2.1.6)
ORTHOPHOTO und ORTHOPHOTO_IMP
Die Tabelle ORTHOPHOTO wird wegen der Verbindung zu der Objekttabelle ORTHOPHOTO_RDT nicht versioniert. Das Attribut ORTHOPHOTOPROPERTY ist vom Typ
SDO_GEORASTER. In dem Attribut werden die ORTHOPHOTOS mithilfe der Stored Procedure mosaicOrthophotoInitial aus den einzelnen Orthophotokacheln der Importtabelle ORTHOPHOTO_IMP erzeugt und gespeichert. Ein Orthophoto ist ein Cityobjekt und erhält einen Fremdschlüssel auf dessen ID-Attribut. Die referentielle Integrität muss manuell sichergestellt werden, da die Versionsverwaltung des Oracle Workspace Managers keine Fremdschlüssel von den nicht versionierten auf versionierte Tabellen erlaubt.
Die Tabelle ORTHOPHOTO_IMP wird für den Import der einzelnen Rasterkacheln verwendet. Mit Hilfe der Stored Procedure mosaicRasterReliefInitial wird aus diesen Kacheln ein
einzelnes Raster erzeugt und in der Tabelle ORTHOPHOTO abgelegt. Das Attribut FILENAME 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 abgespeichert.
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.
32
3D-Geodatenbank Berlin
2. Datenmodellierung
Abbildung 2.14: Diagramm für die Tabellen für Orthophotos
33
3D-Geodatenbank Berlin
2. Datenmodellierung
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
ORTHOPHOTO_IMP_SEQ
ORTHOPHOTO_RDT_SEQ
ORTHOPHOTO_IMP_RDT_SEQ
Tabelle
ORTHOPHOTO_IMP
ORTHOPHOTO_RDT
ORTHOPHOTO_IMP_RDT
34
3D-Geodatenbank Berlin
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 aktuellen Datenbestandes und die Verwaltung des zeitlichen Verlaufs dieser Daten (Historie).
Vielmehr kann der Datenbestand dazu genutzt werden, bestimmte Stadtbereiche neu zu planen. 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 Historienverwaltung 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 eingegrenzt. 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 Planungen 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 mittlerweile überschriebenen Stand vom Zeitpunkt t1 zurückzusetzen oder den gesamten Datenbankzustand 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
35
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
Alle im Beispiel beschriebenen Szenarien können mit dem im Folgenden dargestellten Datenbankschema 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 Planungen 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 Planung gewählt werden.
Alle in der Abbildung als Oval dargestellten Objekte (GeneralWorkspace, PlanningAlternative und CityModelAspect) werden als Workspaces des Oracle Workspace Managers realisiert
und zusätzlich mit Metadaten in eigenen Tabellen verwaltet. Die Abhängigkeiten und Zusammenhä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.
36
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
Abbildung 3.2: UML-Diagramm mit Klassen, Attributen und Methoden für parallele Planungen.
37
3D-Geodatenbank Berlin
3.2
3. Versions- und Historienverwaltung
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 Spaltenbezeichnungen 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.
38
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
Da die eigentliche Versionierung und Historienverwaltung vom Oracle Workspace Manager
übernommen wird, dienen die Metadatentabellen und die zugehörigen Prozeduren einer „Versionierung 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 Betrachtungszeitpunkt aus der Vergangenheit gewählt, so kann der zu diesem Zeitpunkt gültige Datenbankbestand 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 nachfolgenden Kapiteln beschrieben. Mit diesen Prozeduren ist es Anwendungsprogrammen möglich, 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. Workspaces
3.2.13
DeleteTermPlanningAlternatives Löschen aller beendeten Planungsalternativen u. 3.2.14
Workspaces
DiscardPlanningAlternative
Beenden einer Planungsalternative
3.2.7
GetAllConflicts
Abfrage der Konflikte aller Planungsalternativen 3.2.11
GetAllDiff
Abfrage der Differenzen aller Planungsalternati- 3.2.9
ven
GetConflicts
Abfrage der Konflikte einer Planungsalternativen
3.2.10
39
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
GetDiff
Abfrage der Differenzen einer Planungsalternativen
3.2.8
RefreshPlanningAlternative
Aktualisieren des Datenbestandes einer Planungsalt.
3.2.12
UpdatePlanningAlternative
Aktualisieren der Metadaten einer Planungsalternative
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. Workspaces
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 Parameter mit NULL anzugeben.
Syntax:
AddPlanning(
title
description
executive
spatialExtent
Parameter:
title
IN
IN
IN
IN
VARCHAR2,
VARCHAR2,
VARCHAR2,
MDSYS.SDO_GEOMETRY);
Kurzbezeichnung der Planung, die in Anwendungsprogrammen (z.B.
PlanningManager) in Menüs angezeigt wird. Diese sollte kurz und eindeutig sein.
description
Beschreibung der Planung (max. 4000 Zeichen)
executive
Verantwortliche Person/Stelle für das Anlegen der Planung
spatialExtent
räumliche Begrenzung des Planungsgebiets
40
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
3.2.2 UpdatePlanning
Die Prozedur ändert die Parameter Titel, Beschreibung, Verantwortliche Stelle und Räumliche Begrenzung einer bestehenden Planung. Alle vorherigen Inhalte werden überschrieben.
Syntax:
UpdatePlanning(
id
title
description
executive
spatialExtent
IN
IN
IN
IN
IN
NUMBER
VARCHAR2,
VARCHAR2,
VARCHAR2,
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 Savepoints 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 Alternativen beendet.
Syntax:
DiscardPlanning(id
Parameter:
id
IN NUMBER);
ID der zu beendenden Planung
3.2.4 AcceptPlanning
Die Prozedur beendet eine Planung. Die ausgewählte Planungsalternative wird in den Elternworkspace 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 werden nicht gelöscht!
Die Prozedur wird nur dann ausgeführt, wenn die Planung noch aktiv ist und kein Terminierungsdatum hat.
Syntax:
AcceptPlanning(
planningId
planningAlternativeId
IN NUMBER,
IN NUMBER);
Parameter:
planningId
ID der zu beendenden Planung
planningAlternativeId
ID der zu übernehmenden Planungsalternative
41
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
3.2.5 AddPlanningAlternative
Die Prozedur legt einen Datensatz in der Tabelle PLANNING_ALTERNATIVE an und erzeugt einen Workspace. Der Workspacename setzt sich aus der Kennung 'PA', der ID der Planung 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 Anwendungsprogrammen (z.B. PlanningManager) in Menüs angezeigt wird. Diese sollte 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
42
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
lediglich ein Savepoint mit dem Namen "terminated" gesetzt. Die Prozedur wird nur ausgefü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 durchgeführten Änderungen am 3D-Stadtmodell. Andererseits gibt er Aufschluss über die Komplexitä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)
43
3D-Geodatenbank Berlin
3.2.11
3. Versions- und Historienverwaltung
GetAllConflicts
Die Prozedur ruft die Prozedur GetConflicts für alle Workspaces auf, die Planungsalternativen zugeordnet sind. Das Ergebnis gibt einen Eindruck der Möglichkeit, die einzelnen Planungen 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 (neuer) 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" gesetzt (ggf. überschrieben), der es ermöglicht, das Datum des letzten Aufrufens der Prozedur
zu speichern.
Syntax:
RefreshPlanningAlternative(id IN NUMBER);
Parameter:
id
3.2.13
ID der Planungsalternative
DeleteAllPlanningAlternatives
Die Prozedur löscht alle in der Tabelle PLANNING_ALTERNATIVE vermerkten Workspaces 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!
44
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
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 entsprechende 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 Planungsalternativen und sind somit temporärer Natur.
Syntax:
AddCityModelAspect(
title
description
generator
planningAlternativeId
Parameter:
title
IN
IN
IN
IN
VARCHAR2,
VARCHAR2,
VARCHAR2,
NUMBER);
Kurzbezeichnung der Ansicht
description
Beschreibung der anzulegenden Ansicht (max. 4000 Zeichen)
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 Metadatentabellen (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(
45
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
cityModelAspectId
planningAlternativeId
Parameter:
cityModelAspectId
planningAlternativeId
3.2.18
IN NUMBER,
IN NUMBER);
ID des CityModelAspect, dem die Planungsalternative
zugeordnet werden soll.
ID der Planungsalternative
RemovePAfromCMA
Die Prozedur entfernt eine Planungsalternative aus einem CityModelAspect.
Syntax:
RemovePAfromCMA(
cityModelAslpectId
planningAlternativeId
Parameter:
cityModelAspectId
planningAlternativeId
3.2.19
IN NUMBER,
IN NUMBER);
ID des CityModelAspect, aus dem die Planungsalternative entfernt werden soll.
ID der zu entfernenden Alternative
DeleteAllCityModelAspects
Die Prozedur löscht alle CityModelAspects. Die Tupel in den entsprechenden Metadatentabellen (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 PlanningManager.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 erfahren 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 Verbindungs46
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
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 ausgelesen und in einer Baumansicht dargestellt. Durch die Auswahl einer Planung oder einer Planungsalternative 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 (Koordinatenliste 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.
47
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
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 angegeben, 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 PLANNING im entsprechenden Feld vom Typ MDSYS.SDO_GEOMETRY gespeichert.
Im Gegensatz zu Oracle Spatial muss bei der Eingabe der Polygonstützpunkte das erste Koordinatenpaar 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 TERMINATION_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, indem die eingegebenen und automatisch erzeugten Metadaten unter einer neuen ID in die Tabelle PLANNING geschrieben werden.
Hinweis: Soll einer neuen Planung keine räumliche Begrenzung zugeordnet werden, so ist „null“ (ohne Anführungszeichen) in das entsprechende 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 geschrieben.
3.3.2 Planungsalternativen
Im PlanningManager können alle nicht beendeten Planungsalternativen verwaltet werden.
Abbildung 3.5 zeigt die Metadatenansicht einer Planungsalternative. Die gezeigten Informationen haben folgende Bedeutung:
•
ID
ID der Planungsalternative (automatisch fortlaufende Nummerierung)
•
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)
48
3D-Geodatenbank Berlin
•
Workspacename
3. Versions- und Historienverwaltung
Name des Workspaces der Planungsalternative. Der Name
wird automatisch generiert und setzt sich aus der Kennung
PA_, der ID der Planung, der diese Planungsalternative zugeordnet ist, und der ID der Planungsalternative zusammen.
(PA_25_21 ist demnach der Workspace, welcher der Planungsalternativen 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
Abbildung 3.5: Anwendungsprogramm PlanningManager: Oberfläche zur Verwaltung von Planungsalternativen
Grau hinterlegte Informationen werden automatisch generiert und können nicht vom Benutzer
bearbeitet werden.
49
3D-Geodatenbank Berlin
3. Versions- und Historienverwaltung
Für die Verwaltung der Metadaten von Planungsalternativen stehen folgende Buttons zur Verfügung, die kontextabhängig aktiviert bzw. deaktiviert sind:
•
Übernehmen Übernehmen der ausgewählten Planungsalternative. Der Inhalt des entsprechenden Workspaces wird in den Workspace LIVE überführt. Der
Datenbestand von LIVE (Grunddatenbestand) wird somit geändert! Weiterhin werden die Planungsalternative, alle konkurrierenden
Planungsalternativen und die Planung selber durch Setzen des Beendigungsdatums beendet. Die entsprechenden Tupel verbleiben in den Tabellen PLANNING und PLANNING_ALTERNATIVE, sie werden jedoch nicht mehr im PlanningManager angezeigt.
•
Löschen
Löschen der ausgewählten Planungsalternative. Eine Planungsalternative wird gelöscht, indem in der Tabelle PLANNING_ALTERNATIVE
das aktuelle Datum in die Spalte TERMINATION_DATE des entsprechenden 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 gelöscht. Die Planungsalternative wird im PlanningManager nicht mehr
angezeigt.
•
Neu
Definieren einer neuen Planungsalternative. Eine neue Planungsalternative kann nur erzeugt werden, wenn eine Planung ausgewählt ist, da eine Alternative genau einer Planung zugewiesen wird. Eine Planungsalternative wird erzeugt, indem die eingegebenen und automatisch Metadaten unter einer neuen ID in die Tabelle PLANNING_ALTERNATIVE geschrieben werden. Es wird ein neuer Workspace in der Datenbank angelegt.
•
Ändern
Geänderte Einträge werden übernommen. Die geänderten Metadaten
werden in die entsprechende Zeile der Tabelle PLANNING_ALTERNATIVE geschrieben.
3.4
Das Menü Extras
Einige Funktionalitäten für Planungsalternativen werden unter dem Menüpunkt Extras angeboten. 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 Planungsalternative (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 Planungsalternative (vgl. 3.2.10 Prozedur GetConflicts). Der
Aufruf der Funktion kann einige Zeit (Minuten) in Anspruch nehmen!
•
Aktualisierungsdatum
Datum der letzten Aktualisierung des Workspaces der gewählten Planungsalternative (vgl. 3.2.12 RefreshPlanningAlternative. Wurde noch keine Aktualisierung durchgeführt, so wird das Datum des Anlegens der Planungsalternative ausgegeben.
50
3D-Geodatenbank Berlin
•
3.5
Aktualisieren
3. Versions- und Historienverwaltung
Aktualisieren des Workspaces der Planungsalternative mit
dem derzeitigen Datenbestand des Workspace LIVE.
Konfliktmanagement
Planungsalternativen sind auf der Datenbankseite als Workspaces des Oracle Workspace Managers 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 Planungsalternativen entsprechen. Auf Ebene der jeweiligen Planungsalternativen wird der Datenbestand 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 Originaldatenbestand, 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 Konflikten nicht möglich. Im PlanningManager können Konflikte über das Menü Extras im Menü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 Planungsalternative 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 Anwendungsprogramm durch eine grafische Darstellung der beiden Objekte geschehen. Der PlanningManager 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 wechseln. 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 Anwendungsprogramm heraus an.
51
3D-Geodatenbank Berlin
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) verarbeitet. 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 Objekt-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üllen der Datenbank mit Rasterdaten erfolgt durch den Import einzelner Rasterdatenkacheln, die
abschließend zu einem großen, homogenen Rasterdatenobjekt (Luftbild bzw. DGM) verschmolzen 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 (Bounding Box) zur Verfügung. Bei der Ausgabe von Gebäuden können darüber hinaus auch Objekt-IDs oder die Zugehörigkeit von Gebäuden zu einer CityObject-Gruppierung als Selektionskriterium verwendet werden.
Für alle Import- und Exportvorgänge kann grundsätzlich der Oracle-Workspace explizit angegeben 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 Rasterdaten (Richtwert: kleiner 50 MB) zu im- bzw. exportieren. Für den Import von großen Bildern, 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>
52
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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 Datenbankparametern. 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).
Abbildung 4.1 Das Import/Export Tool
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.2 Anmeldemaske
53
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
Anschließend stellt die Anwendung eine Verbindung zur Datenbank her. Ist die Verbindung
aufgebaut, werden die Auswahlliste der Import-Konvertierungsprozeduren (mit Titel „Prozedurbeschreibung“ bzw. „Prozedurname“) und die Auswahlbox „CityObjectGroup“ freigeschaltet. 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 Konvertierungsmechanismus realisiert werden, da die konkreten Attribute und Geometrierepräsentation jeweils von
dem Anwendungsprogramm abhängen, das die Shapefiles erzeugt hat. Im Rahmen des initialen Aufbaus des Berliner 3D-Stadtmodells sind bereits drei unterschiedliche Arten von 3DShapefiles zu unterstützen. Beispielsweise sind die Gebäude des Stadtteils Ostkreuz im Shapefile der Fa. RealIT als 3D-Multipatches gespeichert, wobei jeder Datensatz genau ein Gebä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-Grundrisspolygonen 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 kopiert. 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 CITYOBJECT grundsätzlich jene Tupel erkennen, die durch den Importer geladen und noch nicht interpretiert wurden, da reguläre CITYOBJECTS eine CLASS_ID>0 besitzen müssen. Für jedes einzelne Attribut des Datensatzes wird dann ein Tupel in der Tabelle CITYOBJECT_GENERICATTRIB angelegt, wobei je nach Attributdatentyp im Shapefile der entsprechende Datentyp im Tabellenfeld DATATYPE gesetzt wird und der Attributwert in die zugehörige Tabellenspalte STRVAL, INTVAL, REALVAL, DATEVAL oder GEOMVAL geschrieben wird. Jedes Tupel erhält zudem im Attribut ATTRNAME den jeweiligen Spaltennamen 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_GEOMETRY) 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 Tupel 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 Konvertierungsprozedur vorgesehen werden. Diese Prozeduren werden als Stored Procedure (PL/SQLProzedur 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.
54
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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 Daten importieren. Zuvor kann er mittels Eingabe ins Textfeld Workspace den DatenbankWorkspace ä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.
Abbildung 4.3: Maske zur Eingabe der Lineage
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 fehlerhaft 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 Import-/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 Kacheln 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.
55
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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 importieren. Voraussetzung hierfür ist, dass eine sog. Worlddatei (Worldfile) mit Koordinateninformation 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 Einlesevorgang zu starten. Dieser kann bei großen Dateien (500MB) abhängig von der Serverleistung 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. Speicherplatzmangels auftreten, kann die Rasterdatendatei vor dem Import in kleinere Kacheln zerlegt werden (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 aufgefordert, dass zu kachelnde Bild anzugeben. Nach Eingabe des neuen Bildnamen, z.B. „neues_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. Entsprechende Worldfile-Dateien werden automatisch generiert.
4.3.3.1 Mosaikbildung von DGMs
Die Erstellung eines Gesamtrasterobjekts aus einzelnen Rasterkacheln wird vollständig innerhalb des Oracle-DBMS mittels Stored Procedures ausgeführt. Aufgrund der großen Datenmengen, 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-/Exportprogramm gesteuert, sondern muss über die Eingabe des entsprechenden Befehls in einer
SQL-Eingabekonsole erfolgen, wie z.B. dem Oracle beiliegenden SQL*Plus oder der Enterprise 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 Gesamtrasterobjekt 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 Abschnitt 2.2.2 beschrieben.
Die Mosaik-Prozedur generiert über das eigentliche Gesamtraster hinaus ein RasterReliefObjekt, 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 CITYOBJECT-Tupel werden automatisch generiert und nach erfolgreichem Ablauf der Prozedur in
dem Konsolenfenster angezeigt. Sie sollten in einer Datenbank-Dokumentation notiert werden, 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>);
56
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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 Beschreibung 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. ’photogrammetrische 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 Befehle 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 generiert 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 Beschreibung 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 Orthophoto’, ’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 Struktur 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
57
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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 Anmeldung 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 gefragt. 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 Firmen RealIT und RSS in die Berliner 3D-Geodatenbank benötigt werden.
Mit Hilfe des Import-/Exportprogramms werden Shapefiles mit 3D-Multipatch- sowie 3DPolygon-Geometriedaten zunächst uninterpretiert in die 3D-Geo-DB eingelesen. Alle Attribute des Shapefiles werden ihrem Typ entsprechend in der CITYOBJECT_GENERICATTRIB
gespeichert (siehe Abschnitt 4.3.1). Zur Konvertierung der eingelesenen Shapefiles in 3DGebäudeobjekte stehen derzeit die folgenden Prozeduren zur Verfügung: REALIT_MULTIPATCH, RSS_GRUNDRISSE_MPATCH, RSS_BUILDING_MPATCH.
4.5.1 REALIT_MULTIPATCH
Das von der Fa. RealIT gelieferte Shapefile besitzt neben dem Shape-Attribut mit 3DMultipatch-Geometriedaten nur die Attribute “Building_I“, “X_ref“, “Y_ref“ und “Z_ref“
(siehe Abb. 4.4).
58
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
Abbildung 4.4: Shapefile im RealIT-Format
Das Import-/Exportprogramm importiert diese Attribute entsprechend als GEOM, BUILDING_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
59
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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_GENERICATTRIB gelöscht. Die anderen Attribute (X_REF, Y_REF und Z_REF) haben keine Entsprechung im Datenmodell und verbleiben deshalb als generische Attribute in der CITYOBJECT_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 (SolidAggregat) der Name des Gebäudes abgelegt. Dazu wird das Attribut “Building_I“ des Shapefiles 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
60
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
Das Import-/Exportprogramm speichert die Attribute des Shapefiles entsprechend in der CITYOBJECT_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 verwendet. Folgende Attribute des Shapefiles werden dabei in die Tabellen SURFACE_GEOMETRY 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 abgespeichert. 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.
61
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
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_PLATTE”, “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 Tabelle CITYOBJECT_GENERICATTRIB (siehe Abb. 4.10).
Abbildung 4.10: Importierte RSS-Multipatch-Daten in der Tabelle CITYOBJECT_GENERICATTRIB
62
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
Die Prozedur RSS_BUILDING_MPATCH generiert aus den importierten Rohdaten schließlich 3D-Gebäude. Dabei werden folgende Attribute des Shapefiles in die Tabellen SURFACE_GEOMETRY, BUILDING und EXTERNALREFERENCE übernommen: GEOM (Shape-Attribut des Shapefiles), ID (Name des Gebäudes), OBJEKTART (Funktion des Gebäudes), 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 abgespeichert. 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 SURFACE_GEOMETRY, in der die Geometrie des Gebäudes mit Hilfe der Prozedur GENERATE_SOLID abgelegt wird.
Abbildung 4.11: Inhalt der Tabelle EXTERNALREFERENCE nach der Konvertierung der RSSMultipatch-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
63
3D-Geodatenbank Berlin
4. Werkzeug für den Datenimport und -export
4.5.4 EXTRUDE-Prozedur
Die Prozedur EXTRUDE erzeugt für CityObjects mit Grundrissgeometrie (als CITYOBJECT_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 “geometryAttributeName“ ü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_GENERICATTRIB 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 Wandpolygone 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);
64
3D-Geodatenbank Berlin
5
Nutzungsbeispiele
5.1
Direkter Zugriff über SQL
Im Folgenden werden zwei Beispiele vorgestellt, über die Orthophotos (Beispiel 1) und Gebäude (Beispiel 2) aus der Datenbank selektiert werden können. Insbesondere bei der Extraktion 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 Anwendung 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 Abfrage von Vektorgeometrien ist in Oracle 10g nicht vorgesehen. Stattdessen muss durch den
Aufruf von Stored-Procedures ein entsprechender Raumausschnitt bei angegebener räumlicher Auflösung aus einem Georaster ausgeschnitten und in eine Datenstruktur abgelegt werden. Über einen zusätzlichen Aufruf werden die Metainformationen zum ausgewählten Georaster 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 Zugang zum Datenbankrechner verfügen ( mdsys.sdo_geor.exportTo(...) ).
Grundsätzlich stehen zwei Methoden zur Verfügung, über die Ausschnitte aus einem Georaster 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 Ausschnitts 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 mitgeteilt werden, aus welchem Georaster sie einen Ausschnitt extrahieren soll; zu diesem
Zweck muss dieses zunächst über eine Select-Anweisung aus der fraglichen Rasterdatentabelle 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 übergebene und als BLOB definierte Variable ‚lb’ gelegt. Diese steht dann zur Verarbeitung ü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 erzeugt wurde. Dies kann entweder durch das aufrufende Programm oder Selektion eines bereits existierenden BLOBs aus der Datenbank geschehen.
65
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
2. Selektion über Angabe eines georeferenzierten Raumausschnitts (Envelopes): In diesem 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 werden können. Auf der anderen Seite ist die Selektion komplizierter, da die benötigten Informationen 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 definierten 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 Geometrie verfügt, ist das referenzierte Element in SURFACE_GEOMETRY mit großer Wahrscheinlichkeit 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 ‚Kinder’, Enkel’ etc. gefunden werden. Die Rekursion bricht dann ab, wenn ein selektierter Eintrag über eine Geometrie verfügt (GEOMETRY is not NULL).
66
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
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 Geometrie 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 ausgelesenen Objekte in lesbare Geometrien (XML) umzuwandeln (siehe http://www.deegree.org).
Die Methode selectBuildings(...) selektiert alle Gebäude sowie die relational verbundenen 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 FeatureProperty mit dem Namen ‚GEOM’ geschrieben. Aus den FeatureProperties wird abschließ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
67
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
dort in eine XML/GML2-Datei exportiert. Die Flächen eines Gebäudes werden dabei als MultiPolygon wiedergegeben.
import java.sql.Connection;
import java.util.ArrayList;
import java.util.List;
import
import
import
import
import
import
import
import
import
import
import
import
import
org.deegree.model.feature.Feature;
org.deegree.model.feature.FeatureCollection;
org.deegree.model.feature.FeatureProperty;
org.deegree.model.feature.FeatureType;
org.deegree.model.feature.FeatureTypeProperty;
org.deegree.model.geometry.GM_MultiSurface;
org.deegree.model.geometry.GM_Surface;
org.deegree.model.table.Table;
org.deegree_impl.io.DBConnectionPool;
org.deegree_impl.io.OracleSpatialAccess;
org.deegree_impl.io.shpapi.ShapeFile;
org.deegree_impl.model.feature.FeatureFactory;
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 {
68
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
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",
69
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
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];
70
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
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) );
}
}
71
3D-Geodatenbank Berlin
5. Nutzungsbeispiele
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);
}
}
72