ID 5399
Schilling, Arne: Integration und Visualisierung von 2D- und 3D-Geodaten in einem verteilten
GIS am
Beispiel virtueller Stadttouren / Arne Schilling - Hamburg: Diplomica GmbH, 2002
Zugl.: Heidelberg, Universität, Diplom, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
v
Inhaltsverzeichnis
1 Einführung und Konzeption ...1
1.1
GIS und 3D-Visualisierung ... 1
1.2
Bisherige Entwicklungen internetbasierter 3D-GIS ... 3
1.3
Zielsetzung und Anforderungen... 4
1.4
Konzeption eines Virtual Reality Servers ... 6
2 Grundlagen für die Implementierung...9
2.1
Deep Map... 9
2.2
Verfügbare Geodatenquellen und Geodaten ... 11
2.2.1
SDE ... 11
2.2.2
OpenGIS Geodatenserver ... 13
2.2.3
3D/4D Datenbank ... 14
2.2.4
ODF-Modell ... 14
2.2.5
VRML-Modelle... 15
2.3
Verfügbare 3D-Technologien ... 16
2.3.1
VRML ... 16
2.3.2
X3D... 19
2.3.3
Java3D... 20
3 Datenkomponente...21
3.1
Möglichkeiten der Modellierung von 3D-Geodaten... 21
3.1.1
Modellierung der Objekte ... 21
3.1.1.1
Geometrische Modellierung ... 21
3.1.1.2
Levels-of-Detail ... 24
3.1.2
Modellierung des Geländemodells... 26
3.1.2.1
Geometrische Modellierung ... 27
3.1.2.2
Levels-of-Detail Konzepte... 30
3.1.2.3
Shading-Texturen ... 31
3.1.2.4
Darstellung von thematischen Daten... 31
3.1.2.5
Sichtbarkeitsanalysen ... 32
3.2
Implementierung des Geometrie- und Feature-Modells... 33
3.2.1
Geometrie-Modell... 33
3.2.2
Feature-Modell... 38
vi Inhaltsverzeichnis
4 Managementkomponente ... 43
4.1
Geodatenverwaltung... 44
4.1.1
Collections... 44
4.1.2
Datenquellen-Schicht... 45
4.1.3
Layer-Schicht... 46
4.1.4
Thema-Schicht... 47
4.1.5
Konfiguration der Datenquellen-, Layer- und Thema-Schicht ... 48
4.2
Räumliche Abfrage... 49
4.3
Integration der Objekte... 51
4.3.1
Konvertierung von 2D zu 3D Daten... 51
4.3.2
Integration verschiedener SRS ... 55
4.3.3
Verschneidung der Features ... 56
4.3.3.1
Halbautomatische Verschneidung ... 58
4.3.3.2
Automatische Verschneidung... 59
4.4
Integration des Geländemodells ... 62
4.5
Export der Geodaten... 64
4.6
Einbindung in Deep Map und ans Internet ... 66
4.6.1
Einbindung in Deep Map ... 66
4.6.2
Server-Client Kommunikation ... 68
4.6.3
Inkrementelle Datenübertragung... 68
4.6.4
Datenreduktion... 69
5 Visualisierungskomponente... 71
5.1
Benutzeroberfläche ... 72
5.2
Tourenvisualisierung... 72
5.3
Anzeige von Objektinformationen... 73
6 Ergebnisse ... 75
6.1
Geländemodell... 75
6.2
Viewshed-Analyse ... 77
6.3
Aus 2D generierte 3D Geodaten ... 78
6.4
Verschneidung von extrudierten Grundrissen und echten 3D-Modellen... 80
6.5
Integriertes 3D-Modell ... 81
6.6
Tourensimulation ... 84
6.7
Vergleich verschiedener Modellgrößen... 85
7 Zusammenfassung und Ausblick... 87
Literaturverzeichnis... 91
vii
Abbildungsverzeichnis
Abbildung 1: Benutzeroberfläche von Virtual Glasgow. Beispiel für eine Virtual
City im Internet. ... 4
Abbildung 2: Grobkonzept eines Virtual Reality Servers für die Integration von
2D- und 3D-Geodaten... 6
Abbildung 3: Mobiler Prototyp von Deep Map... 9
Abbildung 4: Organisation der räumlichen Daten durch Tabellen in SDE... 12
Abbildung 5: Rekonstruiertes Gebäude. Links Randdarstellung, rechts zusammen
mit DHM [Quelle: BrHa00]. ... 14
Abbildung 6: 3D-Modell der Heidelberger Altstadt. ... 15
Abbildung 7: Routing bei VRML. Im Beispiel ist der Zeitpunkt des Berührens
eines TouchSensors mit der Mouse mit dem Start der Wiedergabe eines
Klanges verknüpft... 17
Abbildung 8: GeoVRML. Beispiel für GeoElevationGrid... 18
Abbildung 9: Java3D Szenengraph [Quelle: Sun00]. ... 20
Abbildung 10: Zellenmodell nach Molenaar... 22
Abbildung 11: Differenz-Operation bei CSG... 23
Abbildung 12: Quadtree (links) und Octree (rechts). ... 24
Abbildung 13: Verschiedene Levels-of-Detail eines Gebäudes. ... 25
Abbildung 14: RSG. Die Farbwerte entsprechen unterschiedlichen Höhen des
Geländes. ... 27
Abbildung 15: Verhältnis zwischen Delaunay-Triangulation und Voronoi-
Diagramm... 28
Abbildung 16: HTIN. Sukzessive Verfeinerung durch Aufteilung in weitere
Dreiecke [nach FlMa97]. ... 29
Abbildung 17: Anwendung von Shading-Texturen. In der oberen Bildhälfte ist
ein sehr feinmaschiges TIN mit Gouraud-Shading abgebildet, unten ein
vereinfachtes TIN mit darauf gelegter Shading-Textur [nach DöHi00]... 31
Abbildung 18: Das Geometriemodell des VRServers als UML-Diagramm. ... 35
Abbildung 19: Zugriff auf die Eckpunkt-Koordinaten in VRML. Die
Koordinaten und der Knoten, der diese enthält, sind hervorgehoben... 36
Abbildung 20: Topologische Beziehungen zwischen den Elementen eines TINs
(ti: Dreieck, ei: Kante, ni: Knoten). ... 37
Abbildung 21: Das DGM-Modell des VRServers als UML-Diagramm... 37
Abbildung 22: Grobkonzept eines Features. ... 38
Abbildung 23: Das Feature-Modell des VRServers als UML-Diagramm. ... 40
viii Abbildungsverzeichnis
Abbildung 24: Interaktionsdiagramm der wichtigsten Klassen des VRServers... 43
Abbildung 25: Die Informationen für die Konvertierung von 2D nach 3D stehen
in der Klasse VRExtrusion. ... 46
Abbildung 26: Verschiedene Generalisierungsgrade eines Gebäudegrundrisses.
Durch geometrische Vereinfachung lässt sich die Anzahl der Eckpunkte (v.a.
bei Rundungen) reduzieren, ohne dass wesentliche Informationen verloren
gehen. Der Wert ,,Flatness" entspricht ungefähr den resultierenden
Kantenlängen... 47
Abbildung 27: Die Klassen VRTheme, VRLayer und die Schnittstelle
VRDataSource dienen der Geodatenverwaltung. UML-Diagramm. ... 48
Abbildung 28: GUI von XML-Spy zur Editierung der Konfigurations-Datei... 49
Abbildung 29: Fokusregionen entlang einer Tour. ... 50
Abbildung 30: Dreistufige Hierarchie des Datenmanagements am Beispiel eines
Feature-Themas, das aus zwei Layern besteht. Auf der rechten Seite befinden
sich die Hilfsklassen...51
Abbildung 31: Die Integration als Kette einzelner Teilprozesse. ... 51
Abbildung 32: Höheninformationen als Attribute im GIS. ArcView Tabelle... 53
Abbildung 33: Möglichkeiten der Konvertierung von 2D nach 3D Geometrien... 54
Abbildung 34: Das Koordinatentransformationspaket von SEDRIS und die
Erweiterung um Gauß-Krüger Koordinaten. ... 55
Abbildung 35: Vergleich der Aufteilung von Gebäudekomplexen in Teilobjekte
bei verschiedenen Datenquellen. Links digitale Grundrisskarte, rechts 3D-
Modell aus ODF-Datei. A) Stadthalle, B) Marstall. ... 57
Abbildung 36: Verknüpfungen zwischen Objekten aus verschiedenen
Datenquellen über Attribute bei der halbautomatischen Verschneidung. Die
Tabelle zeigt die einer ArcView Shape-Datei zugehörigen DBase-Tabelle. Die
Werte in den einzelnen Spalten gehen als Attribute (properties) in die
Feature-Objekte ein. ... 59
Abbildung 37: Die einzelnen Schritte bei der automatischen Verschneidung... 60
Abbildung 38: Anordnung der Views beim Erzeugen einer Feature-Liste
(VRFeatureCollection) aus mehreren Layern... 60
Abbildung 39: Konvexe Hülle eines Gebäudegrundrisses... 61
Abbildung 40: Kopiervorgänge bei der räumlichen Zusammenführung der
Features. Die Zahlen beziehen sich auf die Objekt-IDs des
Marstallkomplexes aus Abbildung 35 B. ... 62
Abbildung 41: Multiresolution-Geländemodell in Aufsicht.
Drahtgitterdarstellung... 63
Abbildung 42: Export der Features nach VRML... 65
Abbildung 43: Darstellung von Bäumen durch mehrere Levels-of-Detail. ... 66
Abbildung 44: Architektur des Gesamtsystems. Die Beschreibung der einzelnen
Komponenten erfolgt im Text... 67
Abbildung 45: Datenreduktion am Beispiel einer ca. 2200 KByte großen VRML-
ix
Datei, 1: ursprüngliche Datei, 2: Begrenzung der Koordinatengenauigkeit auf
1 cm, 3: zusätzliche Komprimierung nach dem Huffman-Verfahren. ... 70
Abbildung 46: GUI der Visualisierungskomponente. ... 71
Abbildung 47: Multiresolution-DGM in Schrägansicht. Schattierte Darstellung... 75
Abbildung 48: Vergleich zwischen der Einbettung von Gebäuden in das
ursprüngliche DGM (oben) und in ein um Plattformen erweitertes DGM
(unten)... 76
Abbildung 49: Viewshed. Links: ursprüngliches DGM, rechts: Auf den Viewshed
reduziertes DGM; die weißen Flächen sind von der Tour aus nicht sichtbar
und wurden gelöscht. Der Verlauf der Tour ist als Kurve eingezeichnet. ... 77
Abbildung 50: Auf DGM gelegte Straßenbegrenzungen... 78
Abbildung 51: Auf DGM gelegte Baublockflächen... 79
Abbildung 52: Mit Labels versehene Objekte... 79
Abbildung 53: Aus Gebäudegrundrissen extrudierte Blockmodelle im Bereich der
Altstadt... 80
Abbildung 54: ODF-Modelle, die die Gebäude als echte 3D-Modelle zeigen.
Dächer und Wände wurden wie in der vorigen Abbildung aufgrund dem
Neigungswinkel unterschiedlich eingefärbt... 80
Abbildung 55: Ergebnis der Verschneidung von extrudierten Grundrissen und
ODF-Modellen... 80
Abbildung 56: Integriertes 3D-Modell. Terrestrische Ansicht Universitätsplatz... 81
Abbildung 57: Integriertes 3D-Modell. Vogelperspektive Universitätsplatz. ... 82
Abbildung 58: Integriertes 3D-Modell. Vogelperspektive Altstadt... 82
Abbildung 59: Integriertes 3D-Modell. Übersicht westliche Altstadt, östliches
Bergheim und Neuenheim. Für Gebiete außerhalb der Altstadt sind keine
3D-Modelle vorhanden, so dass hier extrudierte Gebäudegrundrisse ohne
Dachlandschaft verwendet wurden... 83
Abbildung 60: Tourensimulation. Ansicht im Modus WALKTHROUGH.
Universitätsplatz... 84
Abbildung 61: Tourensimulation. Ansicht im Modus FLYOVER. ... 84
Abbildung 62: Tourensimulation. Ansicht im Modus OVERVIEW. Die
dargestellte Tour verläuft vom Darmstädter Hofzentrum zur Erlöserkirche... 84
Abbildung 63: Modellgröße 1 (Auflösung: 800 * 600). ... 85
Abbildung 64: Modellgröße 2 (Auflösung: 800 * 600). ... 85
Abbildung 65: Modellgröße 3 (Auflösung: 240 * 320). Die Auflösung entspricht
dem Display eines tragbaren PDAs... 86
x
Tabellenverzeichnis
Tabelle 1: Vergleich der vorhandenen Datenquellen... 33
Tabelle 2: Vergleich zwischen Zellen- und Simplex-Modell ... 35
Tabelle 3: Export der Simplexe nach VRML... 64
1
1 Einführung und Konzeption
1.1 GIS und 3D-Visualisierung
Die Natur geographischer Daten ist im Grunde genommen dreidimensional, obwohl
sie konventionell in Form von Kartenblättern dargestellt und in zweidimensionalen
Geodatenbanken verwaltet werden. Karten können die Objekte der Realität nur un-
vollständig wiedergeben, da sie sich auf die Darstellung von Grundrissen beschränken.
Um einen Einblick in die räumlichen Lageverhältnisse und Beziehungen zwischen den
Kartenelementen zu erlangen, muss die symbolhafte Darstellung erst dekodiert wer-
den. Besonders bei der Erfassung des Reliefs, das im Allgemeinen durch Schattierung
und Isohypsen verdeutlicht wird, fällt dies schwer.
Daher ist seit Anfang der 1990er Jahre eines der dynamischsten Felder der räumlich
orientierten Informationswissenschaft die Entwicklung von 3D Geoinformationssys-
temen (GIS) [LaRa95]. 3D GIS erlauben in Verbindung mit Visualisierungstechniken
eine Sicht auf Geodaten, die der menschlichen Perspektive entspricht. Durch das Ein-
tauchen in dreidimensionale Umgebungen wird der Raum intuitiv erfasst. 3D GIS un-
terscheiden sich deutlich von den traditionellen zweidimensionalen GIS. Es müssen
sowohl neue Methoden für die Datenbeschaffung und verwaltung als auch neue Ver-
fahren für die Analyse entwickelt werden. Die Einsatzgebiete liegen v.a. in Stadtpla-
nung, Umweltplanung, Wissenschaftlicher Visualisierung und Ausbildung (und natür-
lich auch in Militärischen Simulationen) [BAKT00]. Digitale Repräsentationstechniken
sind z.B. wesentliche Hilfsmittel, um die Auswirkungen geplanter Projekte abschätzen
zu können.
Mit dem Themengebiet 3D GIS und Visualisierung städtischer Umgebungen beschäf-
tigen sich v.a. Köninger und Bartel [BBBK97, KöBa97, KöBa98], Verbree [VeVK98,
VVGJ99] und Kim [KiLL98, KLLH 98a, KLLH98b].
Systeme, bei denen der Schwerpunkt auf der Datenvisualisierung liegt, werden auch als
Virtual Reality GIS (VGIS) bezeichnet. ,,The concept of merging Geographical
Information Systems and Virtual Reality into Virtual Geographic Information Systems
(VGIS) has enjoyed increasing attention in the recent past" [BaKT00, 1]. Durch Tech-
niken wie Head-Mounted-Displays (HMD) oder CAVE wird dabei eine echte 3D-
Interaktion ermöglicht. Aus diesen Entwicklungen ist abzulesen, dass der Visualisie-
rung von Geodaten eine immer größere Bedeutung zugesprochen wird.
Ein großes Hindernis für die 3D-Visualisierung stellt jedoch die meist ungenügende
Datengrundlage dar. Die Erstellung detailgetreuer Modelle ist aufwendig und muss
mehr oder weniger manuell erfolgen. Solche Modelle werden bisher nur im Rahmen
2
1 Einführung und Konzeption
von Projektstudien erstellt und sind in der Regel nur für begrenzte Stadtgebiete ver-
fügbar. 3D-Daten benötigen zudem spezialisierte Datenbanken, die z.B. in den Stadt-
verwaltungen derzeit so noch nicht vorhanden sind.
Hingegen liegt mittlerweile eine Fülle von 2D-Geodaten in digitaler Form vor. Darun-
ter digitale Stadtkarten, Verkehrsnetze, Landnutzungsflächen, demographische Daten,
Umweltdaten, Satellitenbilder u.a. Es ist daher wünschenswert, auf bestehende 2D-
Daten, wie sie in GIS oft schon vorgehalten werden, zurückzugreifen und diese als
Datengrundlage für die 3D-Visualisierung zu nutzen.
Die zur Verfügung stehenden Geodaten unterscheiden sich nicht nur hinsichtlich ihrer
Dimensionalität, sie liegen auch in unterschiedlichen Formaten vor oder sind unter-
schiedlich georeferenziert. Um 2D Vermessungsdaten und 3D Stadtmodelle in einem
Virtual Reality System zu integrieren, müssen Konzepte für eine einheitliche Verwal-
tung der heterogenen Datenquellen und eine automatische Überführung der 2D Geo-
metrien in die dritte Dimension erarbeitet werden.
Konzepte für eine 3D-Visualisierung auf der Basis von 2D GIS wurden z.B. von Dod-
ge [DoJi97, DoSD97b, DoDo98] und Schilcher [ScRG98, SGKR98, SGKR99] erarbei-
tet.
Eine weitere Entwicklung, die sich zunehmend auch auf den GIS-Bereich auswirkt, ist
die wachsende Bedeutung des Internets. Wurde die Zahl der Internet-Nutzer noch
Anfang 1999 mit 171 Mio. angegeben, waren es im März 2000 bereits über 304 Mio.
Schätzungen belaufen sich auf über 1 Mrd. Nutzer im Jahr 2005 [USIT00]. Nicht nur
E-Commerce weist immer größere Umsätze auf; auch in den Bereichen Informations-
vermittlung und Bildung wird mittlerweile das Internet als immer wichtigeres Medium
angesehen. Speziell das World Wide Web (WWW) wird nicht nur für textuell vermittel-
te Informationen, sondern zunehmend auch als visuelle Schnittstelle für bildliche Dar-
stellungen und Animationen verwendet.
Die Idee, GI-Systeme für das Internet nutzbar zu machen, ist relativ jung. Sie bietet
jedoch großes Potential, geographische Informationen für ein breites Publikum zu-
gänglich zu machen und raumrelevante Fragestellungen näher zubringen. Bereits reali-
sierte, aus der Kombination von GIS- und Internettechnologien hervorgegangene Sys-
teme sind z.B. Stadtinformationssysteme, die eine Interaktion mit dynamisch generier-
ten Karten ermöglichen.
Ein wesentliches Manko ist jedoch die meist geringe Bandbreite. Die Standard-
Übertragungsrate reicht derzeit nicht aus, um die großen Datenmengen, die mit kom-
plexen 3D-Modellen verbunden sind, in akzeptabler Zeit zu übermitteln. Auch die
Graphikausgabe ist bei umfangreichen Modellen für eine flüssige Navigation schnell
überfordert. Daher sollte eine internetbasierte 3D-Visualisierung auch auf die Perfor-
manz des Endgeräts und die Internetanbindung Rücksicht nehmen.
1.2 Bisherige Entwicklungen internetbasierter 3D-GIS
3
1.2 Bisherige Entwicklungen internetbasierter 3D-GIS
Die Kombination von VR- und Internettechnologien bietet gerade für Stadtmarketing-
und Tourismusanwendungen die Möglichkeit, sich in graphisch ansprechender Form
zu präsentieren. In den letzten Jahren sind daher immer mehr ,,Virtuelle Städte" (,,vir-
tual cities", ,,cybertowns", ,,digital cities") aufgetaucht, die einen dreidimensionalen
Einblick in städtische Umgebungen ermöglichen sollen.
Meist handelt es sich dabei um statische 3D-Modelle der Stadtzentren oder ausgewähl-
ter Bereiche. Oft ist sogar eine weitergehende Interaktion möglich, indem weitere In-
formationen über Gebäude angezeigt werden können. Bisweilen kommen aber auch
Pseudo-3D-Techniken zum Einsatz. Ein Beispiel sind 360
°
-Panoramabilder, die aus
mehreren Fotos zusammengesetzt werden und die zwar einen hohen visuellen Realis-
mus bieten, aber keine Navigation erlauben [vgl. EvHu01]. Den wenigsten Konzepten
liegt jedoch ein GIS oder eine räumliche Datenbank zugrunde. Unter Zuhilfenahme
eines 3D-GIS können z.B. unterschiedliche Planszenarien in ein Stadtmodell eingebet-
tet werden und somit für die Stadtplanung als Hilfsmittel dienen.
[DDSF98] unterscheiden mehrere Typen von Virtuellen Städten im Internet:
a) Viele Websites bezeichnen sich als Virtuelle Städte, sind aber eigentlich herkömmli-
che Online-Führer für Kultur, Soziales, Shopping usw. Dabei spielt die Darstellung
der gebauten Umgebung kaum eine Rolle. Sie sind vielmehr als Informationsquelle
und Werbeplattform für Touristen konzipiert.
b) ,,Flache" Virtuelle Städte benutzen statische Abbildungen von Gebäuden und
Strassen, die als Menü für weitere Informationen dienen. Die Abbildungen sollen
einen dreidimensionalen Eindruck vermitteln, sind aber oft stilisiert.
c) Dreidimensionale Virtuelle Städte bestehen aus echten 3D-Modellen und nutzen
internetfähige VR-Technologien. In der Regel ist eine Navigation durch das Modell
und Erkundung der städtischen Umgebung möglich. Die Realitätsnähe ist unter-
schiedlich, je nach Größe des vorliegenden Gebiets und Aufwand der Erfassung.
Versuche, echte 3D GI-Systeme mit Internet-Technologien zu verbinden, unterneh-
men z.B. Coors [Coor97a, CoFl98, CoJu98, CoJK00] und Zlatanova [ZlGr98, Zlat99,
ZlTe99, Zlat00].
Von Coors [Coor97b] wurde ein 3D GIS entwickelt, dessen Datenbestand via Internet
bearbeitet werden kann. Der Schwerpunkt lag dabei auf der Architektur der Ser-
ver/Client Kommunikation in einer Multiuser-Umgebung. Dadurch können sich meh-
rere Anwender gleichzeitig am Server anmelden und sich Teile des Datenbestandes
herunterladen. Die Visualisierung und Manipulation erfolgt lokal auf dem Client-
Rechner. Um den zentralen Datenbestand konsistent zu halten, wurde ein eigenes Ü-
bertragungsprotokoll entwickelt. Wird ein Datensatz von einem Anwender verändert,
wird dies den anderen Anwendern mitgeteilt, so dass deren Darstellung aktuell bleibt.
4
1 Einführung und Konzeption
Abbildung 1: Benutzeroberfläche von Virtual Glasgow. Beispiel für eine Virtual City im Internet.
Das Protokoll unterstützt ebenfalls ein Levels-of-Detail Konzept und eine inkremen-
telle Übertragung der Darstellungsobjekte. Als Datenkomponente dient eine auf dem
Modell nach [Mole90] basierende und von [Flic98] veränderte dreidimensionale Geo-
metriebeschreibung. Die Geometrien werden über verschiedene Schnittstellen (Loader)
aus schon vorhandenen Dateien importiert. Darunter sind z.B. Schnittstellen für das
ODF-Format, für VRML und für ein Telekom-spezifisches Format. Zur Darstellung
auf der Client-Seite wird VRML verwendet.
Teile des Projektes, das in Java implementiert wurde, standen für diese Arbeit zur Ver-
fügung und konnten als Orientierung dienen. Insbesondere wurde der Loader für
ODF (vgl. Kapitel 2.2.4) und Teile für den Export nach VRML übernommen.
1.3 Zielsetzung und Anforderungen
Die vorgestellte Arbeit wurde im Rahmen des Projektes Deep Map [MaZi00] durchge-
führt, ein am European Media Laboratory (EML) entwickeltes Touristeninformations-
system (s. Kapitel 2.1). Für Deep Map wurden bereits Komponenten für den Zugriff
auf eine Excel-Datenbank, für die Berechnung von individuellen Tourenvorschlägen,
1.3 Zielsetzung und Anforderungen
5
für die Kartengenerierung und insbesondere ein Open GIS-konformer Geodatenserver
implementiert. Damit konnte bereits eine Benutzerschnittstelle realisiert werden, die
die 2D Geodaten in Form konventioneller Karten aufbereitet und präsentiert. Darüber
hinaus existieren aber auch mehrere 3D-Modelle in unterschiedlichen Formaten. Sogar
ein nicht umgesetztes Planszenario aus der Zeit des Nationalsozialismus wurde model-
liert.
Diese Arbeit versucht, über die zweidimensionale Präsentationsform hinauszugehen
und eine automatische Generierung von 3D-Ansichten zu ermöglichen. Für die 3D-
Visualisierung werden dabei nicht nur 3D-Modelle, sondern auch 2D-Daten aus dem
Geodatenserver für Gebiete, in denen keine 3D-Daten vorliegen, mit einbezogen.
Ein erstes Ziel ist es daher, die unterschiedlichen Geodaten so zu verwalten und zu
integrieren, dass ein gemeinsamer Zugriff für die eine 3D-Visualisierung möglich wird.
Hierzu müssen zweidimensionale Geodaten interpretiert und in die dritte Dimension
überführt werden. Die solchermaßen generierten ,,2,5D-Modelle" werden mit echten
3D-Modellen über einen Verschneidungsmechanismus fusioniert.
Wünschenswert ist hierbei ein möglichst großer Automatisierungsgrad. Insbesondere
muss auf die unterschiedlichen Datenquellen je nach Einsatzzweck dynamisch und
transparent zugegriffen werden können, um Virtual Reality Modelle zu erzeugen, die
z.B. interaktive 3D-Teilansichten eines Stadtmodells darstellen. Die 2D-
Geodateninfrastruktur sollte dabei möglichst unverändert bleiben, da in der Regel di-
verse Fachanwendungen auf diese zugreifen und bei wesentlichen Änderungen der
Geodaten möglicherweise Abstimmungsprobleme auftreten.
Besonderer Wert wird auch auf das Digitale Geländemodell (DGM) gelegt. Im Gegen-
satz zur 3D-Modellierung von Hand, bei der ein statisches DGM verwendet wird,
muss bei der dynamischen Visualisierung ein Konzept für die automatische Generie-
rung in Abhängigkeit von der Auswahl des Datenbestandes gefunden werden.
Das zweite Ziel ist die Anwendung der integrierten 2D- und 3D-Geodaten für die
dreidimensionale Tourenvisualisierung, die über das Internet zur Verfügung gestellt
werden soll. Die Tourenplanungskomponente berechnet Touren in Form einer Abfol-
ge von Routensegmenten, Abbiegeregeln und Haltepunkten. Das Ergebnis wird bisher
in Kartenform präsentiert. Die zu entwickelnden Komponenten sollen den Benutzer in
ein virtuelles, z.T. interaktives Modell eintauchen lassen und ihn entlang der Tour
durch das Modell führen. Somit kann bereits vor dem Aufenthalt in der Stadt ein Ein-
druck über die architektonische Charakteristik und die Atmosphäre gewonnen und der
Aufenthalt besser geplant werden.
Der Begriff ,,Virtual Reality" (VR) hat sich zum Modewort für alles, was irgendwie mit
dreidimensionaler Repräsentation zu tun hat, entwickelt. Unter VR soll hier eine
Visualisierung verstanden werden, die dem Benutzer das Gefühl vermittelt, in eine
realistisch simulierte Umgebung einzutauchen, um mit ihr ungezwungen und in
Echtzeit zu interagieren. Die 3 wichtigsten Anforderungen an ein VR System sind
Immersion, Interaktion und visueller Realismus [Shan98]. Das gebräuchlichste VR
System ist das Desktop-VR, das eine einfache monoskopische Projektion auf dem
Bildschirm erzeugt. Im Gegensatz zu HMDs oder ähnlichen Systemen erfordert es
6
1 Einführung und Konzeption
Gegensatz zu HMDs oder ähnlichen Systemen erfordert es keine zusätzliche Hardware
und funktioniert sowohl auf jedem Personal Computer als auch auf mobilen Geräten.
Die Komponenten sollen in das objektorientierte verteilte GIS Deep Map integriert
werden, so dass die schon existierenden Komponenten genutzt werden können. Als
Frontend dient ein Internet-Browser.
1.4 Konzeption eines Virtual Reality Servers
Bei der Konzeption eines Systems, das einen gemeinsamen Zugriff auf verschiedene
Datenquellen ermöglichen soll, kann zwischen zwei verschiedenen Strategien unter-
schieden werden [GaBe99]. Bei der ersten Strategie (federated database) verlässt sich
das System auf die Speicherung und Verwaltung der Daten in den Datenquellen. An-
fragen werden für die jeweiligen Datenquellen umgeformt und an diese weitergeleitet.
Die Antworten werden gesammelt und in Echtzeit zusammengeführt.
Bei der zweiten Strategie (warehouse system) werden alle verfügbaren Daten im Vor-
aus gesammelt und als zentraler Datenbestand gespeichert. Damit fällt der Verbin-
dungsaufbau zu den Datenquellen bei Anfragen weg und die Integration muss nicht
dynamisch erfolgen. Die Reaktionszeit ist vergleichsweise kurz. Allerdings fallen insbe-
sondere bei 3D-Geodaten große Datenmengen an, die im Speicher oder in einem ge-
eigneten Dateiformat vorgehalten werden müssen.
Abbildung 2: Grobkonzept eines Virtual Reality Servers für die Integration von 2D- und 3D-Geodaten.
Die Komponente, die für die Integration der Geodaten und für die Generierung von
3D-Modellen zuständig ist, wird im Folgenden als VRServer (Virtual Reality Server)
bezeichnet. Als Lösungsansatz verwendet der VRServer Schnittstellen zu den verschie-
denen 2D- und 3D-Geodatenquellen. Generell werden die Datenquellen dynamisch
angesprochen. Die Geodaten können (bzw. müssen z.T.) aber auch entweder als Roh-
VRServer
2D
Geodaten
3D
Geodaten
3D Web Browser
Internet
1.4 Konzeption eines Virtual Reality Servers
7
daten oder bereits integrierte Datensätze im Speicher vorgehalten werden.
Das Gesamtkonzept lässt sich in drei Komponenten zerlegen:
1) Datenkomponente
2) Managementkomponente
3) Visualisierungskomponente
Datenkomponente
Die Datenkomponente beschreibt eine objektorientierte Klassenbibliothek, die zur
internen Repräsentation der Geodaten dient und die bereits grundlegende Operationen
bzw. Methoden zur Manipulation bereithält. Die einzelnen Datenquellen weisen sehr
unterschiedliche Formate auf und die Beschreibung von Geometrie, Erscheinungsform
und Attributen variiert teilweise erheblich. Das Format kann objekt- oder textorientiert
sein, die Geometrie zwei- oder dreidimensional. Daher wurde von mir ein Java-Paket
implementiert, das die Repräsentation verschiedendimensionaler Geodaten aus unter-
schiedlichen Quellen durch eine einzige Klassenhierarchie erlaubt. Es dient der Mana-
gementkomponente als einheitliche Bezugsbasis zur Verwaltung.
Managementkomponente
In der Managementkomponente werden die Geodaten geladen, verwaltet, exportiert
und versendet. Sie ist in das bereits bestehende GIS Deep Map eingebunden, das ne-
ben traditionellen GIS-Funktionalitäten auch weitere Funktionalitäten wie den Zugriff
auf eine touristische Datenbank, Routenberechnungen, Benutzeradaption u.a. umfasst.
Die Komponenten werden als in sich geschlossene Module bzw. Agenten für Deep
Map zur Verfügung gestellt. Für die Umsetzung der in Kapitel 1.3 definierten Zielset-
zung werden zwei Agenten benötigt. Der VRServer-Agent steht mit dem eigentlichen
VRServer in Verbindung. Er nimmt räumliche Anfragen entgegen und generiert eine
geeignete 3D-Szene. Auf der anderen Seite steht ein Agent, der sowohl mit Deep Map
als auch mit dem WWW in Verbindung steht. Er konstruiert räumliche Anfragen zur
Routenvisualisierung für den VRServer und ist für die Übertragung des Ergebnisses
über das WWW an die auf dem Client befindliche Visualisierungskomponente verant-
wortlich.
Visualisierungskomponente
Die Visualisierungskomponente ist für die Visualisierung auf der Client-Seite und die
Interaktion mit dem Benutzer zuständig. Das Graphical User Interface (GUI) der Vi-
sualisierungskomponente besteht aus einem Applet und einem 3D-Browser. Das
Applet wird vollständig auf den Rechner des Client übertragen und präsentiert dem
Benutzer ein Feld für Benutzereingaben und Auswahlmöglichkeiten. Es kommuniziert
über das HTTP-Protokoll mit dem Servlet. Die 3D-Darstellung und Navigation wird
von einem VRML-Browser übernommen, dem die Szene vom Applet übergeben wird.
8
1 Einführung und Konzeption
Die Kriterien bei der Wahl der verwendeten Software und des Beschreibungsformats
waren v.a. Plattformunabhängigkeit und die Verwendung von Standardlösungen. Java-
Applets und VRML sind allgemein verbreitet und Software, die diese Standards unter-
stützt, ist frei verfügbar.
Bevor auf die einzelnen Aspekte der Implementierung des VRServers eingegangen
wird, sollen im nächsten Kapitel einige wichtige Grundlagen erläutert werden. Dazu
zählt zum einen die schon vorhandene Infrastruktur, die im Rahmen des Projektes
Deep Map entwickelt wurde und die auch bei dieser Arbeit genutzt werden konnte.
Viele der hier verwendeten Geodatensätze werden bereits bei Deep Map eingesetzt
oder wurden für das Projekt erstellt. Zum anderen sollen wichtige Technologien näher
betrachtet werden, die bei der Implementierung zum Einsatz kamen oder die für die
Integration und 3D-Visualisierung relevant sind.
9
2 Grundlagen für die Implementierung
2.1 Deep Map
Deep Map ist ein am European Media Laboratory (EML) in Heidelberg durchgeführ-
tes Forschungsprojekt, bei dem Erkenntnisse aus Computerwissenschaften, Geogra-
phie, Kunstgeschichte und weiterer Disziplinen einfließen [MaZi01]. Es hat die Ent-
wicklung eines mobilen elektronischen Touristeninformationssystems zum Ziel, das
mit dem Benutzer auf möglichst natürliche Weise kommuniziert. Deep Map soll dem
Benutzer die Orientierung und das Zurechtfinden in einer fremden Stadt erleichtern,
ihn mit Informationen über Geschichte, Gebäude und Personen versorgen, und ihm
Hilfestellung bei Stadtbesichtigungen in Form von berechneten Tourenvorschlägen
leisten. Dabei soll das System nicht nur auf persönliche Interessen und den kulturellen
Hintergrund Rücksicht nehmen, sondern auch eine intuitive Bedienung über Spracher-
kennung ermöglichen. Als Frontend dienen entweder Desktop PCs, die über das In-
ternet angesprochen werden oder tragbare Computer, die über wireless LAN (Local
Area Network) oder Mobilfunknetze in das System eingebunden werden.
Abbildung 3: Mobiler Prototyp von Deep
Map.
Der Kern des gesamten Systems ist ein Geographisches Informationssystem (GIS),
zusammen mit einer touristischen Datenbank. Das GIS ist nicht als monolithisches
System wie bei bisherigen kommerziellen Produkten ausgelegt, sondern als verteiltes
System. Das bedeutet, dass die Funktionalitäten auf einzelne Komponenten verteilt
sind, die leicht auszutauschen sind und die sich auf verschiedenen Rechnern innerhalb
10
2 Grundlagen für die Implementierung
eines Netzwerks befinden können. Die Komponenten werden Agenten genannt und
übernehmen Aufgaben wie Geodatenverwaltung, räumliche Abfragen, Tourenplanung,
Kartenvisualisierung und Datenbankabfragen. Die modulare Architektur erlaubt auch
eine relativ einfache Erweiterung der Dienste (so könnte z.B. ein Agent für Hotelreser-
vierungen eingebunden werden). Die Agenten sind weitgehend unabhängig und kom-
munizieren untereinander auf der Basis der von der FIPA (Foundation for Intelligent
Physical Agents) standardisierten Agentenkommunikationssprache ACL (Agent Com-
munication Language), indem einzelne Nachrichten ausgetauscht werden. Als gemein-
same Kommunikationsplattform dient die ebenfalls am EML entwickelte Middleware
RAJA (Resource Aware Java Agent Infrastructure), bei der die Agenten ihre Dienste
anmelden und über die sie Nachrichten austauschen. RAJA ist an eine hochgradig dy-
namische Umgebung angepasst und ermöglicht eine effektive Nutzung der vorhande-
nen Ressourcen [DiMa00]. RAJA löst das bisher am EML verwendete JAMFrame als
Middleware ab.
Im Rahmen von Deep Map wurden bisher die Agenten Info-Agent, Spatial-Agent,
Tour-Agent und Map-Agent entwickelt [ZHCM00], die im Folgenden kurz beschrie-
ben werden.
Info-Agent
Der Info-Agent ist für die Anbindung der touristisch-historischen Datenbank zustän-
dig. In der Datenbank sind Sachinformationen über historische Ereignisse, Personen,
Gebäude, Sehenswürdigkeiten und andere Objekte sowie Multimedia-Daten enthalten.
So können z.B. zu einem bestimmten Objekt Texte, Bilder und Verknüpfungen zu
weiteren damit zusammenhängenden Informationen geliefert werden.
Spatial-Agent
Der Spatial-Agent liefert die zweidimensionalen Basisdaten. Der Spatial-Agent ist so
ausgelegt, dass er als Client über CORBA eine Verbindung zu einem OpenGIS-
Geodatenserver herstellt und die Anfragen an diesen weiterleitet. Der Geodatenserver
verwaltet alle zweidimensionalen Daten und kann auch Operationen wie Sichtbarkeits-
analysen durchführen. Räumliche Abfragen liefern alle Objekte zurück, die sich inner-
halb einer Region befinden.
Tour-Agent
Der Tour-Agent ermittelt den Verlauf von Besichtigungstouren. Grundlage bildet da-
bei ein attributiertes Verkehrswegenetz. Der Verlauf entspricht der kürzesten Wegstre-
cke zwischen dem gewünschten Start- und dem Zielpunkt. Zusätzlich kann eine An-
zahl von Vias angegeben werden.
Map-Agent
Der Map-Agent erzeugt Karten eines bestimmten Ausschnitts für die Anzeige des
GUIs (Graphical User Interface). Dabei können auf Anfrage auch bestimmte Objekte
2.2 Verfügbare Geodatenquellen und Geodaten
11
hervorgehoben werden. Das Design kann sich hinsichtlich Symbolik und Beschriftung
an Standards verschiedener Länder orientieren. Das Ergebnis ist entweder eine Raster-
oder eine Vektorgraphik, die zum Endgerät übertragen wird.
2.2 Verfügbare Geodatenquellen und Geodaten
2.2.1 SDE
SDE (Spatial Database Engine) ist eine von ESRI entwickelte Datenbankerweiterung.
Sie dient dazu, räumliche Daten in einem relationalen Datenbanksystem (RDBMS) zu
speichern. SDE nutzt eine Client/Server Architektur, die es erlaubt, von jedem Rech-
ner innerhalb eines Netzwerks auf die räumlichen Daten zuzugreifen. Als Clients kön-
nen z.B. ESRI-Produkte wie ArcView, MapObjects oder Arc/INFO fungieren. Die
Verwaltung der Geodaten erfolgt somit nicht mehr durch lokale Dateien, sondern
zentral durch SDE. Damit wird ein erster Schritt weg von traditionellen monolithi-
schen hin zu verteilten GI-Systemen unternommen.
SDE kann jedoch nicht nur von ESRI Produkten verwendet werden. Es wird auch ein
Application Programming Interface (API) für C/C++ und Java zur Verfügung gestellt,
mit dessen Hilfe anwendungsspezifische Lösungen realisiert werden können.
Auf der Server-Seite befinden sich der SDE-Server, das RDBMS und die eigentlichen
Daten. Der SDE-Server übernimmt die räumlichen Such-Routinen und holt sich die
diejenigen Daten aus dem RDBMS, die den Suchkriterien entsprechen. Er ist über eine
IP erreichbar. Die Client-Anwendung beinhaltet die API (com.esri.sde.client), mit der
die Verbindung zum Server hergestellt wird und die Kommunikation vonstatten geht.
Es können mehrere Clients gleichzeitig auf SDE zugreifen. Die Clients können dabei
auf verschiedenen Plattformen laufen, da die Kommunikation durch das Netzwerk-
Protokoll standardisiert ist.
RDBMS speichern Daten in Tabellen, die aus Zeilen und Spalten bestehen. Abfragen
werden durch die weit verbreitete Structured Query Language (SQL) definiert. Eine
SQL Abfrage selektiert alle Einträge in einer Tabelle, die bestimmten Kriterien ent-
sprechen (Bsp.: selektiere alle Einträge, in denen im Feld a ein Wert kleiner als x steht).
Auf die selektierten Einträge kann daraufhin vom Client zugegriffen werden. Damit
sind jedoch keine räumlichen Abfragen möglich. Durch SDE können unter Verwen-
dung von Standard SQL auch räumliche Randbedingungen definiert werden.
SDE verändert nicht die RDBMS. Sie fügt lediglich bei bereits existierenden Tabellen
(Business Tables) eine Spalte für räumliche Elemente an. Die räumlichen Daten wer-
den dabei nicht in der Business Table selbst, sondern in SDE gespeichert. Die Ver-
knüpfung zwischen den in der Tabelle enthaltenen Sachinformationen und den Geo-
metrien wird über ID-Schlüssel hergestellt. Diese Verknüpfungen werden durch Layer
organisiert, die darüber hinaus Informationen über das Koordinatensystem, räumliche
12
2 Grundlagen für die Implementierung
Ausdehnung und weitere Beschreibungen enthalten. Layer repräsentieren Tabellen, die
räumliche Daten enthalten (Spatially Enabled Tables) [ESRI01].
Mit Hilfe von SDE und SQL-Abfragen können z.B. die folgenden Fragen beantwortet
werden:
·
welche Gebäude sind von einer bestimmten Straßenkreuzung aus bis zu 100 m ent-
fernt,
·
welche Gebäude befinden innerhalb einer definierten Fläche,
·
welche Parzellen gehören einem bestimmten Eigentümer.
Abbildung 4: Organisation der räumlichen Daten durch Tabellen in SDE.
SDE-Layer werden durch den Import von CAD- oder GIS-Daten erzeugt. Für das
Desktop GIS ArcView steht ein Werkzeug zur Verfügung, das in der Lage ist, Shape-
Dateien in SDE zu laden. Die ArcView Shape-Dateien sind daraufhin als Layer in SDE
enthalten.
In der Entwicklungsumgebung standen die folgenden Geodaten als ArcView Shape-
Dateien zur Verfügung und konnten in SDE integriert werden.
·
Eine Grundrisskarte aller Gebäude Heidelbergs, zur Verfügung gestellt vom Ver-
messungsamt Heidelberg. Sie enthält neben den Geometrien auch die Adressen der
Gebäude. Im Rahmen eines Projektseminars am Geographischen Institut wurden
außerdem die Stockwerkzahlen der meisten Gebäude durch eine Feldbegehung er-
mittelt. Dadurch konnten die Gebäudehöhen geschätzt werden. Diese Informatio-
nen flossen als Attribute in die Shape-Datei ein und sind für die Generierung von
3D-Blockmodellen von Bedeutung (siehe Kapitel 4.3.1).
·
Eine Punktekarte, in der die genaue Lage und Höhe aller Kanaldeckel verzeichnet
ist, zur Verfügung gestellt vom Vermessungsamt Heidelberg. Zusammen mit der
Digitalisierung einer Topographischen Karte ergeben sich daraus Höhenmesspunk-
2.2 Verfügbare Geodatenquellen und Geodaten
13
te flächendeckend sowohl für das bebaute als auch für das unbebaute Gebiet. Diese
Daten bilden die Grundlage für die Berechung eines digitalen Geländemodells. Die
Messpunkte wurden als 2D-Punkte in SDE geladen, wobei die Höhe als Attribut
angefügt wurde.
·
Aus diesem genauen DGM wurden in ArcView weitere gröbere DGM abgeleitet.
Aus den Messpunkten wurde zunächst eine Triangulation berechnet und dann ein
Raster darüber gelegt. An den Schnittpunkten des Rasters wurden die Höhen ge-
messen. Die abgeleiteten DGM werden also ebenfalls als Punktemenge, jedoch mit
konstanten Abständen zueinander, gespeichert.
·
Eine Punktekarte, die die Positionen der Bäume im Altstadtbereich enthält. Die
Positionen wurden aus einem Luftbild entnommen und als 2D-Punkte abgespei-
chert. Zusätzlich sind die Krondurchmesser als Attribut gespeichert.
·
Weitere Shape-Dateien, die während der Entwicklung des WebGIS Prototypen, ein
Projekt, das ebenfalls im Rahmen von Deep Map durchgeführt wurde [vgl. Jöst00
und Häuß99], entstanden. Diese enthalten u.a. Daten über
- Baublöcke,
- Waldflächen,
- Verlauf von Straßenseiten,
- Gewässer,
- Beschriftungen.
2.2.2 OpenGIS Geodatenserver
Es besteht mittlerweile ein unverkennbarer Trend, für die Verwaltung von Geodaten
einen zentralen Geodatenserver einzusetzen. Eine entscheidende Rolle spielt dabei das
OpenGIS Consortium (OGC), das für solche Dienste offene (standardisierte) Schnitt-
stellen entwickelt, mit dem Ziel, die Interoperabilität zu fördern [ZiAr01]. Für die Imp-
lementierung stellt das OGC die Simple Feature Specification (SFS) zur Verfügung. Bei
den meisten Anbietern von Geodatenservern kommen die Varianten der SFS für SQL
oder für COM zum Einsatz. Am EML wurde die dritte Spezifikation für CORBA mit
Hilfe von Java umgesetzt [Aras00]. CORBA bietet einen durchgehend objektorientier-
ten Ansatz und ist für die Anwendung in einem verteilten GIS prädestiniert. Der
Zugriff auf die Geodaten entspricht einem Methodenaufruf entfernter Objekte, wobei
der Object Request Broker (ORB) die Zugriffe kontrolliert. Ähnlich wie bei SDE er-
folgt die Anbindung an den Geodatenserver durch Clients, in diesem Fall CORBA-
Clients. Die CORBA-Technolgie erlaubt die gleichzeitige Anbindung mehrerer Clients.
Die Basis der Implementierung bildet eine SDE-Datenbank. Somit sind durch den
OpenGIS Geodatenserver prinzipiell die gleichen Daten verfügbar wie unter Kapitel
2.2.1 angesprochen.
14
2 Grundlagen für die Implementierung
2.2.3 3D/4D Datenbank
Mit dem Aufkommen von 3D GI-Systemen hat sich auch das Interesse an einer Da-
tenbank für dreidimensionale Geodaten verstärkt. Solche 3D-Datenbank Management
Systeme (3D DBMS) befinden sich jedoch erst in der Entwicklung. Mit der Arbeit von
Krüger [Krüg00] steht sogar bereits ein Framework für die Abbildung der temporalen
Komponente bereit. 3D-Datenbanken, die zusätzlich zu den geometrischen Eigen-
schaften auch die Zeit erfassen, werden als 4D DBMS bezeichnet. Am EML wird in
Zusammenarbeit mit dem Fraunhofer-Institut für Graphische Datenverarbeitung
(IGD) Darmstadt ein 4D DBMS entwickelt. Es basiert auf der relationalen Datenbank
Cloudscape. Die Abfragen werden durch eine Erweiterung von SQL vorgenommen
(4D-SQL), mit der sowohl geometrische als auch temporale Bedingungen formuliert
werden können. Zur Zeit der Entstehung dieser Arbeit stand das 4D DBMS noch
nicht zur Verfügung.
2.2.4 ODF-Modell
Von der Heidelberger Altstadt liegt ein 3D-Modell im ODF-Format vor. Das Modell
wurde vom Institut für Photogrammetrie (IfP) der Universität Stuttgart erstellt. Dabei
kam ein vom IfP entwickeltes Verfahren zum Einsatz, das eine weitgehend automati-
sche Generierung von Stadtmodellen ermöglicht [BrHa00]. Die Datengrundlage bilden
ein Digitales Höhenmodell (DHM) und eine digitale Katasterkarte, die die Grundrisse
der Gebäude enthält. Das DHM wurde durch einen flugzeuggetragenen Laserscanner
erfasst. Es besteht aus Messpunkten mit einem Abstand von ca. 1 m. Aus dem DHM
wird durch automatische Interpretationsmechanismen ein Polyeder-Modell, also ein
Modell mit planaren Facetten der Gebäudeflächen, erzeugt.
Abbildung 5: Rekonstruiertes Gebäude. Links Randdarstellung, rechts zusammen mit DHM [Quelle:
BrHa00].
2.2 Verfügbare Geodatenquellen und Geodaten
15
Die Grundrisse dienen dabei als Interpretationshilfe, um die Gebäude von der Gelän-
deoberfläche zu trennen und die Orientierung der Wände zu ermitteln. Die Gebäude
werden zunächst aus 3D-Primitiven wie z.B. Quader, die sich am Grundriss orientie-
ren, aufgebaut. Bei der Rekonstruktion der Dächer kommt Vorwissen über mögliche
vorkommende Dachformen (Flach-, Giebel- oder Walmdach) zum Tragen. Anschlie-
ßend werden die 3D-Primitive zu einem Modell, das nur noch aus den Randflächen
besteht (Boundary Representation, vgl. Kapitel 3.1.1.1), vereinigt.
Abbildung 6: 3D-Modell der Heidelberger Altstadt.
Das Modell wurde als ODF-Datei gespeichert. ODF ist ein textbasiertes Beschrei-
bungsformat. Die Geometrien werden als Constructive Solid Geometry (CSG) oder
Boundary Representation (B-Rep) beschrieben. Im vorliegenden Modell wurde beides
gespeichert. CSG und B-Rep repräsentieren dabei aber die gleichen Objekte, so dass
nur auf B-Rep zurückgegriffen wurde. Um von einem GIS als Geodatenquelle verwen-
det werden zu können, müssen die Daten in den Speicher geladen werden. Die Datei
muss in einzelne Objekte aufgelöst und in ein internes Format überführt werden.
2.2.5 VRML-Modelle
Von einem Teil der Gebäude im Altstadtbereich wurden terrestrische Fotos der Fassa-
den aufgenommen. Zusammen mit dem ODF-Modell, das keinerlei Farbinformatio-
nen enthält, konnten daraus texturierte 3D-Modelle erstellt werden. Das ODF-Modell
wurde hierfür in das 3D-Modellierungsprogramm Studio 3D Max geladen und überar-
beitet. Bevor die Fotos auf die Fassadenflächen gelegt werden können, müssen sie ent-
zerrt werden, um perspektivische Fehler durch Blickwinkel und Brennweite der Kame-
ra auszugleichen. Obwohl die Geometrie nicht verändert wird, machen solchermaßen
Ende der Leseprobe aus 107 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2002, Integration und Visualisierung von 2D- und 3D-Geodaten in einem verteilten GIS am Beispiel virtueller Stadttouren, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/220958
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare