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 • Voraussetzung:Grundlegendes 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 <<<<<<< Public Comment Phase >>>>>>> CityGML 1.0.0OGC Implementation Specification(after final OGC TC vote) 2008-08-20  Internationaler Standard

6. <<Geometry>> gml::_Geometry LOD 0-4 GeometryProperty LOD 0-4 GeometryProperty CityGML: thematische Gliederung in Objektklassen <<Feature>> gml::_Feature ExternalReference - informationSystem: anyURI - externalReference: ExternalObjectReferenceType <<Feature>> _CityObject <<FeatureCollection>>CityModel * * … <<Feature>> _AbstractBuilding <<Feature>> _TransportationObject <<Feature>> ReliefFeature <<Feature>> _WaterBody <<Feature>> _Vegetation

7. ab LOD1 ab LOD2 ab LOD3 ab LOD4 CityGML: Detailstufen in der Gebäudemodellierung Gebäudemodell

8. Semantik basierend auf ISO 19109 Geometrie basierend auf ISO 19107 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. (rekursive)Gruppierungvon Objekten DigitaleGeländemodelle(DGM) Verwaltung vonDGMs und Luftbildern(WebServices) Flexible3D-Geometrien Gebäude bisLOD 3 Generische(prototypische)3D-Objekte Versions-management Referenzierungvon externenDatenquellen 2. Projektphase 1. Projektphase Gebäude inkl.Innenraum-modellierung(LOD 4) umfassendethematischeModellierung Import undExport vonCityGML-Files Oberflächen-daten Funktionsumfang der 3D-Geodatenbank von CityGML vererbte Eigenschaften Zusatz

11. Entwicklung eines Import/Exporttools für CityGML-Instanzdokumente CityGML c Xsd Schema <xs:complexTypename="CityModelType"> <xs:complexContent> <xs:extension ... JavaBindung (JAXB) Schema-basierte Klassen public class CityModel {… } SQLAbfragen (Imp/ExportTool) UML Schema Daten-export Daten-import OracleDatenbank Vereinfachung des komplexen Datenmodells von CityGML Schema-verein-fachung Datenbank-Erzeugung a AbbildungKlassen Tabellen vereinfachtesUML Schema RelationalesDatenbankschema SQL DDLBefehle (JDeveloper) b Ableitung des relationalen Datenbankschemas Entwicklungsablauf

