die oracle-schnittstelle der berliner 3d-geodatenbank

Institut für Geodäsie und GeoinformationstechnikInstitut für Geodäsie und Geoinformationstechnik

25. November 2008

Die Oracle-Schnittstelleder Berliner 3D-GeodatenbankDie Oracle-Schnittstelleder Berliner 3D-Geodatenbank

Claus Nagel, Alexandra Stadler, Gerhard König, Thomas H. Kolbe

Technische Universität BerlinInstitut für Geodäsie und GeoinformationstechnikFachgebiet Methodik der Geoinformationstechnik

2


Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank 25. November 2008

MotivationMotivation

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


Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank 24. Juli 2008

Oracle 10g R2Oracle 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



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)

CityGML: ÜberblickCityGML: Überblick

5


Nagel, Stadler, König, Kolbe: Die Oracle-Schnittstelle der Berliner 3D-Geodatenbank 24. Juli 2008

CityGML: Auf dem Weg zum OGC-StandardCityGML: Auf dem Weg zum OGC-Standard

CityGML 0.4.0OGC Best Practices Paper

CityGML 1.0.0 (Proposal)OGC Request for Comments

CityGML 0.3.0OGC Discussion Paper

2007-05-30

2008-02-04

2006-03-06

2008-02-192008-03-20

CityGML 1.0.0OGC Implementation Specification(after final OGC TC vote)

2008-08-20

<<<<<<< Public Comment Phase >>>>>>>

Internationaler Standard

6



CityGML: thematische Gliederung in ObjektklassenCityGML: thematische Gliederung in Objektklassen

ExternalReference

- informationSystem: anyURI - externalReference: ExternalObjectReferenceType

<<FeatureCollection>>CityModel

**

…

LOD 0-4 GeometryProperty

<<Geometry>>gml::_Geometry LOD 0-4 GeometryProperty

<<Feature>>_Transportation

Object

<<Feature>>_AbstractBuilding

<<Feature>>ReliefFeatur

e

<<Feature>>_WaterBody

<<Feature>>_Vegetation

<<Feature>>_CityObject

<<Feature>>gml::_Feature

7



CityGML: Detailstufen in der GebäudemodellierungCityGML: Detailstufen in der Gebäudemodellierung

Gebäudemodell

ab LOD1

ab LOD2

ab LOD3

ab LOD4

8



CityGML: Kohärenz von Semantik und GeometrieCityGML: Kohärenz von Semantik und Geometrie

Building

BuildingPartBuildingPart

RoofSurf.

RoofSurf.

Door

WallSurf.

WallSurf.

Window

Building Installation

...

......

CompositeSolid

SolidSolid

Polygon

Polygon

Polygon

Polygon

CompositeSurface

...

......

Polygon

Semantics Geometry

CompositeSurface

Semantik

basierend auf ISO 19109

Geometriebasierend auf ISO 19107

8

9



Eine 3D-Geodatenbank für BerlinEine 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



Flexible3D-Geometrien

Generische(prototypische)

3D-Objekte

Gebäude bisLOD 3

DigitaleGeländemodelle

(DGM)

Versions-management

Verwaltung vonDGMs und Luftbildern

(WebServices)

Referenzierungvon externenDatenquellen

(rekursive)Gruppierungvon Objekten

Funktionsumfang der 3D-GeodatenbankFunktionsumfang der 3D-Geodatenbank

umfassendethematischeModellierung

Oberflächen-daten

Import undExport von

CityGML-Files

Gebäude inkl.Innenraum-

modellierung(LOD 4)

von CityGML vererbte Eigenschaften Zusatz

1.

Pro

jektp

hase

2.

Pro

jektp

hase

11



Entwicklung eines Import/Exporttools für CityGML-

Instanzdokumentec

Vereinfachung des

komplexen Datenmodell

s von CityGML

a

CityGML Xsd Schema<xs:complexTypename="CityModelType"> <xs:complexContent> <xs:extension ...

UML Schema

vereinfachtesUML Schema

Schema-verein-fachung

JavaBindung

(JAXB)

Schema-basierte Klassen

public class CityModel {… }

SQLAbfragen

(Imp/ExportTool)

Daten-import

Daten-export

Ableitung des relationalen Datenbankschemas

b

AbbildungKlassen Tabellen

OracleDatenbank

SQL DDLBefehle

(JDeveloper)

Datenbank-Erzeugung

RelationalesDatenbankschema

EntwicklungsablaufEntwicklungsablauf

12




Instanzdokumentec

JavaBindung

(JAXB)



SQLAbfragen

(Imp/ExportTool)

Daten-import

Daten-export


b


OracleDatenbank

SQL DDLBefehle

(JDeveloper)

Datenbank-Erzeugung


Vereinfachung des


s von CityGML

a


UML Schema



Vereinfachung des Datenmodells von CityGMLVereinfachung des Datenmodells von CityGML

13



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

