Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank

Institut für Geodäsie und Geoinformationstechnik
Die Oracle-Schnittstelle
der 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
25. November 2008
Motivation
Institut für Geodäsie und Geoinformationstechnik
Geodaten-Sammelstelle
 Zusammentragen, vergleichen, anpassen, fortführen und
austauschen
 Daten beliebiger Herkunft
Voraussetzung:
Grundlegendes Datenmodell und Austauschformat
für 3D-Stadtmodelle
 Einheitliche Strukturierung garantiert
 Verwendung von CityGML
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Oracle 10g R2
Institut für Geodäsie und Geoinformationstechnik
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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
24. Juli 2008
CityGML: Überblick
Institut für Geodäsie und Geoinformationstechnik
Technisches
 Modelliert alle wesentlichen Bestandteile einer virtuellen Stadt
in 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)
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
CityGML: Auf dem Weg zum OGC-Standard
Institut für Geodäsie und Geoinformationstechnik
2006-03-06
2007-05-30
2008-02-04
2008-02-19
2008-03-20
CityGML 0.3.0
OGC Discussion Paper
CityGML 0.4.0
OGC Best Practices Paper
CityGML 1.0.0 (Proposal)
OGC Request for Comments
<<<<<<< Public Comment Phase >>>>>>>
CityGML 1.0.0
2008-08-20
OGC Implementation Specification
(after final OGC TC vote)
 Internationaler Standard
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
24. Juli 2008
CityGML: thematische Gliederung in Objektklassen
Institut für Geodäsie und Geoinformationstechnik
<<Feature>>
gml::_Feature
<<Feature>>
<<FeatureCollection>>
CityModel
ExternalReference
*
_CityObject
*
- informationSystem: anyURI
- externalReference:
ExternalObjectReferenceType
<<Feature>>
<<Feature>>
<<Feature>>
<<Feature>>
<<Feature>>
_Abstract
Building
_Transportation
Object
ReliefFeature
_WaterBody
_Vegetation
…
<<Geometry>>
LOD 0-4 GeometryProperty
gml::_Geometry
LOD 0-4 GeometryProperty
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
CityGML: Detailstufen in der Gebäudemodellierung
Institut für Geodäsie und Geoinformationstechnik
Gebäudemodell
ab LOD1
ab LOD2
ab LOD3
ab LOD4
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
CityGML: Kohärenz von Semantik und Geometrie
Institut für Geodäsie und Geoinformationstechnik
Semantik
Geometry
basierend
auf ISO 19107
Building
Composite
Solid
BuildingPart
...
Geometrie
Semantics
basierend
auf ISO 19109
BuildingPart
Roof
Surf.
Roof
Surf.
Wall
Surf.
Wall
Surf.
Door
Win
dow
Building
Installation
Solid
...
...
Solid
Poly
gon
Poly
gon
...
Composite
Surface
Poly
gon
Poly
gon
Poly
gon
Composite
Surface
...
...
‹#›
8
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Eine 3D-Geodatenbank für Berlin
Institut für Geodäsie und Geoinformationstechnik
 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, …
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Funktionsumfang der 3D-Geodatenbank
Institut für Geodäsie und Geoinformationstechnik
von CityGML vererbte Eigenschaften
Generische
(prototypische)
3D-Objekte
Gebäude inkl.
Innenraummodellierung
(LOD 4)
umfassende
thematische
Modellierung
Digitale
Geländemodelle
(DGM)
Verwaltung von
DGMs und Luftbildern
(WebServices)
Referenzierung
von externen
Datenquellen
Versionsmanagement
Oberflächendaten
Import und
Export von
CityGML-Files
2. Projektphase
Gebäude bis
LOD 3
(rekursive)
Gruppierung
von Objekten
1. Projektphase
Flexible
3D-Geometrien
Zusatz
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Entwicklungsablauf
Institut für Geodäsie und Geoinformationstechnik
Entwicklung eines Import/Exporttools
für CityGML-Instanzdokumente
CityGML
Xsd Schema
<xs:complexType
name="CityModelType">
<xs:complexContent>
<xs:extension
...
Java
Bindung
(JAXB)
Schema-basierte
Klassen
SQL
Abfragen
public class CityModel {
…}
(Imp/Export
Tool)
UML Schema
Vereinfachung
des komplexen
Datenmodells
von CityGML
Datenexport
Datenimport
Oracle
Datenbank
Schemavereinfachung
a
vereinfachtes
UML Schema
c
DatenbankErzeugung
Abbildung
Klassen 
Tabellen
Relationales
Datenbankschema
SQL DDL
Befehle
(JDeveloper)
b
Ableitung des relationalen Datenbankschemas
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Vereinfachung des Datenmodells von CityGML
Institut für Geodäsie und Geoinformationstechnik
Entwicklung eines Import/Exporttools
für CityGML-Instanzdokumente
CityGML
Xsd Schema
<xs:complexType
name="CityModelType">
<xs:complexContent>
<xs:extension
...
Java
Bindung
(JAXB)
Schema-basierte
Klassen
SQL
Abfragen
public class CityModel {
…}
(Imp/Export
Tool)
UML Schema
Vereinfachung
des komplexen
Datenmodells
von CityGML
Datenexport
Datenimport
Oracle
Datenbank
Schemavereinfachung
a
vereinfachtes
UML Schema
c
DatenbankErzeugung
Abbildung
Klassen 
Tabellen
Relationales
Datenbankschema
SQL DDL
Befehle
(JDeveloper)
b
Ableitung des relationalen Datenbankschemas
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Vereinfachung des Datenmodells von CityGML
Institut für Geodäsie und Geoinformationstechnik
 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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Auflistung durchgeführter Vereinfachungen