12. Entwicklung eines Import/Exporttools für CityGML-Instanzdokumente CityGML c Xsd Schema <xs:complexTypename="CityModelType"> <xs:complexContent> <xs:extension ... JavaBindung (JAXB) Schema-basierte Klassen public class CityModel {… } SQLAbfragen (Imp/ExportTool) UML Schema Daten-export Daten-import OracleDatenbank Vereinfachung des komplexen Datenmodells von CityGML Schema-verein-fachung Datenbank-Erzeugung a AbbildungKlassen Tabellen vereinfachtesUML Schema RelationalesDatenbankschema SQL DDLBefehle (JDeveloper) b Ableitung des relationalen Datenbankschemas 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 n:m  1:n oder n:1(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. Entwicklung eines Import/Exporttools für CityGML-Instanzdokumente c JavaBindung (JAXB) Schema-basierte Klassen public class CityModel {… } SQLAbfragen (Imp/ExportTool) Daten-export Daten-import Ableitung des relationalen Datenbankschemas CityGML Xsd Schema <xs:complexTypename="CityModelType"> <xs:complexContent> <xs:extension ... UML Schema OracleDatenbank Vereinfachung des komplexen Datenmodells von CityGML Schema-verein-fachung Datenbank-Erzeugung a AbbildungKlassen Tabellen vereinfachtesUML Schema RelationalesDatenbankschema SQL DDLBefehle (JDeveloper) b Ableitung des relationalen Datenbankschemas

18.  Umsetzung der Geometrieklasse Abbildung von Vererbungshierarchien • Ansätze zur Abbildung von Vererbungshierarchien

19. 6 3 7 5 4 Wie kommt Geometrie in die Datenbank? <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> <gml:Polygon gml:id="Roof1"> <gml:exterior> <gml:LinearRing gml:id="RoofRing1"> <gml:posList srsDimension="3"> 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 </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> </gml:surfaceMember> </gml:CompositeSurface> </gml:exterior> </gml:Solid> </bldg:lod1Solid> LOD1 building Datenbank ?

20. 10,5,4 10,0,4 0,1 1,1 0,5,4 7 0,0,4 0,0 1,0 roof.png Wie werden Texturen zugeordnet? <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> </app:TexCoordList> </app:target> </app:ParameterizedTexture> </app:surfaceDataMember> … </app:Appearance> </app:appearanceMember>

21. Vereinfachung des komplexen Datenmodells von CityGML Schema-verein-fachung Datenbank-Erzeugung a AbbildungKlassen Tabellen vereinfachtesUML Schema RelationalesDatenbankschema SQL DDLBefehle (JDeveloper) b Ableitung des relationalen Datenbankschemas Entwicklung eines Import/Exporttools Entwicklung eines Import/Exporttools für CityGML-Instanzdokumente CityGML c Xsd Schema <xs:complexTypename="CityModelType"> <xs:complexContent> <xs:extension ... JavaBindung (JAXB) Schema-basierte Klassen public class CityModel {… } SQLAbfragen (Imp/ExportTool) UML Schema Daten-export Daten-import OracleDatenbank

22. Datenimport Import-Funktionalität JavaBindung Schema-basierte Klassen public class CityModel {… } CityGMLEingabedatei ____ ________ ____ _____ ____ _____ ____ Datenbank-import CityGMLlesen Features CityModel cityModel1 = new CityModel () ; … Export-Funktionalität folgt Instanz von angewendet statischerKern der Software  OracleDatenbank angewendet folgt Instanz von CityGMLAusgabedatei ____ ________ ____ _____ ____ _____ ____ CityGMLschreiben Features CityModel cityModel1 = new CityModel () ; … Datenbank-export Datenexport _________ _________ Entwicklung eines Import/Exporttools: Überblick citygml4j XSD Schema <xs:complexTypename="CityModelType"> <xs:complexContent> … </xs:complexType>

23. 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 zukomplexen 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

24. 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 <cityObjectMember> CityObject Instanz </cityObjectMember> • Zwischenspeicherung der zugehörigen SAX-Ereignisse • Hauptspeicherverbrauch bestimmt sich nach der Größe der XML-Chunks, nicht mehr nach der Dateigröße

25. 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

26. Thread Pool Thread Pool Worker Worker Worker Worker Queue Queue 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

27. 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

28. 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

29. ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ _____ _____ ____ _________ _________ _________ _________ _________ BufferQueue TopLevel FeatureQueue CityGMLEingabedatei TemporärerBuffer ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ _____ _____ ____ citygml4j Feature-erzeugung SAX Parser Parser Thread(1 Instanz) Converter Thread(begrenzte Anzahl von Instanzen) Datenimport – Schritt 1

30. ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ _____ _____ ____ _________ _________ _________ _________ _________ TopLevel FeatureQueue SQL-BefehlQueues OracleDatenbank Importfilter Datenbank-update Geodaten commit _________ _________ SQL Erzeugung XLinkInformation _________ XLinks XLinkQueue mit separaterXLink Speicherung(temporär) commit XLink Thread(begrenzte Anzahl von Instanzen) Importer Thread(begrenzte Anzahl von Instanzen) Datenimport – Schritt 2

31. ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ _____ _____ ____ _________ _________ _________ _________ _________ XLink ResolverQueue SQL-BefehlQueue OracleDatenbank OracleDatenbank Datenbank-update _________ SQL-Erzeugung _________ _________ XLinkSplitter _________ XLinks commit mit aufgelöstenXLinks XLinkSplitter Thread(1 Instanz) XLinkResolver Thread(begrenzte Anzahl von Instanzen) Datenimport – Schritt 3 _________ mit separaterXLink Speicherung(temporär)

32. ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ ____ _____ ____ _________ _________ Exportfilter Splitter Thread(1 Instanz) SQL TopLevel FeatureID Queue OracleDatenbank Datenbank-ausgabe Feature _________ _________ SQL Feature / Geometrie Anfrage Exporter Thread(begrenzte Anzahl von Instanzen) Datenexport – Schritt 1

33. ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ ____ _____ ____ _________ _________ BufferQueue CityGMLAusgabedatei TemporärerBuffer ____ _________ ____ _____ ____ _____ ____ ____ _____ ____ ____ _____ _____ ____ Feature CityGMLschreiben citygml4j Exporter Thread(begrenzte Anzahl von Instanzen) IO Writer Thread(1 Instanz) Datenexport – Schritt 2

34. Performance-Messung… Import Export 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 6600@2.4GHz, 2GB RAM, WindowsXP SP2, 100MBit LAN

35. 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 (>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

36. 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

37. 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

38. 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!!

39. 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/products/goloader/index.htm [letzter Zugriff: 2008-06-20].

40. Fragen ? Claus NagelAlexandra Stadler Gerhard König Thomas H. Kolbe { nagel|stadler|koenig|kolbe} @ 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