Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank

1
Die Oracle-Schnittstelleder Berliner
3D-Geodatenbank

• Claus Nagel, Alexandra Stadler, Gerhard König,
  Thomas H. Kolbe
• Technische Universität Berlin
• Institut für Geodäsie und Geoinformationstechnik
• Fachgebiet Methodik der Geoinformationstechnik

2
Motivation

• Geodaten-Sammelstelle
• Zusammentragen, vergleichen, anpassen, fortführen
  und austauschen
• Daten beliebiger Herkunft
• VoraussetzungGrundlegendes Datenmodell und
  Austauschformatfür 3D-Stadtmodelle
• Einheitliche Strukturierung garantiert
• Verwendung von CityGML

3
Oracle 10g R2

• Systementscheidung
• Unterstützung von räumlichen Datentypen (2D-4D)
• Datenbankverbindung zu kommerziellen GIS
• Methoden zur effizienten Verwaltung von
  Rasterdaten
• Workspace Manager (Versions- und
  Historienmanagement)
• Designentscheidung
• Beschränkung auf Standard Datentypen von Oracle
  Spatial
• Abbildung des objektorientierten Datenmodells auf
  relationales Schema

4
CityGML Überblick

• Technisches
• Modelliert alle wesentlichen Bestandteile einer
  virtuellen Stadtin ihrer Semantik, Geometrie,
  Topologie und Erscheinung
• GML-Anwendungsschema, XML-basiert
• Datenmodell und Austauschformat für virtuelle 3D
  Stadtmodelle
• Geschichtliches
• Entwickelt in der SIG3D NRW unter Federführung
  von
• Prof. Thomas H. Kolbe (IGG TU Berlin)
• Dr. Gerhard Gröger (IGG Uni Bonn)
• Seit August 2008 internationaler Standard des
  Open Geospatial Consortium (OGC)

5
CityGML Auf dem Weg zum OGC-Standard
CityGML 0.3.0OGC Discussion Paper
2006-03-06
CityGML 0.4.0OGC Best Practices Paper
2007-05-30
CityGML 1.0.0 (Proposal)OGC Request for Comments
2008-02-04
2008-02-192008-03-20
ltltltltltltlt Public Comment Phase gtgtgtgtgtgtgt
CityGML 1.0.0OGC Implementation
Specification(after final OGC TC vote)
2008-08-20
? Internationaler Standard
6
CityGML thematische Gliederung in Objektklassen
ltltFeaturegtgt gml_Feature
ExternalReference - informationSystem anyURI
- externalReference ExternalObjectReferenceT
ype
ltltFeaturegtgt _CityObject
ltltFeatureCollectiongtgtCityModel



ltltFeaturegtgt _TransportationObject
ltltFeaturegtgt _AbstractBuilding
ltltFeaturegtgt ReliefFeature
ltltFeaturegtgt _WaterBody
ltltFeaturegtgt _Vegetation
7
CityGML Detailstufen in der Gebäudemodellierung
Gebäudemodell
8
CityGML Kohärenz von Semantik und Geometrie
9
Eine 3D-Geodatenbank für Berlin

• Auftraggeber
• Berliner Senatsverwaltung für Wirtschaft, Arbeit
  und Frauen
• Berlin Partner GmbH
• 1. Projektphase
• Institut für Geodäsie und Geoinformationstechnik
  Uni Bonn
• Datenbank-Prototyp (Oracle 10g R2 Spatial)
• Basierend auf CityGML (Version 0.3.0)
• Gebäude bis LOD3, DGM
• 2. Projektphase
• Institut für Geodäsie und Geoinformationstechnik
  - TU Berlin
• Adaption auf aktuelle Version von CityGML (0.4.0)
• 99 Unterstützung von CityGML
• Gebäude inklusive Innenraummodellierung und
  Adressierung
• Weitere thematische Module Appearance, Gewässer,
  Verkehrsnetz,

10
Funktionsumfang der 3D-Geodatenbank
von CityGML vererbte Eigenschaften
Zusatz
11
Entwicklungsablauf
12
Vereinfachung des Datenmodells von CityGML
13
Vereinfachung des Datenmodells von CityGML

• CityGML umfangreiches Datenmodell mit
  Erweiterungsmechanismen
• Thematisches Modell deckt breites Spektrum an
  Anwendungsfeldern ab
• Komplexe Relationen innerhalb einzelner
  thematischer Module