Institut für Geodäsie und Geoinformationstechnik
 Multiplizitäten von Attributen
0..*  0..1
 Kardinalitäten von Relationen
(und damit auch ihre Typen)
n:m  1:n oder n:1
 Rekursionen
parent-id und root-id
 Datentypanpassung
codetype, color vector  String
Aggregation  Komposition
gml-Geometrie  SDO_GEOMETRY
 Projektspezifische Klassen und
Klassenattribute
Orthophotos, Adressrepräsentation,
Metadaten
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Vereinfachte Abbildung der GML-Geometrieklassen
Institut für Geodäsie und Geoinformationstechnik
 CityGML = GML3-Anwendungsschema
 unterstützt eine Teilmenge der in GML3 spezifizierten Geometrieklassen
(ebene Geometrien)
bRepMember
1..*
<<Geometry>>
_BRepGeometry
+isSolid : boolean [1]
+isComposite : boolean [1]
+isTriangulated : boolean [1]
0..1
<<Geometry>>
BRepAggregate
<<Geometry>>
Polygon
+geometry : Polygon [1]
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Attribute der Klasse _BRepGeometry
Institut für Geodäsie und Geoinformationstechnik
+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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Ableitung des relationalen Datenbankschemas
Institut für Geodäsie und Geoinformationstechnik
Entwicklung eines Import/Exporttools
für CityGML-Instanzdokumente
CityGML
Xsd Schema
<xs:complexType
name="CityModelType">
<xs:complexContent>
<xs:extension
...
Java
Bindung
(JAXB)
Schema-basierte
Klassen
SQL
Abfragen
public class CityModel {
…}
(Imp/Export
Tool)
UML Schema
Vereinfachung
des komplexen
Datenmodells
von CityGML
Datenexport
Datenimport
Oracle
Datenbank
Schemavereinfachung
a
vereinfachtes
UML Schema
c
DatenbankErzeugung
Abbildung
Klassen 
Tabellen
Relationales
Datenbankschema
SQL DDL
Befehle
(JDeveloper)
b
Ableitung des relationalen Datenbankschemas
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Abbildung von Vererbungshierarchien
Institut für Geodäsie und Geoinformationstechnik
bRepMember
1..*
<<Geometry>>
_BRepGeometry
+isSolid : boolean [1]
+isComposite : boolean [1]
+isTriangulated : boolean [1]
0..1
<<Geometry>>
BRepAggregate
<<Geometry>>
Polygon
+geometry : Polygon [1]
BRepGeometry
ID: NUMBER <<PK>>
IS_SOLID : BOOLEAN
IS_COMPOSITE : BOOLEAN
IS_TRIANGULATED : BOOLEAN
BRepAggregate
ID: NUMBER <<PK>><<FK>>
BRepAggregate
ID: NUMBER <<PK>>
IS_SOLID : BOOLEAN
IS_COMPOSITE : BOOLEAN
IS_TRIANGULATED : BOOLEAN
Polygon
Polygon
ID: NUMBER <<PK>>
IS_SOLID : BOOLEAN
IS_COMPOSITE : BOOLEAN
IS_TRIANGULATED : BOOLEAN
GEOMETRY : SDO_GEOMETRY
BRepGeometry
ID: NUMBER <<PK>>
TYPE : VARCHAR2(30)
IS_SOLID : BOOLEAN
IS_COMPOSITE : BOOLEAN
IS_TRIANGULATED : BOOLEAN
GEOMETRY : SDO_GEOMETRY
ID: NUMBER <<PK>><<FK>>
GEOMETRY : SDO_GEOMETRY
 Ansätze zur Abbildung von Vererbungshierarchien
 Umsetzung der Geometrieklasse
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Wie kommt Geometrie in die Datenbank?
Institut für Geodäsie und Geoinformationstechnik
<bldg:lod1Solid>
<gml:Solid>
<gml:exterior>
<gml:CompositeSurface gml:id="lod1Surface">
<gml:surfaceMember>
<gml:Polygon gml:id="Left1">
<gml:exterior>
<gml:LinearRing gml:id="LeftRing1">
<gml:posList srsDimension="3"> 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
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
...
<gml:surfaceMember>
SURFACE_GEOMETRY
<gml:Polygon gml:id="Roof1">
ID
GMLID
PARENT
<gml:exterior>
_ID
<gml:LinearRing gml:id="RoofRing1">
<gml:posList srsDimension="3"> 0.01 0.0UUID_xyz
4.0 10.0
0.0 4.0 10.0 5.0 4.0 0.0 5.0 4.0 20.0 lod1Surface
0.0 4.0
1
</gml:posList>
3
Left1
2
</gml:LinearRing>
</gml:exterior>
4
Front1
2
</gml:Polygon>
5
Right1
2
</gml:surfaceMember>
</gml:CompositeSurface>
6
Back1
2
</gml:exterior>
7
Roof1
2
</gml:Solid>
‹#› </bldg:lod1Solid>
6
3
7
5
4
Datenbank ?
LOD1 building
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
ROOT
_ID
IS_
SOLID
IS_COM
POSITE
GEOMETRY
1
1
0
1
0
1
1
0
0
LoD1 surface 3
1
0
0
LoD1 surface 4
1
0
0
LoD1 surface 5
1
0
0
LoD1 surface 6
1
0
0
LoD1 surface 7
25. November 2008
Wie werden Texturen zugeordnet?
Institut für Geodäsie und Geoinformationstechnik
<app:appearanceMember>
<app:Appearance>
<app:theme>Summer</app:theme>
…
<app:surfaceDataMember>
<app:ParameterizedTexture gml:id="roofTexture">
<app:imageURI>roof.png</app:imageURI>
<app:wrapMode>wrap</app:wrapMode>
<app:target uri="#Roof1">
<app:TexCoordList>
<app:textureCoordinates ring="#RoofRing1">
0.0 0.0 1.0 0.0 1.0 1.0 0.0 1.0 0.0 0.0
</app:textureCoordinates>
TEXTUREPARAM
</app:TexCoordList>
SURFACE_
IS_TEXTURE
</app:target>
GEOMETRY
_PARAME
</app:ParameterizedTexture>
_ID
TRIZATION
</app:surfaceDataMember>
…
7
1
</app:Appearance>
</app:appearanceMember>
…
WORLD_TO
_TEXTURE
TEXTURE_
COORDINATES
SURFACE
_DATA_ID
-
0.0 0.0 1.0 0.0 1.0
1.0 0.0 1.0 0.0 0.0
x
10,5,4
0,1
1,1
0,5,4
7
10,0,4
0,0,4
0,0
‹#›
roof.png
1,0
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Entwicklung eines Import/Exporttools
Institut für Geodäsie und Geoinformationstechnik
Entwicklung eines Import/Exporttools
für CityGML-Instanzdokumente
CityGML
Xsd Schema
<xs:complexType
name="CityModelType">
<xs:complexContent>
<xs:extension
...
Java
Bindung
(JAXB)
Schema-basierte
Klassen
SQL
Abfragen
public class CityModel {
…}
(Imp/Export
Tool)
UML Schema
Vereinfachung
des komplexen
Datenmodells
von CityGML
Datenexport
Datenimport
Oracle
Datenbank
Schemavereinfachung
a
vereinfachtes
UML Schema
c
DatenbankErzeugung
Abbildung
Klassen 
Tabellen
Relationales
Datenbankschema
SQL DDL
Befehle
(JDeveloper)
b
Ableitung des relationalen Datenbankschemas
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Entwicklung eines Import/Exporttools: Überblick
Institut für Geodäsie und Geoinformationstechnik
Datenimport
CityGML
Eingabedatei
____
____
____
____
_____
____
_____
____
CityGML
lesen
folgt
Features
CityModel cityModel1 =
new CityModel () ;
…
Instanz von
citygml4j
XSD Schema
<xs:complexType
name="CityModelType">
<xs:complexContent>
…
</xs:complexType>
Java
Bindung
folgt
____
____
____
____
_____
____
_____
____
public class CityModel {
…}
Instanz von
CityGML
Ausgabedatei
Schema-basierte
Klassen
CityGML
schreiben
Features
CityModel cityModel1 =
new CityModel () ;
…
Datenbank
-import
angewendet
ImportFunktionalität
ExportFunktionalität
Oracle
Datenbank
___
___
___
___
___
___
statischer
 Kern der