Vereinfachung des Datenmodells von CityGMLVereinfachung des Datenmodells von CityGML

14



Auflistung durchgeführter VereinfachungenAuflistung 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-GeometrieklassenVereinfachte Abbildung der GML-Geometrieklassen

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

<<Geometry>>_BRepGeometry

<<Geometry>>Polygon

+isSolid : boolean [1]+isComposite : boolean [1]+isTriangulated : boolean [1]

+geometry : Polygon [1]

<<Geometry>>BRepAggregate

0..1

1..*

bRepMember <<Geometry>>_BRepGeometry

<<Geometry>>Polygon




0..1

1..*

bRepMember

16



Attribute der Klasse _BRepGeometryAttribute der Klasse _BRepGeometry

+isSolid: 1… Geometrie ist geschlossen bildet einen Solid0… Geometrie ist nicht geschlossen bildet eine Surface

+isComposite: 1… Geometrie ist zusammenhängend bildet einen Composite0… 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 Geometrienbeim Export entfällt Prüfung auf mehrfach vorkommende

Geometrien Performancesteigerung!

+isReverse: Geometrie in DB immer im korrekten Drehsinn gespeichert direkte Verarbeitung sichergestelltfür Export von XLinks wird der Drehsinn aus dem Originalfile

benötigtisReverse kennzeichnet den Drehsinn einer Geometrie im

Originalfile

17




Vereinfachung des


s von CityGML

a


UML Schema



Instanzdokumentec

JavaBindung

(JAXB)



SQLAbfragen

(Imp/ExportTool)

Daten-import

Daten-export


b


OracleDatenbank

SQL DDLBefehle

(JDeveloper)

Datenbank-Erzeugung


Ableitung des relationalen DatenbankschemasAbleitung des relationalen Datenbankschemas

18



Abbildung von VererbungshierarchienAbbildung von Vererbungshierarchien

Ansätze zur Abbildung von Vererbungshierarchien

<<Geometry>>_BRepGeometry

<<Geometry>>Polygon




0..1

1..*

bRepMember <<Geometry>>_BRepGeometry

<<Geometry>>Polygon




0..1

1..*

bRepMember

BRepAggregateID: NUMBER <<PK>><<FK>>

Polygon

ID: NUMBER <<PK>><<FK>>GEOMETRY : SDO_GEOMETRY

BRepGeometryID: NUMBER <<PK>>IS_SOLID : BOOLEANIS_COMPOSITE : BOOLEANIS_TRIANGULATED : BOOLEAN

BRepAggregateID: NUMBER <<PK>>IS_SOLID : BOOLEANIS_COMPOSITE : BOOLEANIS_TRIANGULATED : BOOLEAN

PolygonID: NUMBER <<PK>>IS_SOLID : BOOLEANIS_COMPOSITE : BOOLEANIS_TRIANGULATED : BOOLEANGEOMETRY : SDO_GEOMETRY

BRepGeometryID: NUMBER <<PK>>TYPE : VARCHAR2(30)IS_SOLID : BOOLEANIS_COMPOSITE : BOOLEANIS_TRIANGULATED : BOOLEANGEOMETRY : SDO_GEOMETRY

Umsetzung der Geometrieklasse

19



Wie kommt Geometrie in die Datenbank?Wie kommt Geometrie in die Datenbank?

LOD1 building

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>

SURFACE_GEOMETRYID GMLID PARE

NT_ID

ROOT

_ID

IS_SOLI

D

IS_COM

POSITE

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

7

45

63

20



Wie werden Texturen zugeordnet?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>

TEXTUREPARAMSURFACE_GEOMET

RY_ID

IS_TEXTURE

_PARAMETRIZATIO

N

WORLD_TO_TEXTU

RE

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

…

roof.png0,0 1,0

0,1 1,1

0,0,4

10,0,4

10,5,4

0,5,4 7

23



Vereinfachung des


s von CityGML

avereinfachtesUML Schema



b


SQL DDLBefehle

(JDeveloper)

Datenbank-Erzeugung



Instanzdokumentec


UML Schema

JavaBindung

(JAXB)



SQLAbfragen

(Imp/ExportTool)

Daten-import

Daten-export

OracleDatenbank

Entwicklung eines Import/ExporttoolsEntwicklung eines Import/Exporttools

24



Entwicklung eines Import/Exporttools: ÜberblickEntwicklung eines Import/Exporttools: Überblick

Datenimport

CityGMLEingabedatei____ ____________ _____ ____ _________

CityGMLlesen

Features

CityModel cityModel1 = new CityModel () ; …

folgt Instanz von

Datenexport

_________ _________

OracleDatenban

k

Datenbank-import

angewendet

Features

CityModel cityModel1 = new CityModel () ; …

Datenbank-export

angewendetInstanz von

CityGMLAusgabedatei____ ____________ _____ ____ _________

CityGMLschreiben

folgt

statischerKern der Software