• Vergleichbare Hierarchien auf Seite der Geometrie
• Analyse bisheriger Berlin DB ergab Weniger
  komplexes Schema ist ausreichend!
• ? Anpassung der CityGML-Möglichkeiten and die
  Projektbedürfnisse
• Vereinfachtes Datenmodell
• Optimaler Workflow
• Effiziente Prozessierung
• Abstimmung mit Projektpartner 3DGeo

14
Auflistung durchgeführter Vereinfachungen

• Multiplizitäten von Attributen 0.. ? 0..1
• Kardinalitäten von Relationen nm ? 1n oder
  n1(und damit auch ihre Typen) Aggregation ?
  Komposition
• Rekursionen parent-id und root-id
• Datentypanpassung codetype, color vector ?
  String gml-Geometrie ? SDO_GEOMETRY
• Projektspezifische Klassen und Orthophotos,
  Adressrepräsentation, Klassenattribute
  Metadaten

15
Vereinfachte Abbildung der GML-Geometrieklassen

• CityGML GML3-Anwendungsschema? unterstützt
  eine Teilmenge der in GML3 spezifizierten
  Geometrieklassen (ebene Geometrien)

16
Attribute der Klasse _BRepGeometry

• isSolid 1 Geometrie ist geschlossen ? bildet
  einen Solid 0 Geometrie ist nicht geschlossen
  ? bildet eine Surface
• isComposite 1 Geometrie ist zusammenhängend ?
  bildet einen Composite 0 beliebige
  Geometrieanordnung ? bildet einen Multi
• isTriangulated 1 Geometrie ist trianguliert ?
  bildet eine TriangulatedSurface 0
  Geometrie ist nicht trianguliert ? keine
  TriangulatedSurface

Effizinte XLink-Behandlung erfordert zusätzlich
isXLink isXLink kennzeichnet aufeinander
verweisende Geometrien beim Export entfällt
Prüfung auf mehrfach vorkommende Geometrien ?
Performancesteigerung! isReverse Geometrie in
DB immer im korrekten Drehsinn gespeichert ?
direkte Verarbeitung sichergestellt für Export
von XLinks wird der Drehsinn aus dem Originalfile
benötigt isReverse kennzeichnet den Drehsinn
einer Geometrie im Originalfile
17
Ableitung des relationalen Datenbankschemas
CityGML
Xsd Schema ltxscomplexTypename"CityModelType"gt
ltxscomplexContentgt ltxsextension
...
UML Schema
OracleDatenbank
Vereinfachung des komplexen Datenmodells von
CityGML
Schema-verein-fachung
a
Datenbank-Erzeugung
vereinfachtesUML Schema
AbbildungKlassen ?Tabellen
SQL DDLBefehle (JDeveloper)
RelationalesDatenbankschema
b
Ableitung des relationalen Datenbankschemas
18
Abbildung von Vererbungshierarchien

• Ansätze zur Abbildung von Vererbungshierarchien

19
Wie kommt Geometrie in die Datenbank?
ltbldglod1Solidgt ltgmlSolidgt ltgmlexteriorgt
ltgmlCompositeSurface gmlid"lod1Surface"gt
ltgmlsurfaceMembergt ltgmlPolygon
gmlid"Left1"gt ltgmlexteriorgt
ltgmlLinearRing gmlid"LeftRing1"gt
ltgmlposList srsDimension"3"gt 0.0 0.0 0.0 10.0
0.0 0.0 10.0 0.0 4.0 0.0 0.0 4.0 0.0 0.0
0.0 lt/gmlposListgt
lt/gmlLinearRinggt lt/gmlexteriorgt
lt/gmlPolygongt lt/gmlsurfaceMembergt ...
ltgmlsurfaceMembergt ltgmlPolygon
gmlid"Roof1"gt ltgmlexteriorgt
ltgmlLinearRing gmlid"RoofRing1"gt
ltgmlposList srsDimension"3"gt 0.0 0.0 4.0 10.0
0.0 4.0 10.0 5.0 4.0 0.0 5.0 4.0 0.0 0.0
4.0 lt/gmlposListgt
lt/gmlLinearRinggt lt/gmlexteriorgt
lt/gmlPolygongt lt/gmlsurfaceMembergt
lt/gmlCompositeSurfacegt lt/gmlexteriorgt
lt/gmlSolidgt lt/bldglod1Solidgt
Datenbank ?
SURFACE_GEOMETRY SURFACE_GEOMETRY SURFACE_GEOMETRY SURFACE_GEOMETRY SURFACE_GEOMETRY SURFACE_GEOMETRY SURFACE_GEOMETRY
ID GMLID PARENT_ID ROOT_ID IS_SOLID IS_COMPOSITE GEOMETRY
1 UUID_xyz 1 1 0
2 lod1Surface 1 1 0 1
3 Left1 2 1 0 0 LoD1 surface 3
4 Front1 2 1 0 0 LoD1 surface 4
5 Right1 2 1 0 0 LoD1 surface 5
6 Back1 2 1 0 0 LoD1 surface 6
7 Roof1 2 1 0 0 LoD1 surface 7