Software
angewendet
Datenbank
-export
Datenexport
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Herausforderungen der CityGML/GML Verarbeitung
Institut für Geodäsie und Geoinformationstechnik
 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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Unterstützung beliebig großer CityGML-Dateien
Institut für Geodäsie und Geoinformationstechnik
Umsetzung eines zweistufigen Verfahrens
1. 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
<cityObjectMember> CityObject Instanz </cityObjectMember>
 Zwischenspeicherung der zugehörigen SAX-Ereignisse
 Hauptspeicherverbrauch bestimmt sich nach der Größe der XMLChunks, nicht mehr nach der Dateigröße
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Unterstützung beliebig großer CityGML-Dateien
Institut für Geodäsie und Geoinformationstechnik
Umsetzung eines zweistufigen Verfahrens
2. 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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Performante Datenverarbeitung
Institut für Geodäsie und Geoinformationstechnik
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
Thread Pool
Thread Pool
Worker
Worker
Worker
Worker
‹#›
Queue
Queue
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Auflösung von XLink-Verweisen
Institut für Geodäsie und Geoinformationstechnik
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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
XLink-Verweise: Zweistufige Strategie
Institut für Geodäsie und Geoinformationstechnik
1. 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)
2. Zweite Stufe: Post-Processing
 Abfrage der temporären XLink-Tabellen
 Auflösung des XLink-Ziels über Datenstruktur im Hauptspeicher
 Entsprechende Prozessierung des XLinks
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Datenimport – Schritt 1
Institut für Geodäsie und Geoinformationstechnik
____
_____
____
____
_____
____
_____
____
____
_____
____
____
_____
_____
____
___
___
___
___
___
___
___
___
___
___
___
___
___
___
___
Buffer
Queue
CityGML
Eingabedatei
____
_____
____
____
_____
____
_____
____
____
_____
____
____
_____
_____
____
TopLevel Feature
Queue
Temporärer
Buffer
citygml4j
SAX Parser
Parser Thread
(1 Instanz)
Featureerzeugung
Converter
Thread
(begrenzte Anzahl
von Instanzen)
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Datenimport – Schritt 2
Institut für Geodäsie und Geoinformationstechnik
____
_____
____
____
_____
____
_____
____
____
_____
____
____
_____
_____
____
___
___
___
___
___
___
___
___
___
___
___
___
___
___
___
TopLevel Feature
Queue
SQL-Befehl
Queues
Importfilter
Oracle
Datenbank
Datenbankupdate
Geodaten
___
___
___
commit
___
___
___
SQL Erzeugung
XLink
Information
XLinks
XLink
Queue
commit
Importer Thread
XLink Thread
(begrenzte Anzahl
von Instanzen)
(begrenzte Anzahl
von Instanzen)
___
___
___
mit separater
XLink Speicherung
(temporär)
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Datenimport – Schritt 3
Institut für Geodäsie und Geoinformationstechnik
____
_____
____
____
_____
____
_____
____
____
_____
____
____
_____
_____
____
___
___
___
___
___
___
___
___
___
___
___
___
___
___
___
XLink Resolver
Queue
Oracle
Datenbank
___
___
___
___
___
___
XLink
Splitter
SQL-Befehl
Queue
Oracle
Datenbank
Datenbankupdate
SQL-Erzeugung
___
___
___
___
___
___
XLinks
___
___
___
mit separater
XLink Speicherung
(temporär)
XLink
Splitter Thread
(1 Instanz)
commit
mit aufgelösten
XLinks
XLink
Resolver Thread
(begrenzte Anzahl
von Instanzen)
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Datenexport – Schritt 1
Institut für Geodäsie und Geoinformationstechnik
____
_____
____
____
_____
____
_____
____
____
_____
____
____
____
_____
____
___
___
___
___
___
___
Exportfilter
Splitter Thread
SQL
(1 Instanz)
TopLevel Feature
ID Queue
Oracle
Datenbank
___
___
___
SQL
Datenbankausgabe
___
___
___
Feature
Feature / Geometrie Anfrage
Exporter Thread
‹#›
(begrenzte Anzahl von Instanzen)
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Datenexport – Schritt 2
Institut für Geodäsie und Geoinformationstechnik
____
_____
____
____
_____
____
_____
____
____
_____
____
____
____
_____
____
___
___
___
___
___
___
Buffer
Queue
CityGML
Ausgabedatei
Temporärer
Buffer
Feature
CityGML
schreiben
citygml4j
____
_____
____
____
_____
____
_____
____
____
_____
____
____
_____
_____
____
Exporter Thread
IO Writer Thread
(begrenzte Anzahl von Instanzen)
(1 Instanz)
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Performance-Messung…
Institut für Geodäsie und Geoinformationstechnik
Import
Dataset
1.1 mio LOD1
buildings
10.927 LOD2
buildings
fully
textured
 w/o