citygml4j XSD Schema<xs:complexTypename="CityModelType"> <xs:complexContent> … </xs:complexType>

JavaBindung



Import-Funktionalität

Export-Funktionalität

25



Herausforderungen der CityGML/GML VerarbeitungHerausforderungen 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öglichKorrekte Abbildung in Datenbank erfordert Auflösung von XLinks

26



Unterstützung beliebig großer CityGML-DateienUnterstützung beliebig großer CityGML-Dateien

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 XML-

Chunks, nicht mehr nach der Dateigröße

27



Unterstützung beliebig großer CityGML-DateienUnterstützung beliebig großer CityGML-Dateien

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

28



Performante DatenverarbeitungPerformante Datenverarbeitung

Queue

Thread Pool

Worker

Worker

Worker

Thread Pool

Queue

Worker

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-VerweisenAuflö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 StrategieXLink-Verweise: Zweistufige Strategie

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

31


25. November 2008

Parser Thread(1 Instanz)

Converter Thread

(begrenzte Anzahl von Instanzen)

Datenimport – Schritt 1Datenimport – Schritt 1

____ _____________ _____ ____ _____________ _____ ____ ____ _____ _________

CityGMLEingabedat

ei

SAX Parser

TemporärerBuffer

BufferQueue

Feature-erzeugung

citygml4j

TopLevel FeatureQueue

__________________

_________

_________

_________

____ _____________ _____ ____ _____________ _____ ____ ____ _____ _________


32


25. November 2008

_________

mit separaterXLink Speicherung

(temporär)XLink Thread(begrenzte Anzahl

von Instanzen)

Importer Thread



TopLevel FeatureQueue

commit

XLinks XLinkInformatio

n

Datenbank-update

_________ _________

OracleDatenbank

SQL Erzeugung

commit

SQL-BefehlQueues

Geodaten

Importfilter

XLinkQueue

__________________

_________

_________

_________

____ _____________ _____ ____ _____________ _____ ____ ____ _____ _________


33


25. November 2008

XLinkResolver Thread


XLinkSplitter Thread

(1 Instanz)


__________________

_________

_________

_________

____ _____________ _____ ____ _____________ _____ ____ ____ _____ _________

XLinkSplitter

XLink ResolverQueue

Datenbank-

update

OracleDatenbank

__________________

mit aufgelöstenXLinks

SQL-Erzeugung

XLinks

commit

SQL-BefehlQueue

mit separaterXLink Speicherung

(temporär)

_________

_________ _________

OracleDatenbank


34


25. November 2008

Exporter Thread(begrenzte Anzahl von Instanzen)

Splitter Thread(1 Instanz)

Datenexport – Schritt 1Datenexport – Schritt 1

Feature

Exportfilter

SQL

TopLevel Feature

ID Queue

Datenbank-

ausgabeSQL

Feature / Geometrie Anfrage

__________________

OracleDatenba

nk

____ _____________ _____ ____ _____________ _____ ____ ____ ____ _________

__________________


35


25. November 2008

IO Writer Thread(1 Instanz)

Exporter Thread(begrenzte Anzahl von

Instanzen)

citygml4j

Temporärer

Buffer

BufferQueue

____ _____________ _____ ____ _____________ _____ ____ ____ _____ _________

CityGMLAusgabeda

tei

CityGMLschreiben

Datenexport – Schritt 2Datenexport – Schritt 2

____ _____________ _____ ____ _____________ _____ ____ ____ ____ _________

__________________

Feature


36


25. November 2008

Performance-Messung…Performance-Messung…

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

Dataset File size

Time Features /

second

No. of worker

s

Geometry / Appearance / XLinks

Time Features /

second

No. of workers

1.1 mio LOD1

buildings7,5 GB

1:15h 228 411511040 /

0 / 038mi

n455 10

2:25h 121 111511040 /

0 / 01:57h 150 1

10.927 LOD2

buildingsfully

textured

163 MB+

57 MB25 min

7 4434714 /43348 /

391006

4.3min

42 4

w/o textures

163 MB6.5 min

28 4434714 /

0 / 391006 2min 91 4

Import Export

37



Charakteristika des Import/ExporttoolsCharakteristika 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-Systemen7GB Datei (>1mio LOD1-Gebäude) Import: 75min, Export:

38min

Unterstützung von XLinks

Benutzerdefinierter Import und Export durch FilteroptionenGML ID, GML Name

Blockweiser Import/Export zur Datenkachelung (mittels Bounding Boxes)

Auswahl von Objektklassen

38



Charakteristika des Import/ExporttoolsCharakteristika des Import/Exporttools

Zwei SchnittstellenGraphische 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 ErweiterungenGeplante 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ügbarkeitVerfü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



ReferenzenReferenzen

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

42



Claus NagelAlexandra StadlerGerhard KönigThomas 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

Fragen ?

die oracle-schnittstelle der berliner 3d-geodatenbank

Documents