• LOD1 building

20
Wie werden Texturen zugeordnet?
ltappappearanceMembergt ltappAppearancegt
ltappthemegtSummerlt/appthemegt
ltappsurfaceDataMembergt ltappParameterizedTextu
re gmlid"roofTexture"gt ltappimageURIgtroof.pn
glt/appimageURIgt ltappwrapModegtwraplt/appwrapM
odegt ltapptarget uri"Roof1"gt
ltappTexCoordListgt ltapptextureCoordinates
ring"RoofRing1"gt 0.0 0.0 1.0 0.0 1.0 1.0
0.0 1.0 0.0 0.0 lt/apptextureCoordinatesgt
lt/appTexCoordListgt lt/apptargetgt
lt/appParameterizedTexturegt lt/appsurfaceDataMem
bergt lt/appAppearancegt lt/appappearanceMember
gt
TEXTUREPARAM TEXTUREPARAM TEXTUREPARAM TEXTUREPARAM TEXTUREPARAM
SURFACE_GEOMETRY_ID IS_TEXTURE_PARAMETRIZATION WORLD_TO_TEXTURE TEXTURE_COORDINATES SURFACE_DATA_ID
7 1 - 0.0 0.0 1.0 0.0 1.0 1.0 0.0 1.0 0.0 0.0 x

21
(No Transcript)
22
(No Transcript)
23
Entwicklung eines Import/Exporttools
Entwicklung eines Import/Exporttools für
CityGML-Instanzdokumente
CityGML
c
Xsd Schema ltxscomplexTypename"CityModelType"gt
ltxscomplexContentgt ltxsextension
...
JavaBindung (JAXB)
Schema-basierte Klassen public class
CityModel
SQLAbfragen (Imp/ExportTool)
UML Schema
Daten-import
Daten-export
OracleDatenbank
24
Entwicklung eines Import/Exporttools Überblick
citygml4j
XSD Schema ltxscomplexTypename"CityModelType"gt
ltxscomplexContentgt lt/xscomplexTypegt
25
Herausforderungen der CityGML/GML Verarbeitung

• Unterstützung von Instanzdokumenten beliebiger
  Dateigröße
• GML bietet ein mächtiges, komplexes Datenmodell
• XML ist geschwätzig
• Dateigröße von Instanzdokumenten wächst
  schnell(1 Mio. LOD1 Gebäude benötigen ca. 7GB
  Speicherplatz)
• Effiziente und performante Verarbeitung
• beliebige Verschachtelungstiefe von CityGML/GML
  Objekten führt zu komplexen XML-Datenstrukturen ?
  effiziente Verarbeitung?
• Nebenläufige Prozesse zur Erhöhung der
  Performance ? Entkopplung?
• XLink-Verweise
• CityGML/GML Property-Elemente können per XLink
  auf entfernte Objekte verweisen
• Vorwärts- und Rückwärtsverweise innerhalb einer
  Datei möglich
• Korrekte Abbildung in Datenbank erfordert
  Auflösung von XLinks

26
Unterstützung beliebig großer CityGML-Dateien

• Umsetzung eines zweistufigen Verfahrens
• Partielles Einlesen von XML-Dokumenten
• Datenstrombasiertes, ereignisorientiertes
  XML-Parsen
• Simple API for XML (SAX)
• Sequentielles Einlesen von XML-Elementen in den
  Hauptspeicher? keine Beschränkung der absoluten
  Dateigröße
• Problem SAX-Ereignisse zustandslos ? Kontext
  geht verloren,Rekonstruktion komplexer
  Datenstrukturen aufwendig
• Aufspaltung der CityGML Datei in kleinere Stücke
  (XML-Chunks)
• Sinnvolle Teilung bspw. anhand von CityObject
  Instanzen ltcityObjectMembergt CityObject Instanz
  lt/cityObjectMembergt