textures
File size
Time
Features
/ second
No. of
workers
1:15h
228
4
2:25h
121
Export
Geometry /
Appearance /
XLinks
Time
Features
/ second
No. of
workers
11511040 /
0/0
38min
455
10
1
11511040 /
0/0
1:57h
150
1
4.3min
42
4
2min
91
4
7,5 GB
163 MB
+
57 MB
163 MB
25
min
7
4
434714 /
43348 /
391006
6.5
min
28
4
434714 /
0 / 391006
Database server: 2 x Intel Xeon Dual Core@3GHz, 6GB RAM, SCSI Raid 5 Disk Array,
Windows Server 2003 SP2, 100MBit LAN
‹#›
Client running the import/export tool: Intel Core2 CPU [email protected], 2GB RAM,
WindowsXP SP2, 100MBit LAN
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Charakteristika des Import/Exporttools
Institut für Geodäsie und Geoinformationstechnik
Volle Unterstützung von CityGML 1.0.0, 0.4.0, 0.3.1, 0.3.0
Unterstützung beliebig großer CityGML-Dateien (>4GB)
Nebenläufigkeit der Datenverarbeitung durch Multithreading
Hohe Performance auch auf Standard-Systemen
 7GB Datei (>1mio 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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Charakteristika des Import/Exporttools
Institut für Geodäsie und Geoinformationstechnik
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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Geplante Erweiterungen
Institut für Geodäsie und Geoinformationstechnik
 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
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Verfügbarkeit
Institut für Geodäsie und Geoinformationstechnik
 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/
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Referenzen
Institut für Geodäsie und Geoinformationstechnik
 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/products/goloader/index.htm
[letzter Zugriff: 2008-06-20].
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008
Institut für Geodäsie und Geoinformationstechnik
Fragen ?
Claus Nagel
Alexandra Stadler
Gerhard König
Thomas H. Kolbe
{ nagel|stadler|koenig|kolbe} @ igg.tu-berlin.de
Technische Universität Berlin
Institut für Geodäsie und Geoinformationstechnik
Fachgebiet Methodik der Geoinformationstechnik
Straße des 17. Juni 135, 10623 Berlin
‹#›
Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank
25. November 2008