• Zwischenspeicherung der zugehörigen
  SAX-Ereignisse
• Hauptspeicherverbrauch bestimmt sich nach der
  Größe der XML-Chunks, nicht mehr nach der
  Dateigröße

27
Unterstützung beliebig großer CityGML-Dateien

• Umsetzung eines zweistufigen Verfahrens
• Bindung der XML-Chunks an Java-Klassen
• Objektorientierte Sicht auf XML-Daten
• Java Architecture for XML Binding (JAXB)
• Generierung einer Java-Klassenhierarchie aus
  einer XML-Schemainstanz
• Abbildung komplexer XML-Datenstrukturen auf
  Java-Objektbaum (Unmarshalling) und umgekehrt
  (Marshalling) ? Effiziente Verarbeitung
• Problem Überführung des gesamten
  Instanzdokuments in eine in-memory Repräsentation
  ? Hauptspeicherbedarf bestimmt sich nach
  Dateigröße
• Schrittweise Bindung der einzelnen XML-Chunks
• XML-Chunks werden unabhängig voneinander in
  Objektbäume übersetzt
• Hauptspeicherverbrauch bestimmt sich nach der
  Größe der Teilbäume
• Freigabe von Hauptspeicher nach Verarbeitung
  eines XML-Chunks

28
Performante Datenverarbeitung

• Verarbeitung eines Instanzdokuments durch
  (quasi-)parallele, interagierende Prozesse
  (Threads)
• Nebenläufige Verarbeitung durch Entkoppelung
  anhand der einzelnen CityObject Instanzen
  (XML-Chunks)
• Parallelisierung abhängig von Anzahl an
  Prozessoren/Prozessorkernen
• Kontextwechsel? überhöhte Lebenszyklus- und
  Ressourcenverwaltung? Thrashing durch Mangel an
  Arbeitsspeicher
• Wiederverwendung von Threads durch Verwaltung in
  Thread-Pools
• Kombination von Thread-Pools zu komplexen
  Prozessketten

29
Auflösung von XLink-Verweisen

• Nebenläufige, partielle Verarbeitung von CityGML
  Dateien
• Verarbeitung beliebig großer Instanzdokumente
• Performante Verarbeitung durch (quasi-)parallele
  Prozesse
• Problem Auflösung von XLink-Verweisen auf
  entfernte CityObject Instanzen wird komplexer
• Rückwärtsverweise
• ? CityObject bereits verarbeitet SQL-Abfrage in
  Datenbank?
• CityObject wird parallel verarbeitet
  Interprozess-Kommunikation?
• Vorwärtsverweise
• CityObject wird parallel verarbeitet
  Interprozess-Kommunikation?
• CityObject noch nicht verarbeitet ?
• Einstufige Strategie erfordert Repräsentation des
  kompletten Instanzdokuments im Hauptspeicher
• Implementierung einer zweistufigen Strategie

30
XLink-Verweise Zweistufige Strategie

• Erste Stufe
• Speicherung von CityObject Instanzen in Datenbank
  ohne Berücksichtigung ihrer XLink-Verweise
• Zwischenspeicherung der XLink-Verweise in
  temporären Tabellen
• Quelle Tabellenname Primärschlüssel
• Ziel GML-ID des referenzierten Elements
• Eventuell Zusatzinformationen
• Effiziente Datenstruktur zur Abbildung GML-ID ?
  Tabellenname Primärschlüssel (im Hauptspeicher
  Überlaufspeicher in Datenbank)
• Zweite Stufe Post-Processing
• Abfrage der temporären XLink-Tabellen
• Auflösung des XLink-Ziels über Datenstruktur im
  Hauptspeicher
• Entsprechende Prozessierung des XLinks

31
Datenimport Schritt 1
32
Datenimport Schritt 2
33
Datenimport Schritt 3
_________
mit separaterXLink Speicherung(temporär)
34
Datenexport Schritt 1
35
Datenexport Schritt 2
36
Performance-Messung
Import
Export
Dataset File size Time Features / second No. of workers Geometry / Appearance / XLinks Time Features / second No. of workers
1.1 mio LOD1 buildings 7,5 GB 115h 228 4 11511040 /0 / 0 38min 455 10
1.1 mio LOD1 buildings 7,5 GB 225h 121 1 11511040 /0 / 0 157h 150 1
10.927 LOD2 buildings?fully textured 163 MB57 MB 25 min 7 4 434714 /43348 /391006 4.3min 42 4
? w/o textures 163 MB 6.5 min 28 4 434714 /0 / 391006 2min 91 4

• Database server 2 x Intel Xeon Dual Core_at_3GHz,
  6GB RAM, SCSI Raid 5 Disk Array, Windows Server
  2003 SP2, 100MBit LAN
• Client running the import/export tool Intel
  Core2 CPU 6600_at_2.4GHz, 2GB RAM, WindowsXP SP2,
  100MBit LAN

37
Charakteristika des Import/Exporttools

• Volle Unterstützung von CityGML 1.0.0, 0.4.0,
  0.3.1, 0.3.0
• Unterstützung beliebig großer CityGML-Dateien
  (gt4GB)
• Nebenläufigkeit der Datenverarbeitung durch
  Multithreading
• Hohe Performance auch auf Standard-Systemen
• 7GB Datei (gt1mio LOD1-Gebäude) ? Import 75min,
  Export 38min
• Unterstützung von XLinks
• Benutzerdefinierter Import und Export durch
  Filteroptionen
• GML ID, GML Name
• Blockweiser Import/Export zur Datenkachelung
  (mittels Bounding Boxes)
• Auswahl von Objektklassen

38
Charakteristika des Import/Exporttools

• Zwei Schnittstellen
• Graphische Benutzerschnittstelle (GUI) zur
  Benutzung durch Endanwender
• Kommandozeilen-Schnittstelle (CLI) zur einfachen
  Einbettung der Import/Export-Funktionalität in
  Drittanwendungen
• Basiert auf Open Source Bibliothek citygml4j des
  IGG
• CityGML Programmbibliothek für Java
• Ermöglicht das einfache Lesen, Verarbeitung und
  Schreiben von CityGML Instanzdokumenten

39
Geplante Erweiterungen

• Matchingfunktionalität
• Erkennung korrespondierender Objekte
• Verlinkung und Austausch von Informationen
• Entfernen redundanter Informationen
• Weiterführende Nutzung als Backend für Web
  Services
• Web Feature Services (WFS) können existierende
  Import- und Exportfunktionalität nutzen
• Alternative zur graphischen Benutzeroberfläche
• Erweiterung der Exportfunktionalität um
  standardisierte Formate
• KML etc.
• Performanceoptimierung
• Optimale Verteilung auf physischen Platten

40
Verfügbarkeit

• Open Source Veröffentlichungen des IGG, TU Berlin
• 3D Geodatenbank
• Import/Exporttool
• citygml4j
• Verfügbar sind
• SQL-Skripte, Quellcode, ausführbare Binärdateien,
  Programmbibliotheken, Dokumentation, Tutorials,
  etc.
• Lizenz GNU Lesser Public General License v3
  (LGPL)
• Link http//www.igg.tu-berlin.de/1746/

Heute!!
41
Referenzen

• 3D city database (2007), www.3dcitydb.org
  letzter Zugriff 2008-06-20.
• Döllner J, Kolbe TH, Liecke F, Sgouros T,
  Teichmann K (2006) The Virtual 3D City Model of
  Berlin - Managing, Integrating, and Communicating
  Complex Urban Information, In Proceedings of the
  25th Urban Data Management Symposium UDMS,
  Aalborg 2006.
• Emgård L, Zlatanova S (2007) Implementation
  alternatives for an integrated 3D Information
  Model, In Advances in 3D Geoinformation Systems,
  Springer-Verlag, pp. 313-330.
• GNU Lesser General Public License,
  http//www.gnu.org/copyleft/lgpl.html letzter
  Zugriff 2008-06-20.
• Gröger G, Kolbe TH, Czerwinski A (2007),
  Candidate OpenGIS Implementation Specification
  (City Geography Markup Language), Version 0.4.0,
  OGC Doc. No. 07-062, Open Geospatial Consortium
  2007.
• Snowflake Software, GO Loader product page
  (2008), http//www.snowflake software.co.uk/produc
  ts/goloader/index.htm letzter Zugriff
  2008-06-20.

42
Fragen ?
Claus NagelAlexandra Stadler Gerhard
König Thomas H. Kolbe nagelstadlerkoenigko
lbe _at_ igg.tu-berlin.de Technische Universität
BerlinInstitut für Geodäsie und
GeoinformationstechnikFachgebiet Methodik der
Geoinformationstechnik Straße des 17. Juni 135,
10623 Berlin