3D-Geo-Informationssystem

3D-Geo-Informationssystem
Entwicklung eines Informationssystems basierend auf
3D-Geometriedaten von Darmstadt
Studienarbeit
vorgelegt von
Patrick Gentzcke
Institut für Computervisualistik Fraunhofer IGD, Darmstadt
AG Computergrafik
Abt. Graphische Informationssysteme
Betreuer: Dipl.-Ing. Daniel Holweg, Fraunhofer IGD
Prüfer: Prof. Dr. Stefan Müller, Universität Koblenz
Oktober 2003
Inhaltsverzeichnis
1
Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Geographische Informationssysteme
2.1 Was ist ein Geographisches Informationssystem?
2.2 Die Vier Komponenten eines GIS . . . . . . . .
2.2.1 Dateneingabe . . . . . . . . . . . . . . .
2.2.2 Datenverwaltung . . . . . . . . . . . . .
2.2.3 Analyse . . . . . . . . . . . . . . . . . .
2.2.4 Präsentation . . . . . . . . . . . . . . . .
2.3 Datentypen eines GIS . . . . . . . . . . . . . . .
2.3.1 Geometriedaten . . . . . . . . . . . . . .
2.3.2 Sachdaten . . . . . . . . . . . . . . . . .
2.3.3 Metadaten . . . . . . . . . . . . . . . . .
2.4 GIS Typen . . . . . . . . . . . . . . . . . . . . .
2.4.1 Landinformationssystem . . . . . . . . .
2.4.2 Rauminformationssystem . . . . . . . .
2.4.3 Umweltinformationssystem . . . . . . .
2.4.4 Netzinformationssystem . . . . . . . . .
2.4.5 Fachinformationssystem . . . . . . . . .
2.5 Koordinatensysteme . . . . . . . . . . . . . . . .
2.5.1 Gauß-Krüger Koordinaten . . . . . . . .
2.5.2 3D-Koordinatensystem . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
9
10
10
10
11
11
12
12
13
13
13
14
14
14
14
14
15
Techniken und Werkzeuge
3.1 HTML . . . . . . . . .
3.2 XML . . . . . . . . .
3.3 Java . . . . . . . . . .
3.4 Oracle . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
17
17
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
2
INHALTSVERZEICHNIS
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
19
19
20
In 3D-Cityviewer
4.1 Datenbank . . . . . . . . . . . . . . . . . . .
4.2 Aufbau einer relationalen Datenbank . . . . .
4.3 Bestehende Datenbank . . . . . . . . . . . .
4.3.1 Body . . . . . . . . . . . . . . . . .
4.3.2 Face . . . . . . . . . . . . . . . . . .
4.3.3 Node . . . . . . . . . . . . . . . . .
4.3.4 Surface . . . . . . . . . . . . . . . .
4.3.5 Surfacetype . . . . . . . . . . . . .
4.4 Datenbankerweiterung . . . . . . . . . . . .
4.4.1 Konzeption . . . . . . . . . . . . . .
4.4.2 Category . . . . . . . . . . . . . . .
4.4.3 Building . . . . . . . . . . . . . . .
4.4.4 Adress . . . . . . . . . . . . . . . .
4.4.5 Bakery . . . . . . . . . . . . . . . .
4.4.6 Hotel . . . . . . . . . . . . . . . . .
4.5 Datenbankerweiterung mittels Java und SQL .
4.5.1 Verbindung zur Datenbank herstellen
4.5.2 Datenaustausch . . . . . . . . . . . .
4.5.3 Verbindung beenden . . . . . . . . .
4.6 Inhalt der Datenbank . . . . . . . . . . . . .
4.6.1 Mapping . . . . . . . . . . . . . . .
4.7 Applet . . . . . . . . . . . . . . . . . . . . .
4.7.1 Klassen und Funktionsbeschreibung .
4.7.2 Erweiterung . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
22
24
24
25
26
26
27
27
27
28
28
29
29
30
30
30
32
33
34
34
36
36
40
3.5
3.6
4
5
3.4.1 Datenbank Beschreibung . . . . .
SQL . . . . . . . . . . . . . . . . . . . .
TOMCAT . . . . . . . . . . . . . . . . .
3.6.1 Beschreibung . . . . . . . . . . .
3.6.2 Die TOMCAT Verzeichnisstruktur
Fazit und Ausblick
.
.
.
.
.
42
A Installation des Oracle Treibers
44
B Installation von TOMCAT
45
C Verzeichnisstruktur
47
Abbildungsverzeichnis
2.1
Gauß-Krüger Koordinaten . . . . . . . . . . . . . . . . . . . . .
15
4.1
4.2
4.3
4.4
4.5
2D Luftbild . . . . . . . . . . . . . . . . . . . .
3D Bild des selektierten 2D Ausschnittes . . . .
Übersicht der Beziehungen . . . . . . . . . . . .
Gelbe Seiten - Auswahl eines Hotels . . . . . . .
Stadtplan von Darmstadt mit selektiertem Bereich
.
.
.
.
.
22
23
24
34
35
B.1 Umgebungsvariablen unter WinXP . . . . . . . . . . . . . . . . .
46
C.1 Verzeichnisstruktur In 3D-Cityviewer . . . . . . . . . . . . . . .
47
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Tabellenverzeichnis
3.1
TOMCAT Verzeichnisstruktur . . . . . . . . . . . . . . . . . . .
20
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
Struktur der Tabelle body . . .
Struktur der Tabelle face . . . .
Struktur der Tabelle node . . . .
Struktur der Tabelle surface . . .
Struktur der Tabelle surfacetype
Konzept der DB-Objekte . . . .
Struktur der Tabelle category . .
Beispieldatensatz category . . .
Struktur der Tabelle building . .
Beispieldatensatz building . . .
Struktur der Tabelle adress . . .
Beispieldatensatz adress . . . .
Struktur der Tabelle zipcode . .
Beispieldatensatz zipcode . . . .
Struktur der Tabelle bakery . . .
Struktur der Tabelle hotel . . . .
25
26
26
26
27
27
28
28
29
29
29
30
30
31
31
32
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Kapitel 1
Einleitung
1.1
Motivation
In letzter Zeit gewinnen Geografische Informationssysteme (GIS), basierend auf
dreidimensionalen Daten, immer mehr an Bedeutung, da die seit Jahren betriebene
Stadtplanung mittels Architekturmodellen und komplexen Plänen sehr aufwendig
ist und für manche Zwecke nicht ausreicht.
Zusammen mit dem Internet stellen sie ein gewaltiges Marktpotential dar und werden für weitreichende Veränderungen innerhalb der verschiedenen Anwendungsrichtungen von Geo-Informationssystemen sorgen.
Geo-Informationssysteme tragen zur Verbesserung der Analyse der Daten bei,
da herkömmliche Methoden nicht so flexibel mit 3D-Datenbeständen umgehen
können. Die integrierte Datenhaltung wird das Treffen von Entscheidungen erleichtern und beschleunigen. Unter einem digitalen 3D-Stadtmodell ist ein 3DComputermodell einer Stadt zu verstehen. In diesem Modell sollen die Objekte (Gebäude, Vegetation, Mauern, Verkehrs- und Wasserwege, usw.) der Stadt
möglichst realitätsnah abgebildet werden. Zu jedem Objekt werden die Informationen gespeichert, die für eine räumliche Rekonstruktion erforderlich sind [LORBER]. Für alle Objekte müssen so viele Informationen vorhanden sein, dass sie
stets als 3D-Objekte dargestellt werden können.
Die Daten, die bei so großen Geo-Informationssystemen anfallen, werden immer
umfangreicher. Da nicht nur der Speicherplatz begrenzt ist sondern auch die Bandbreite bei der Übertragung, muss eine ressourcenschonende Methode gefunden
werden, auf die Daten zuzugreifen und sie zu speichern. Eine Datenbank scheint
dafür sehr geeignet. Bei der Übertragung auf das Endgerät sollten nur die Objekte
ausgewählt werden, die für die momentane Anzeige relevant sind. Dies ist besonders wichtig, wenn mobile Endgeräte wie ein PDA verwendet werden, da hier die
Hardwareressourcen und die Bandbreite besonders begrenzt sind.
5
KAPITEL 1. EINLEITUNG
6
In dieser Arbeit sind vor allem Abfragen zu Eigenschaften von bestimmten Objekten relevant. Ein Bewohner der Stadt Darmstadt sollte die Möglichkeit haben,
sich alle Bäckereien anzeigen zulassen, die in einem bestimmten Umkreis von
seinem Standort liegen.
Beispielsweise könnte bei Geschäftsleuten oder Touristen folgende Abfrage
von Interesse sein: Zeige alle Hotels in Darmstadt mit mindestens vier Sternen
”
und einem freien Einzelzimmer“. Weiterhin wäre vorstellbar, dass alle Metzgereien, die auf einer bestimmten Strecke liegen erfragt werden. Zum Beispiel könnte
man sich alle Metzgereien zwischen dem Darmstädter Schloss und dem Fraunhofer Institut anzeigen lassen. Hierfür sind topologische Abfragen notwendig.
Die Verwendung von mobilen Endgeräten wie PDAs oder anderer Begleiter wird
zwar auf eine mobile GIS Lösung beschränkt sein, da ein vollständiges GIS viel
zu komplex wäre. Dies führt zu einer Spezialisierung der Anwendung auf den Benutzer. So könnten sich Touristen beispielsweise den Plan ihrer besuchten Stadt
sowie sämtliche Sehenswürdigkeiten auf Ihren mobilen Begleiter übertragen. Damit wären sie nur mit den für sie relevanten Informationen versorgt. Idealerweise verfügen die mobilen Endgeräte noch über einen GPS Empfänger und können
dem Benutzer somit immer eine exakte Standtortbestimmung geben. Mittels Standortangabe ist eine Navigation des Benutzes möglich (Location based Service).
1.2
Ziele der Arbeit
Ziel der Arbeit ist es, basierend auf dem 3D-Stadtmodell von Darmstadt ein Informationssystem mit Zugriffsmöglichkeit für mobile Engeräte (z.B. PDA) aufzubauen. Hierzu muss die vorhandene Geometriedatenbank um einen Sachdatenteil/Kategorien erweitert werden und beispielhaft mit Daten gefüllt werden.
Ausgehend von dieser Situation wird ein browserbasiertes Informationssystem erstellt, das dem Benutzer einfache Abfragen der Datenbank erlaubt und die Ergebnisse in Form einer 3D-Karte darstellt. Die 3D-Geometrien soll sich hierbei auf
ein sinnvolles Minimum beschränken.
1.3
Aufbau der Arbeit
Die Arbeit ist in fünf Kapitel gegliedert. Nach dem ersten einleitenden Kapitel
wird im zweiten Kapitel der Begriff des Geo-Informationssystems aufgegriffen.
Hier wird erläutert, wie ein Geo-Informationssystem definiert wird und aus welchen Teilen es besteht. Dies ist notwendig um die Techniken und Methoden dieser
Studienarbeit zu verstehen.
Im dritten Kapitel werden die grundlegenden Hilfsmittel vorgestellt mit denen
KAPITEL 1. EINLEITUNG
7
diese Studienarbeit entwickelt wurde. Zum einem werden die verwendeten Programmiersprachen vorgestellt und zum anderen wird die verwendete Datenbank
sowie den Webserver, der für den Betrieb auf einem PC erforderlich ist, beschrieben.
Das vierte Kapitel beschäftigt sich mit dem bereits vorhandenen geographischen
Informationssystem. Zuerst wird auf die bestehende Datenbank eingegangen. Es
werden Struktur und Funktionsweise erklärt. Ferner wird die Erweiterung der bestehenden Datenbank erläutert, und es wird die Verbindung zur bestehenden Datenbank aufgezeigt. Die Datenbank wurde um einen Sachdatenanteil ergänzt. Im
Unterpunkt Datenbankinhalt wird erläutert, wie das Mapping Verfahren zur inhaltlichen Ergänzung der Datenbank funktioniert. Im nächsten Abschnitt werden
die bestehenden Klassen des geographischen Informationssystem erklärt. Danach
werden die Erweiterungen in den entsprechenden Klassen gezeigt
Abschließend werden im fünften Kapitel die Ergebnisse dieser Arbeit zusammengefasst und es wird ein Ausblick gegeben.
Zur Terminologie: Bei der Beschreibung der verschiedenen Inhalte stellte sich
immer wieder die Frage, wie die korrekten Übersetzungen der englischen Originalbegriffe lauten. Einige Begriffe können dabei eindeutig übersetzt werden,
während dies bei anderen kaum, wenn überhaupt, möglich ist. Aus diesem Grund
werden neben den deutschen Bezeichnungen auch die englischen angegeben. Der
Einfachheit halber wird in dieser Arbeit nur von Anwendern, Benutzern usw. gesprochen, obwohl selbstverständlich auch immer die Anwenderrinnen und Benutzerinnen dabei mit gemeint und angesprochen werden.
Kapitel 2
Geographische Informationssysteme
2.1
Was ist ein Geographisches Informationssystem?
Ursprünglich stammt die Abkürzung GIS aus dem englischsprachigen Raum und
steht dort für Geographic Information System, was zur deutschen Version von
Geographische Informationssysteme führte. Jedoch hat der Begriff GIS zunächst
nicht unmittelbar etwas mit Geographie zu tun. Das Adjektiv geographisch“ steht
”
lediglich für die räumliche Zuordnung eines Objekts zu einem bestimmten Punkt
auf der Erde. Deshalb hat sich innerhalb der deutschen Sprache die neutrale Version Geo-Informationssysteme etabliert.
Anhand des folgenden Beispiels kann man sich den Begriff GIS recht einfach veranschaulichen. Eine jedem bekannte Datensammlung ist das Telefonbuch, welches man als Informationssystem (IS) bezeichnen kann. Darin findet man die Namen der Fernsprechteilnehmer und die ihnen zugeordnete Telefonnummer. Natürlich muss dem ganzen eine Ordnung zu Grunde liegen, damit in dieser Datensammlung etwas wieder gefunden werden kann. Es erfolgt eine Einteilung in
Vorwahlbereiche. Innerhlab der Vorwahlbereiche werden die Teilnehmer alphabetisch nach Namen sortiert. Zusammenfassend könnte man also ein IS folgend
beschreiben:
Ein IS ist eine Sammlung von Informationen oder Daten zu einer vorgegebenen
Thematik, die aufgrund eines eindeutigen Ordnungsschemas dem Benutzer einen
schnellen, gezielten Zugriff gestattet. Man nimmt nun bei diesem IS eine Erweiterung vor. Man erweitert den Datenbestand dahingehend, dass jedem Teilnehmer ein Koordinatenpaar bzw Tripel, z.B. geographische Länge und Breite seines
Wohnhauses, zugeordnet wird. Damit hat man dem IS einen räumlichen Aspekt
gegeben. Somit sind nun folgende Abfragen möglich: Zeige mir alle Teilnehmer
”
mit dem Eintrag Steuerberater und stelle das Ergebnis in einer Karte dar“. Auf
diese Weise hat man ein erstes Beispiel für ein Geo-Informationssystem. Zusam-
8
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
9
mengefasst: Sind die Informationen zusätzlich mit Koordinaten versehenund es
sind auch räumliche Abfragen möglich sind, dann spricht man von einem GeoInformationssystem kurz GIS [Linder]. Die Definition von Bill verdeutlicht diese
Aussage:
Ein Geo-Informationssystem ist ein rechnergestütztes System, das aus Hard”
ware, Software, Daten und den Anwendungen besteht. Mit ihm können raumbezogene Daten digital erfasst und redigiert, gespeichert und reorganisiert werden,
modelliert und analysiert sowie alphanumerisch und graphisch präsentiert werden [Bill].“
2.2
Die Vier Komponenten eines GIS
Aus der oben genannten Definition eines GIS nach [Bill] gehen vier unverzichtbare Bestandteile eines GIS hervor: Hardware, Software, Daten und Anwender. Am
wichtigsten sind jedoch die Daten. Die Beschaffung, Aufbereitung und Pflege der
Daten ist die mit Abstand arbeitsaufwendigste und kostenträchtigste Komponente
des Systems.
An die Komponenten der Hard- und Software sind gewisse Anforderungen zu
richten. Für die Hardware ist aufgrund großer Datenmengen bei Grafikverarbeitung generell eine hohe Rechenleistung sowie vor allem ausreichend Arbeits- und
Festplattenspeicher notwendig. Innerhalb großer Vorhaben mit mehreren Bearbeitern ist eine vernetzte Architektur mit zentralem Datenbestand und mehreren
graphischen Arbeitsstationen sinnvoll. Auf der Software Seite gibt es mittlerweile
ein fast unübersehbares Angebot. Bei der Auswahl sind vor allem die konkreten
Bedürfnisse des Anwenders, aber auch die Möglichkeiten des Datenaustausches
mit Partnern und nicht zuletzt die Vertrauenswürdigkeit des Anbieters im Hinblick
auf langfristige Softwarepflege zu berücksichtigen.
Die Software gliedert sich in vier Module, die nachfolgend dargestellt werden und
das Vierkomponenten-Modell der Aufgaben bilden:
2.2.1
Dateneingabe
Für die Eingabe von Daten bei GIS gibt es eine Vielzahl von Möglichkeiten. Einerseits kann eine Eingabe über die Tastatur zur Gewinnung der Daten dienen.
Andererseits erfolgt die Erfassung von raumbezogenen Daten über verschiedene
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
10
Methoden der Geodäsie1 : Tachymetrie2 , Punktaufnahme, Photogrammetrie3 und
Fernerkundung. Es ist aber auch ein Digitalisieren und Scannen vorhandener analoger Karten möglich. Ein wichtiger Teil der Datenerfassung ist der Datenaustausch von Geometrie- und Sachdaten mit anderen Geo-Informationssystemen.
2.2.2
Datenverwaltung
Da die Daten in einem GIS digital gespeichert werden, ist eine interaktive Manipulation sehr einfach. Das Datenvolumen und die geforderte Zugriffsgeschwindigkeit entscheiden jeweils über die geeigneten Datentypen (Vektor-, Raster- und
Sachdaten).
Der Hauptteil der Software für die Verwaltung von Daten bildet die Datenbank
mit dem Datenbankmanagementsystem. Für die Datenbank kommen hierarchische, netzwerkartige, relationale oder objektorientierte Modelle zum Einsatz.
2.2.3
Analyse
Geo-Informationssysteme bieten vielfältige Arten der Datenanalyse an. Die Analyse dient der Gewinnung neuer Informationen und erleichtert somit die Erstellung
von Entscheidungsgrundlagen. Die Methoden reichen von der geometrischen, logischen und relationalen Verknüpfung der Daten bis hin zu statistischen Analysen.
Hierzu zählen unter anderem das Anzeigen von Geometriedaten am Bildschirm
mit der Möglichkeit für interaktive Abfrage- und Messmöglichkeiten. Genauso
ist eine Analyse von Sachdaten sowie eine kombinierte Analyse von Sach- und
Geometriedaten möglich. Momentan werden hauptsächlich relationale Modelle
verwendet, jedoch sind objektorientierte Modelle zukunftsträchtig.
2.2.4
Präsentation
Die Ausgabekomponente eines GIS ist der wichtigste Teilaspekt, da die Visualisierung der Ergebnisse unter anderem große Vorteile gegenüber der Darstellung mittels Zahlen besitzt. Dadurch wird die Akzeptanz des GIS beim Benutzer erhöht. Neben der Anzeige auf dem Bildschirm, stehen im GIS noch weitere
1
Die Lehre von der Ausmessung größerer oder kleinerer Teile der Erdoberfläche und ihrer
Darstellung in Verzeichnissen, Karten, Plänen und Informationssystemen.
2
Sammelbegriff für die Messungsmethoden, mit denen sich eine Geländeaufnahme nach
Grundriss und Höhe schnell und mit der für die Kartierung im gewünschten Maßstab erforderlichen Genauigkeit durchführen lässt.
3
Sie befasst sich mit der Gewinnung und Verarbeitung von Informationen über Objekte und
Vorgänge mittels Bildern, schwerpunktmäßig mit Bestimmung der Form, Größe und Lage von
Objekten im Raum, vorzugsweise mittels photographischer Bilder als Informationsspeicher.
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
11
Möglichkeiten der Datenpräsentation zur Verfügung:
• graphische Aufbereitung der Geometriedaten
• Ausgabe über den Drucker
• Präsentation und Visualisierung durch das Internet
2.3
Datentypen eines GIS
In einem GIS werden raumbezogene Sachdaten verarbeitet. Es handelt sich hierbei folglich um Informationen, die anhand von Koordinaten lokalisiert werden. Da
der Datenumfang sowohl in räumlicher als auch in sachlicher Betrachtungsweise
sehr unterschiedlich sein kann, ist es sinnvoll, GIS Datentypen für eine ideale
Speicherung festzulegen.
2.3.1
Geometriedaten
Rasterdaten
Rasterdaten bezeichnen eine Art geometrischer Verwaltung raumbezogener Objekte. Dabei liegen die Daten in Matrixform vor. Die kleinste Einheit jedes Rasterbildes ist der Bildpunkt. Jedem Bildpunkt/Pixel ist ein Farb- bzw Grauwert
zugeordnet. Rasterdaten entstehen durch einscannen analoger Pläne, Luftbilder
usw. oder direkt durch laden digitaler Bilder in den Computer. Dies sind dann
meist durch Digitalkameras erstellte Bilder bzw. Satellitenfotos. Durch Koordinatentransformationen kann das Rasterbild z.B. mit geographischen Koordinaten in
Beziehung gesetzt werden.
In Rasterdaten können in der Regel keine Sachendaten hinterlegt werden, da das
einzelne Pixel einer Linie oder Polygon nicht weiß“, dass es Teil einer Straße
”
oder Sees ist.
Im Gegensatz zu Vektordaten belegen Rasterdaten (besonders in unkomprimiertem Zustand) einen sehr viel höheren Speicherplatz, da auch für Flächen ohne geometrische Informationen Bildinformationen gespeichert werden müssen. Daher
benötigen hochauflösende Karten sehr viel Speicherplatz. Durch Komprimierung
der Daten wird der Speicherplatzbedarf teilweise erheblich gesenkt. Abhängig von
der Karte und der Komprimierungsrate kann die Ersparnis zwischen 30 und 70
Prozent liegen. Trotz dieser Ersparnis ist bei der Anwendung dieser Karten mit
einem GIS-Programm ein hoher Rechenaufwand erforderlich.
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
12
Vektordaten
Die Grundelemente von Vektordaten sind Punkte, Linien und Polygone. Die Darstellung von geographischen Objekten wird durch kartesische Koordinaten bewerkstelligt. Dies kann eine einzelne Koordinate für einen Einzelpunkt oder Koordinaten für den Start- und Endpunkt einer Linie sein. Linienobjekte werden
als eine angeordnete Reihe von XY-Koordinaten aufgezeichnet. Polygone werden
durch einen geschlossenen Linienzug realisiert. Daher ist eine einfache logische
Ordnung innerhalb einer Datenbank möglich.
Im Gegensatz zu Rasterdaten können Vektordaten sinnvoll mit Sachdaten verknüpft werden, da die durch Vektordaten erstellten Objekte wissen“, was für ein
”
Objekt sie sind. Hoch entwickelte Vektordatenmodelle schließen topologische Beziehungen mit ein.
Moderne GIS-Programme arbeiten ausschließlich mit Vektordaten. Rasterdaten
dienen hier meist nur noch als ergänzende Informationen. Dies hat verschiedene Gründe: Bei Vektordaten können sehr einfach Sachdaten hinterlegt werden.
Dies wird auch ein Schwerpunkt dieser Arbeit sein, worauf in Kapitel 4.4.1 näher
eingegangen wird. Ein weiterer Vorteil ist, dass Vektordaten im Vergleich zu Rasterdaten wesentlich weniger Speicherplatz benötigen. Dies resultiert daraus, dass
für Vektorobjekte nicht mehr viele Pixel abgespeichert werden müssen, sondern
nur einzelne Koordinaten.
2.3.2
Sachdaten
Neben den Geometriedaten sind eine ganze Reihe von Informationen vorstellbar,
die nicht geometrischer Art sind, aber dennoch einen Raumbezug haben und so
einer Geometrie zugeordnet werden können. Diese beschreibenden Daten werden auch Sachendaten genannt. Sie geben den thematischen Inhalt raumbezogener Objekte wieder und repräsentieren Elemente wie Texte, Zahlensammlungen,
Messwerte, Namen oder Eigenschaften. Sachdaten bezeichnen Attribute thematischer oder alphanumerischer Daten. Diese Art von Daten legt man häufig in
relationalen Datenbanken ab und somit sind statistische Auswertungen sehr leicht
möglich. Innerhalb des Datenbankprogrammes werden Sachdaten mit einer geometrischen Information versehen und damit für das GIS zugänglich gemacht.
2.3.3
Metadaten
Die griechische Vorsilbe meta“ bedeutet soviel wie inmitten, zwischen, hinter,
”
nach. Unter Metadaten ( Daten über Daten“) versteht man strukturierte Infor”
mationen, mit deren Hilfe eine Informationsressource beschrieben und dadurch
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
13
besser auffindbar gemacht wird. Der effektive Einsatz von Metadaten setzt einen
gewissen Standardisierungsgrad und somit Maschinenlesbarkeit voraus.
Grundsätzlich kann der Aufbau von Metadaten bei den verschiedenen Anwendungsbereichen variieren. Der Aufbau von Metadaten in reinen Datenbanken kann
sich dabei erheblich von Sachdatenbeständen in GIS-Programmen unterscheiden.
Metadaten sollten erweiterbar und selbsterklärend sein. Erweiterbar deswegen,
weil das Wachstum der Datenbestände in näherer Zukunft enorm sein wird. Dies
geschieht bei gleichzeitig immer geringer werdender Abhängigkeiten von einem
bestimmten, proprietären GIS-System. Des Weiteren sollten Metadaten selbsterklärend sein, da sonst wiederum Metadaten für die vorhandenen Metadaten
benötigt werden.
Im Allgemeinen beschreiben Metadaten in GIS-Systemen Eigenschaften, Definition, Herkunft, Gültigkeit, Genauigkeit, Einsatz- und Nutzungsmöglichkeiten von
Datensätzen. Nur so kann der langfristige Wert der Daten erhalten werden. Zwar
ist in Zeiten stark fallender Massenspeicherpreise die Datenhaltung nicht mehr
wirklich kostspielig, dennoch lassen sich durch den gezielten Einsatz von Metadaten bei der Archivierung von Datenbeständen gezielt Redundanzen vermeiden.
2.4
2.4.1
GIS Typen
Landinformationssystem
Landinformationssysteme (LIS) wurden durch Vermessungsämter entwickelt und
dienen der exakten geometrischen Erfassung von Grund und Boden sowie der damit verknüpften Attribute.
Ein Landinformationssystem ist ein Instrument zur Entscheidungsfindung in Recht,
Verwaltung und Wirtschaft sowie ein Hilfsmittel zur Planung und Entwicklung.
Es besteht einerseits aus einer Datensammlung, welche auf Grund und Boden
bezogene Daten einer bestimmten Region enthält, andererseits aus Verfahren und
Methoden für die systematische Erfassung, Aktualisierung, Verarbeitung und Umsetzung dieser Daten. Die Grundlage eines LIS bildet ein einheitliches, räumliches
Bezugssystem für die gespeicherten Daten, welches auch eine Verknüpfung der im
System gespeicherten Daten mit anderen bodenbezogenen Daten erleichtert. LIS
haben in Deutschland häufig das Gauß-Krüger System als geometrische Grundlage [Bill].
2.4.2
Rauminformationssystem
Ein Rauminformationssystem (RIS) ist ein Instrument zur Entscheidungsfindung
in der Raumbetrachtung sowie ein Hilfsmittel zur Planung und Entwicklung. Es
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
14
besteht aus einer Datensammlung zur Bevölkerungs-, Wirtschafts- und Siedlungsentwicklung, zum Infrastrukturausbau, zur Flächennutzung und den Ressourcen,
die in regionale Entwicklungsprogramme und raumbedeutsame Vorhaben einfließen. Ebenso sind die Verfahren und Methoden zur Erfassung, Aktualisierung und
Umsetzung dieser Daten wesentlicher Bestandteil des Informationssystems. Die
Grundlage bildet der einheitliche Raumbezug, der die verschiedenartigen Daten
miteinander verknüpft [Bill]. Das RIS findet z.B. Anwendung in der Raumordnung oder der amtlichen Statistik.
2.4.3
Umweltinformationssystem
Ein Umweltinformationssystem (UIS) ist ein erweitertes Geo-Informationssystem,
das der Erfassung, Speicherung, Verarbeitung und Präsentation von raum-, zeitund inhaltsbezogenen Daten zur Beschreibung des Zustandes der Umwelt hinsichtlich Belastungen und Gefährdungen dient und Grundlagen für Maßnahmen
des Umweltschutzes bildet. Es dient z.B. zur Erfassung der Radioaktivität oder
der Biotopkartierung.
2.4.4
Netzinformationssystem
Ein Netzinformationssystem (NIS) ist ein Instrument zur Erfassung, Verwaltung,
Analyse und Ausgabe von Betriebsmitteldaten. Diese beziehen sich auf die Netzwerktopologie, die in einem einheitlichen Bezugsrahmen gegeben sein muss. Die
Aufgabe besteht hauptsächlich aus der Dokumentation von Betriebsmitteldaten
(Kundendaten sowie Leitungen, Anlagen zur Ver- und Entsorgung).
2.4.5
Fachinformationssystem
Fachinformationssysteme (FIS) stellen eine besondere Klasse der GIS dar. Sie
decken im Besonderen alle Anwendungsbereiche ab, die von den o.g. Systemen
noch nicht erfasst wurden. FIS kommen z.B. in der digitalen aeronautischen Navigation (Luftverkehr) oder im Bereich von digitalen Straßenkarten als Grundlage
für autonome Fahrzeugnavigation zum Einsatz.
2.5
2.5.1
Koordinatensysteme
Gauß-Krüger Koordinaten
Gauß-Krüger Koordinaten sind ebene, zweidimensionale, rechtwinklige Koordinaten, die aus Rechts- und Hochwert bestehen. Die approximierte Erdoberfläche,
KAPITEL 2. GEOGRAPHISCHE INFORMATIONSSYSTEME
15
die einem Ellipsoid entspricht, muss in einer Ebene abgebildet werden. Hierbei
soll die Längen-, Winkel- und Flächentreue möglichst gewahrt werden. Zur Vermeidung störender Abbildungsverzerrungen auf die Gauß-Krüger Abbildungsebene dürfen die Rechtswerte bestimmte Beträge nicht überschreiten. Es wurden
daher Abbildungsstreifen mit einer ost-west Ausdehnung von drei Längengraden
(Meridianstreifensysteme) festgelegt. Der Rechtswert eines Punktes ist dann der
senkrechte Abstand vom Mittelmeridian des Abbildungsstreifens. Der Hochwert
ist der Abstand des Punktes vom Äquator, gemessen entlang des Mittelmeridians.
Abbildung 2.1: Gauß-Krüger Koordinaten
2.5.2
3D-Koordinatensystem
Jeder Punkt im (virtuellen) Raum, ist durch drei Koordinaten definiert. Hierzu sind
drei Achsen notwendig: Die X-Achse (links/rechts), die Y-Achse (oben/unten)
und die Z-Achse (hinten/vorne). Man unterscheidet zwischen einem links- und
einem rechthändigen Koordinatensystem. Java3D nutzt ein rechthändiges Koordinatensystem. Dies kann man sich ganz einfach veranschaulichen: an der rechten
Hand entspricht der Daumen der X-Achse, der Zeigefinger der Y-Achse und der
Mittelfinger steht für die Z-Achse.
Kapitel 3
Techniken und Werkzeuge
Dieses Kapitel gibt eine Übersicht über alle verwendeten Programmiersprachen
sowie Hilfsmittel, die zur Entwicklung und Modifikation des In 3D-Cityviewers
beigetragen haben.
3.1
HTML
Die Hyper Text Markup Language ist eine so genannte Auszeichnungssprache
und hat die Aufgabe, die logischen Bestandteile eines textorientierten Dokuments
zu beschreiben (wie Überschriften, Textabsätze, Listen, Tabellen oder Grafikreferenzen). Eine der wichtigsten Eigenschaften von HTML ist die Möglichkeit
Verweise zu definieren. Solche Hyperlinks können zu anderen Stellen im eigenen Projekt führen, aber auch zu beliebigen anderen Adressen im World Wide
Web. HTML wird benötigt um einen Hyperlink auf ein Java Applet zu setzen.
Das Applet kann somit auf allen Systemen, die einen Browser besitzen und Java
unterstützen angezeigt werden. Dies ist sehr nützlich, da die Anzeige unabhängig
von der verwendeten Hardware erfolgt.
3.2
XML
Die Extensible Markup Language ist eine Tag“-Sprache ähnlich HTML. Aller”
dings können die Tags bei XML benutzerdefiniert ausgeprägt werden und damit ein selbstbeschreibendes, textbasierendes Datenformat für strukturierte Dokumente generiert werden. Zu XML-Dokumenten gehört eine explizite Definition
der benötigten Tags und Ihrer Struktur, die Document Type Definition (DTD). Die
Tags in XML-Anwendungen - wie auch in HTML - treten paarweise als Start- und
End-Tags auf und geben an, welche Bedeutung der dazwischen liegende Text hat.
16
17
KAPITEL 3. TECHNIKEN UND WERKZEUGE
Ein solcher Tag könnte wie folgt aussehen:
<person> <vorname>...</vorname>
3.3
...
</person>
Java
Java ist eine objektorientierte und plattformunabhängige Programmiersprache von
Sun Microsystems. Unter Objektorientierung versteht man im allgemeinen die
Verschmelzung von Daten oder Eigenschaften und Funktionen zu einem Objekt.
Zusätzlich lässt sich Java durch die Java2D- und Java3D- Klassenbibliothek erweitern, die bereits sehr viele vorgefertigte Funktionalitäten enthalten. Java3D
eignet sich ideal für die plattformunabhängige Darstellung von 3D-Szenen und
basiert auf dem Prinzip eines Szenegraphen. Hierbei werden alle darzustellenden
Objekte und deren Eigenschaften sowie die Beziehungen der Objekte untereinander in einem Graphen gespeichert. Durch Picking, eine Selektionsmöglichkeit des
Benutzers, ist es beispielsweise möglich, einzelne Objekte innerhalb einer 3DSzene auszuwählen und zu diesen Objekten weiterführende Eigenschaften zu erhalten. Die Entwicklung von Java Applets, d.h. kleinen Programmpaketen, die in
einem Browser ablaufen können, ist nur eine Einsatzvariante von Java. Vielmehr
lassen sich mit Java normale Applikationen entwickeln, die wie jedes andere Programm auch außerhalb von Browsern ablaufen.
Ein weiterer Vorteil von Java ist die integrierte Standard-Datenbankanbindung
JDBC. Java ist zudem mit geringen Vorkenntnissen leicht zu erlernen.
Einer der größten Nachteile von Java ist zur Zeit noch die Performance.
3.4
3.4.1
Oracle
Datenbank Beschreibung
Oracle Datenbanken gehören zu den weltweit am verbreitesten Datenbanksystemen. Es handelt sich dabei um eine objekt-relationale Datenbank, die seit Version
8i eine verbesserte Internetanbindung aufweist und auf nahezu allen Plattformen
und Betriebssystemen vertreten ist.
Als Abfragesprachen stehen SQL, SQL*Plus und PL/SQL zu Verfügung. Bei
SQL*Plus handelt es sich um eine Oracle Erweiterung des Standard-SQL, PL/SQL
ist eine von Oracle entwickelte prozedurale Variante zu SQL. Bei der Entwicklung bzw. Weiterentwicklung von Oracle Datenbanken wird darauf geachtet, dass
die Datenbank auf allen verschiedenen Plattformen die gleiche Funktionsweise
und identische Bedienung hat. So ist gewährleistet, dass einmal erlernte OracleKenntnisse auch auf anderen Systemen Geltung haben und somit ohne Umlernen
KAPITEL 3. TECHNIKEN UND WERKZEUGE
18
angewendet werden können.
Die Installation und Konfiguration von Oracle8i geschieht hauptsächlich mit Werkzeugen, die in der weitgehend plattform-unabhängigen Sprache Java entwickelt
sind.
Grundsätzlich besteht die Architektur von Oracle Datenbanken aus drei Komponenten:
Hauptspeicher: Die Oracle Datenbank ist eine sehr speicherintensive Anwendung. Der Hauptspeicher, auch System Global Area (SGA) genannt, wird
von Oracle in mehreren Teilen verwaltet. Die wichtigsten sind:
1. Buffer Cache: hier werden aus der Datenbank gelesene Blöcke zwischengespeichert, um Zugriffe auf das Dateisystem zu vermeiden.
2. Library Cache: speichert bereits ausgeführte SQL-Statements, um die
wiederholte Verarbeitung bereits ausgeführter Anweisungen zu vermeiden.
3. Redo Log Buffer: verwaltet alle schreibenden Transaktionen, die noch
nicht durch Commit/Rollback beendet wurden.
4. Java- und Large Pool: sind für bestimmte Betriebsmodi des Servers
notwendig.
Prozesse: Sämtliche Aktionen der Datenbank werden durch Prozesse gesteuert.
Dabei wird zwischen Hintergrund- und Vordergrundprozessen unterschieden. Die Hintergrundprozesse steuern alle intern ablaufenden Vorgänge,
z.B. das Schreiben der geänderten Daten vom Cache zur Disk oder die Verwaltung der Logfiles. Die Vordergrundprozesse sind verantwortlich für die
Kommunikation mit den jeweiligen Nutzern.
Disk: Zur permanenten Speicherung verwaltet die Oracle Datenbank ihre Daten in Datafiles. Diese Dateien sind in Tablespaces organisiert, in denen das
DBMS1 seine Tabellen verwaltet. Auf Dateiebene gibt es weiterhin Controlfiles, in denen ein Teil der Konfigurationsdaten abgelegt sind, sowie Logfiles
in denen eine dauerhafte Speicherung der Transaktionsdaten für eventuelle
Backups erfolgt.
3.5
SQL
Die Structured Query Language ist eine standardisierte Abfragesprache, die alle
erforderlichen Sprachelemente enthält, um sämtliche Arbeiten, die beim Umgang
1
Datenbankmanagementsystem: Software-System zur Verwaltung einer Datenbank
KAPITEL 3. TECHNIKEN UND WERKZEUGE
19
mit einer relationalen Datenbank anfallen, auszuführen.
Bei der Verwendung der Oracle Datenbank können alle SQL-Befehle mittels
dem Programm sqlplus ausgeführt werden. Die in SQL angebotenen Anweisungen lassen sich zu den folgenden Befehlsgruppen zusammenfassen [MySQL]:
Data Definition Language (DDL): Im einzelnen kann man mit der DDL neue
leere“ Datenbankstrukturen wie Tabellen, Indizes, Views und weitere Ob”
jekte einrichten, die Strukturdefinition existierender DB-Objekte verändern
und Objekte löschen.
Data Manipulation Language (DML): Die DML dient zur Manipulation von
Daten und zu deren Auswertung. Zunächst gibt es die UPDATE-Anweisungen. Dazu gehören die Einfüge-, die Änderungs- und die Löschoperation. Für das Retrieval hat die Anweisung SELECT herausragende Bedeutung. Sie ermöglicht Auswertungen fast jeder Komplexität.
Data Control Language (DCL): Im einzelnen kann man mit der DCL Benutzern Systemprivilegien und Rechte auf Datenbank-Objekten gewähren und
entziehen.
3.6
3.6.1
TOMCAT
Beschreibung
TOMCAT ist ein servlet container. Servlet container sind eine Laufzeitumgebung,
die servlets auf Anfragen des Users aufruft und steuert.
Servlet container lassen sich grob in 3 Gruppen einteilen.
Stand-alone servlet container: Wird ein Java-basierter Web-Server verwendet,
bilden diese container einen integralen Bestandteil des Servers. Dies ist zum
Beispiel der Fall, wenn TOMCAT im stand-alone Modus betrieben wird.
In-process servlet container: Diese servlet container sind eine Kombination aus
einem Web-Server Plugin und einer Java-container Implementierung. Dazu
öffnet das Plugin eine JVM2 innerhalb des Adressraums des Web-Servers
und startet den Java-container darin. Wird die Ausführung eines Servlets
verlangt, übernimmt das Plugin diese Anfrage und übergibt diese an den
Java-container.
2
Java Virtual Machine
KAPITEL 3. TECHNIKEN UND WERKZEUGE
20
Out-of-process servlet container: Auch diese servlet container sind eine Kombination aus einem Web-Server Plugin und einer Java-container Implementierung. Im Unterschied zu den vorher genannten container laufen diese jedoch in einer JVM außerhalb des Web-Servers ab. Dabei kommunizieren
Web-Server Plugin und JVM üblicherweise über TCP/IP sockets. Auch hier
übernimmt das Plugin die Anfrage des Client und leitet diese über TCP/IP
an den Java-container weiter. Aufgrund dieser Konstruktion sind die Antwortzeiten der out-of-process servlet container länger als die der in-process
container, bieten jedoch andere Vorteile insbesondere hinsichtlich der Skalierbarkeit und Stabilität [Tomcat].
Im Falle dieser Arbeit wurde TOMCAT zum Zwecke der Entwicklung und
Debugging als stand-alone container ausgeführt. Hierzu wurde der Java Code lokal ausgeführt und eine Verbindung zur Datenbank beim Fraunhofer Institut in
Darmstadt hergestellt.
3.6.2
Die TOMCAT Verzeichnisstruktur
Verzeichnisname
bin
conf
lib
logs
scr
webapps
work
Beschreibung
Enthält Skripte zum Starten und
Herunterfahren des Servers
Enthält alle TOMCAT Konfigurationsdateien u.a. auch die Dateien:
server.xml
die Hauptkonfigurationsdatei von TOMCAT
web.xml
hier werden die Standardwerte für alle
Web-Applikationen von TOMCAT gesetzt
Enthält verschiedene jar Dateien, die
TOMCAT benutzt
Hier speichert TOMCAT seine Log-Dateien
Hier findet man die Servlet APIs Quellcodes
Enthält einige beispielhafte
Web-Applikationen
Dieses Verzeichnis wird von TOMCAT
automatisch angelegt, um temporäre
Dateien zu speichern
Tabelle 3.1: TOMCAT Verzeichnisstruktur
Kapitel 4
In 3D-Cityviewer
In dieser Arbeit wird ein bestehendes 3D-GIS (In 3D-Cityviewer) um einen Sachdatenanteil erweitert. Das bestehende GIS ermöglicht bereits die Auswahl eines
beliebigen 2D-Ausschnittes über ein Luftbild von Darmstadt (Abbildung 4.1). Der
selektierte Ausschnitt kann in einem 3D-Fenster dargestellt werden (Abbildung
4.2). Zuerst muss man den Teil der 3D-Geometrien auswählen, der angezeigt werden soll. Nun wird hier zwischen Grundrissen, Vegetation, Gebäuden, Dächern
und Mauern unterschieden. Die Erweiterung ergänzt das bestehende System um
eine Auswahl von Kategorien. Es kann z.B. die Kategorie Tankstelle“ gewählt
”
werden. Im Rahmen dieser Auswahl erfolgt eine Darstellung aller Tankstellen im
Ausgewählten 2D-Bereich im 3D-Fenster oder sie können alternativ von den anderen Gebäuden im 3D-Bereich farblich abgesetzt werden. Hierzu muss zuerst die
bestehende Datenbank um neue Tabellen erweitert werden. Die ergänzten Tabellen werden einerseits durch ein Mapping Verfahren mit Inhalt gefüllt und andererseits findet eine Online Recherche statt, um weitere Informationen über z.B.
Hotels herauszufinden.
4.1
Datenbank
Dieses Unterkapitel befasst sich mit typischen Daten für ein Stadtinformationssystem und deren sinnvoller Strukturierung zum Aufbau einer Datenbank. Zuerst wird auf den Aufbau einer relationalen Datenbank eingegangen. Im nächsten
Teil wird das bereits bestehende Datenbankkonzept vorgestellt und erklärt. Zuletzt
wird die Erweiterung um einen Sachdatenteil erläutert.
21
KAPITEL 4. IN 3D-CITYVIEWER
22
Abbildung 4.1: 2D Luftbild
4.2
Aufbau einer relationalen Datenbank
Die Daten einer relationalen Datenbank werden in Tabellen verwaltet, in deren
Spalten die Datenfelder und in deren Zeilen die Datensätze stehen. Zwischen den
Tabellen können Beziehungen hergestellt werden. Dazu muss in der Haupttabelle
ein eindeutig identifizierbares Datenfeld als Primärschlüssel (primary key) definiert werden. Dieses Datenfeld wird mit der beteiligten Tabelle mittels eines
Fremdschlüssels (foreign key) verknüpft. Über die Beziehungen zwischen den
verschiedenen Tabellen einer Datenbank können Daten aus mehreren Tabellen für
Datenbankabfragen zusammengeführt werden.
Ziel der Aufteilung der Daten in verschiedene Tabellen ist die Vermeidung von
doppelten Dateneinträgen (Redundanzen). Dieser Schritt wird auch Normalisierung genannt. Mehrfach vorkommende Dateneinheiten führen zu Inkonsistenzen,
falls nicht alle Vorkommen aktualisiert werden.
Zur Erzielung einer redundanzfreien Datenhaltung, werden Datenfelder, deren
Einträge in einer Tabelle mehrfach vorkommen, in eine eigene Tabelle ausgelagert, die über ein Primärschlüsselfeld mit dem Fremdschlüsselfeld der Detailtabelle verknüpft wird. Dadurch werden nicht die Daten sondern lediglich die Verknüpfungsschlüssel doppelt gespeichert. Eine Änderung von Einträgen muss nur
KAPITEL 4. IN 3D-CITYVIEWER
23
Abbildung 4.2: 3D Bild des selektierten 2D Ausschnittes
in einem Datensatz erfolgen.
Jeder Datensatz einer Tabelle muss eindeutig identifizierbar sein. Zu diesem Zweck
sollte jede Tabelle einen Primärschlüssel erhalten. Im einfachsten Fall besteht er
aus einer fortlaufenden Nummer. Eine Beziehung zu einer zweiten Tabelle erfolgt
über einen Fremdschlüssel, der den Wert des Primärschlüssels der Mastertabelle
erhält.
Zudem lässt sich der Inhalt eines Primärschlüssels nicht ändern, wenn er an Beziehungen beteiligt ist, es sei denn, alle beteiligten Schlüssel werden ebenfalls
geändert. Daher ist es von Vorteil, jeder Tabelle ein separates Schlüsselfeld zuzuordnen. Im vorliegenden Fall werden die Primärschlüssel der Tabellen mit dem
Tabellennamen und den Buchstaben ID benannt.
Es gibt drei Typen von Beziehungen zwischen zwei Tabellen:
1:1-Beziehung: In einer 1:1-Beziehung zwischen zwei Tabellen wird jedem Datensatz der einen Tabelle genau ein Datensatz der anderen zugeordnet. Die
Beziehung wird zwischen den Primärschlüsselfeldern beider Tabellen hergestellt.
KAPITEL 4. IN 3D-CITYVIEWER
24
1:n-Beziehung: Einem Datensatz der Mastertabelle, die auf der 1-Seite der 1:nBeziehung steht, können beliebig viele Datensätze der auf der n-Seite stehenden Detailtabelle zugeordnet werden.
m:n-Beziehung: Jedem Datensatz beider Tabellen können beliebig viele Datensätze der jeweils anderen Tabelle zugeordnet werden. Eine m:n-Beziehung
wird über zwei 1:n Beziehungen zu einer dritten so genannten Verbindungstabelle hergestellt. Sie steht auf der n-Seite beider Beziehungen.
4.3
Bestehende Datenbank
In diesem Abschnitt wird der Aufbau der bereits bestehenden Datenbank erläutert
- es wird auf die bestehenden Tabellen und ihre Relationen eingegangen. Die bereits vorhandene Datenbank besteht aus fünf Tabellen: body, face, node und surfacetype. Abbildung 4.3 zeigt das bestehende Datenbanksystem und die Beziehungen der einzelnen Tabellen zueinander.
Abbildung 4.3: Übersicht der Beziehungen
4.3.1
Body
In der Tabelle body werden die IDs und die einzelnen Objekte verwaltet. Jedes
Objekt hat eine einmalige ID, um es in Tabellen, die in Bezug zu body stehen,
25
KAPITEL 4. IN 3D-CITYVIEWER
eindeutig identifizieren zu können. Werden größere Objekte aus mehren kleineren Objekten zusammengesetzt, dann wird das Feld partof relevant. Wenn man
Auskunft über die Art des Objektes haben möchte, muss man sich das Feld bodytype ansehen. Hier wird zwischen den einzelnen Objekttypen wie z.B. Gebäude
oder Vegetation unterschieden. Um jedes Objekt ist eine Bounding Box gespannt.
Eine Bounding Box ist ein Quader, der ein Objekt mit allen Ausdehnungen umschließt. Dieser dient zur effektiveren Überprüfung, ob ein Objekt innerhalb eines
sichtbaren Bereichs liegt. Da es sich bei den Objekten in dieser Datenbank um
3D-Objekte handelt, müssen die Koordinaten der Bounding Box im 3D-Raum
festgehalten werden. Es werden nur die Koordinaten des Punktes unten links vorne und hinten rechts oben festgehalten. Damit können die restlichen Koordinaten
der Bounding Box berechnet werden.
Feldname
id
name
partof
Datentyp
Int
String
Int
bbox
bbox
bbox
bbox
bbox
bbox
Double
Double
Double
Double
Double
Double
llx
lly
llz
urx
ury
urz
Schlüssel Beschreibung
PK
Objekt ID
FK
Relation wenn Objekt aus mehreren
anderen Objekten besteht
Bounding Box Koordinate lower left x
Bounding Box Koordinate lower left y
Bounding Box Koordinate lower left z
Bounding Box Koordinate upper right x
Bounding Box Koordinate upper right y
Bounding Box Koordinate upper right z
Tabelle 4.1: Struktur der Tabelle body
4.3.2
Face
Die Tabelle face beinhaltet 2D-Elemente die aus 3 nodes gebildet werden. Es handelt sich hierbei um Dreiecke, die durch die Eckpunkte und nicht durch die Linien
repräsentiert werden. Hierbei ist es sehr wichtig, die nodes in der richtigen Reihenfolge zu wählen, um die Außenseite der faces festzulegen. Es muss die Reihenfolge gegen den Uhrzeigersinn gewählt werden. Jedem face wird mittels des
Attributes surcface id noch eine Oberfläche zugeordnet. Die Attribute body left
und body right geben an, wenn an ein face ein anderes Objekt angrenzt. Hierdurch können Redundanzen in der Speicherung der nodes vermieden werden.
26
KAPITEL 4. IN 3D-CITYVIEWER
Feldname
id
surface id
node1
node2
node3
body left
body right
Datentyp
Int
Int
Int
Int
Int
Int
Int
Schlüssel
PK
FK
FK
FK
FK
FK
FK
Beschreibung
Objekt ID
Schlüssel für 1. Node
Schlüssel für 2. Node
Schlüssel für 3. Node
angrenzende Objekte links
angrenzde Objekte rechts
Tabelle 4.2: Struktur der Tabelle face
4.3.3
Node
In der Tabelle node bekommt jeder Knoten eine id zugewiesen. Diese id ist der
Primärschlüssel in der node Tabelle. Jeder node besteht im 3D-Raum aus drei
Koordinaten, die als Float Werte gespeichert sind.
Feldname
id
x
y
z
Datentyp
Int
Double
Double
Double
Schlüssel Beschreibung
PK
Objekt ID
X-Koordinate
Y-Koordinate
Z-Koordinate
Tabelle 4.3: Struktur der Tabelle node
4.3.4
Surface
Die Tabelle surface legt fest, welche Oberfläche ein face hat. Sie ist eine Verbindungstabelle zwischen den Tabellen face und surfacetype.
Feldname
id
partof
surfacetype
name
Datentyp
Int
Int
Int
String
Schlüssel Beschreibung
PK
Objekt ID
FK
Tabelle 4.4: Struktur der Tabelle surface
KAPITEL 4. IN 3D-CITYVIEWER
4.3.5
27
Surfacetype
In der Tabelle surfacetype werden die verschiedenen Oberflächenarten festgelegt.
Jedes face bekommt in der Tabelle face einen surfacetype zugeweisen. Die id in
der Tabelle ist der Primärschlüssel und darf somit nur einmal vorkommen.
Feldname Datentyp
id
Int
type id
String
Schlüssel Beschreibung
PK
Objekt ID
Beschreibung des Oberflächentyps
Tabelle 4.5: Struktur der Tabelle surfacetype
4.4
Datenbankerweiterung
Bevor die Struktur für eine Datenbankerweiterung aufgebaut werden kann, muss
festgelegt werden, welche Daten in das bestehende Stadtinformationssystem integriert werden sollen.
Ein Stadtinformationssystem soll Antworten auf alle Fragen geben, die seine Nutzer zu einer Stadt haben. Nutzer eines solchen Systems sind Touristen, die eine
Reise in die Stadt planen oder bereits vor Ort sind, Bürger der Stadt sowie Unternehmer.
4.4.1
Konzeption
Die nachfolgende Tabelle soll einen Überblick darüber verschaffen, welche Objekte bzw. Informationen für ein Stadtinformationssystem von Bedeutung sind
und welche Detailinformationen in eine Sachdatenbank aufgenommen werden.
Alle in der Tabelle aufgeführten Informationen müssen so strukturiert in der Datenbank abgelegt werden, dass sie später entsprechend der Abfragen der Nutzer in
aufbereiteter Form zur Verfügung gestellt werden können .
Objekt
Bäckerei
Metzgerei
Tankstelle
Hotel
Detailinformation
Öffnungszeiten, Kontakt, Adresse
Öffnungszeiten, Kontakt, Adresse
Öffnungszeiten, Waschstrasse, Kontakt
Kontakt, Übernachtungspreise, Anzahl der Sterne, freie Zimmer
Tabelle 4.6: Konzept der DB-Objekte
KAPITEL 4. IN 3D-CITYVIEWER
28
Der hier vorliegende Entwurf für die Erweiterung des Stadtinformationssystem
am Beispiel der Stadt Darmstadt legt den Schwerpunkt auf typische Fragestellungen seitens der Bürger und Touristen der Stadt.
Die in 4.4.1 genannten Objekte, werden nun in das Stadtinformationssystem integriert. Dabei wendet man die in 4.2 beschriebenen Regeln an und bringt die
Objekte in die Tabellenstruktur eines relationalen Datenbanksystems.
4.4.2
Category
Zuerst müssen die verschiedenen Objekte in Kategorien unterteilt werden. Im Feld
id bekommt jede Kategorie einen ganzzahligen, positiven Wert zugeordnet. Dies
ist der Primärschlüssel der Tabelle category. Das Feld type ist ein String und beschreibt mit einer maximalen Länge von 40 Zeichen die Kategorie.
Durch diese Tabelle wird eine Darstellung der Beziehung zwischen Geometrien
und Kategorie ermöglicht.
Feldname Datentyp
id
Int
type
String40
Schlüssel Beschreibung
PK
Durchlaufende Nummer für ID der
Kategorie
Beschreibung der Kategorie
Tabelle 4.7: Struktur der Tabelle category
id type
1 bakery
2 hotel
Tabelle 4.8: Beispieldatensatz category
4.4.3
Building
In der Tabelle building werde alle Gebäude eingetragen, die einer Kategorie zugehören. Um ein Gebäude einer Kategorie zuordnen zu können, muss das in 4.6.1
beschriebene Mappingverfahren angewendet werden. Im Feld building id wird eine Gebäude-id eingetragen. Im Feld category wird eine der bestehenden Kategorien aus der Tabelle category gewählt. Die Tabelle building ist eine Verbindungstabelle zwischen der bestehenden body Tabelle und der neu angelegten category
Tabelle.
In einer späteren Version sind noch folgende Erweiterungen sinnvoll: Es wird
noch eine Tabelle adress angelegt. In dieser Tabelle kann jedem Gebäude, das
29
KAPITEL 4. IN 3D-CITYVIEWER
Feldname
building id
category
Datentyp
Int
Int
Schlüssel
PK
FK
Beschreibung
Verknüpfung zur Tabelle body
Verknüpfung zur Tabelle category
Tabelle 4.9: Struktur der Tabelle building
building id
11529
10715
category
1
1
Tabelle 4.10: Beispieldatensatz building
in der body Tabelle vorhanden ist, eine Adresse zugeordnet werden. Dies ist für
den Benutzer sehr hilfreich, da er somit das entsprechende Gebäude viel einfacher
finden kann.
4.4.4
Adress
Die building id ist der Primärschlüssel, da jedem Gebäude nur eine Adresse zugeordnet werden kann. Die Straße ist eine maximal 40 Zeichen lange Zeichenkette. Der zipcode ist ein String von der Länge von 5 Zeichen und gleichzeitig ein
Fremdschlüssel.
Feldname
building id
street
nr
zipcode
Datentyp
Int
String40
String3
String5
Schlüssel
PK
FK
Beschreibung
Verknüpfung zur Tabelle body
Strassenname
Hausnummer
PLZ
Tabelle 4.11: Struktur der Tabelle adress
In der zipcode Tabelle sind zu jeder PLZ die Stadt sowie der zugehörige Stadtteil
gespeichert. Beide dürfen eine Länge von maximal 40 Zeichen haben.
4.4.5
Bakery
In einem weiteren Schritt könnte für jede Kategorie eine Tabelle angelegt werden. Hier dient wieder die building id als Primärschlüssel. Durch diese Festlegung
kann maximal eine Bäckerei pro Gebäude existieren. Diese Tabelle gibt detaillierte Auskünfte über die einzelnen Objekte der Kategorie. Am Beispiel der Kategorie bakery wird der Name der Bäckerei, die Telefonnummer, die Öffnungszeiten,
die Email-Adresse sowie ein URL angegeben. Mittels dieser Informationen kann
KAPITEL 4. IN 3D-CITYVIEWER
building id
7501
13451
street
nr
Mühlstr.
72
Arheilger Str. 52
30
zipcode
64283
64289
Tabelle 4.12: Beispieldatensatz adress
Feldname
zipcode
city
district
Datentyp
String5
String40
String40
Schlüssel Beschreibung
PK
PLZ
Tabelle 4.13: Struktur der Tabelle zipcode
der Benutzer einfach mit der Bäckerei in Kontakt treten oder die Öffnungszeiten
einsehen.
4.4.6
Hotel
Ein weiteres Beispiel für eine einzelne Kategorie ist hotel. In dieser Tabelle werden Daten für Benutzer gespeichert, die eine Unterkunft suchen. Idealerweise ist
diese Tabelle mit der Verwaltung der einzelnen Hotels gekoppelt und kann somit
immer eine aktuelle Auskunft über die Anzahl der freien Betten geben. Dies ist
meist schwer zu realisieren und würde einen sehr hohen Aufwand bedeuten. Es ist
jedoch nicht sinnvoll zwei Systeme parallel zu pflegen. Unter Umständen könnten
Verweise auf das System der einzelnen Hotels gesetzt werden.
In den nachfolgenden Abschnitten wird gezeigt, wie mittels Java eine Verbindung
zur Datenbank herstellt, Daten austauscht sowie die Verbindung beendet wird.
Diese Funktionalitäten wurden zur Erweiterung des bestehenden Datenbankschemas verwendet.
4.5 Datenbankerweiterung mittels Java und SQL
4.5.1
Verbindung zur Datenbank herstellen
Um eine Verbindung zur Oracle Datenbank herzustellen muss zuerst wie in A beschrieben der Oracle Treiber installiert werden.
Im ersten Schritt wird nun der JDBC-Treiber explizit geladen. Beim Laden registriert sich der Treiber beim Treibermanager. Der Treibermanager ist ein Objekt
der Klasse DriverManager und ist dafür zuständig, dass der JDBC-Treiber verwalten wird, dass Log-Informationen bei Bedarf ausgeben werden und dass die
Verbindung zur Datenbank hergestellt wird.
31
KAPITEL 4. IN 3D-CITYVIEWER
zipcode city
64283
Darmstadt
64289
Darmstadt
district
Tabelle 4.14: Beispieldatensatz zipcode
Feldname
building id
name
telephone
opening hours
email
url
Datentyp
Int
String20
String20
String40
String20
String20
Schlüssel Beschreibung
PK
Name der Bäckerei
Öffnungszeiten
Email- Adresse
web url
Tabelle 4.15: Struktur der Tabelle bakery
// load the JDBC driver
try {
Class.forName("oracle.jdbc.driver.OracleDriver");
}
catch (Exception e) {
System.out.println("Failed to load JDBC driver.");
}
Ein Objekt der Klasse Connection repräsentiert die Verbindung zu einem DBMS
und wird wie folgt erzeugt:
//get a connection
try {
Connection con;
String url;
url = "jdbc:oracle:thin:";
url+ = "@clustera.igd.fhg.de:1521:tmobil";
con=DriverManager.getConnection(url,"user","pwd");
}
catch (Exception e) {
System.err.println("problems connecting");
}
Der JDBC-URL bezeichnet die DB, zu der die Verbindung aufgebaut werden soll.
Das Subprotokoll bezeichnet den Treibernamen und Subname bezeichnet die Datenbank.
32
KAPITEL 4. IN 3D-CITYVIEWER
Feldname
building id
name
category
telephone
email
url
single room
double room
free rooms
Datentyp
Int
String20
String5
String40
String20
String20
Int
Int
Int
Schlüssel
PK
Beschreibung
Preis für ein EZ in Euro
Preis für ein DZ in Euro
Anzahl der freien Zimmer
Tabelle 4.16: Struktur der Tabelle hotel
<jdbcurl>:: =jdbc:<Subprotokoll>:<Subname>@
<Rechnername>:<Port>:<DBname>
4.5.2
Datenaustausch
Ein Objekt der Klasse Statement repräsentiert eine SQL-Anweisung. Die SQL
Anweisung kann ein DDL1 -, DML2 - oder Query-Statement sein.
// create a statement
try {
Statement s = con.createStatement();
}
catch (Exception e) {
System.err.println("problems creating statem.");
}
Das erzeugen einer neuen Tabelle kann folgenderweise geschehen:
//execute a statement - create new table
try {
String createTable;
createTable = "CREATE TABLE BUILDING_CATEGORY "
createTable+ = "ID INT NOT NULL, ";
createTable+ = "CATEGORY_ID INT NOT NULL";
s.executeQuery(createTable);
1
2
Data Definition Language
Data Modeling Language
KAPITEL 4. IN 3D-CITYVIEWER
33
}
catch (Exception e) {
System.err.println("problems executing statement");
}
Das Einfügen und Ändern großer Mengen von Daten kostet viel Zeit, da für
jede Modifikation ein INSERT oder UPDATE über ein Statement-Objekt abgewickelt werden muss. Eine Verbesserung stellen Batch-Updates da, die auf einmal
eine große Menge an Daten zur Datenbank transferieren können. Die Datenbank
führt die Anweisungen in der Reihenfolge aus, wie sie im Batch-Prozess eingefügt
wurden.
// execute a statement - insert new data
int updateCounts[] = null;
try {
s.addBatch("INSERT INTO building VALUES (1,11911)");
s.addBatch("INSERT INTO building VALUES (1,11069)");
s.addBatch("INSERT INTO building VALUES (1,10628)");
s.addBatch("INSERT INTO building VALUES (1,13347)");
s.addBatch("INSERT INTO building VALUES (1,13894)");
updateCounts = s.executeBatch();
}
catch (Exception e) {
System.err.println("problems executing statem.");
}
4.5.3
Verbindung beenden
Falls man die Verbindung zur Datenbank nicht explizit beendet, wird sie automatisch nach einer gewissen Zeit geschlossen. Es ist aber ein besserer Programmierstil die Verbindung explizit zu schließen.
// close a connection
try {
con.close();
}
catch (Exception e) {
System.err.println("problems disconnecting");
}
KAPITEL 4. IN 3D-CITYVIEWER
34
Die DB-Verbindung wird durch close() geschlossen. Dadurch werden Ressourcen (z. B. Objekte der Klassen Statement und ResultSet), die von con verwendet
werden freigegeben.
4.6
Inhalt der Datenbank
Die Erweiterung der Datenbank ist nur sinnvoll, wenn diese auch mit Daten gefüllt
wird. Zum einen wurde in den gelben Seiten und dem Internet recherchiert, um an
weitere Informationen über die Bäckereien, Tankstellen und Hotels zu bekommen.
Zum anderen wurde ein manuelles Mappen der Objekte durchgeführt. Dies wird
ausführlich im nächsten Abschnitt erklärt.
4.6.1
Mapping
Beim Mapping werden die Gelben Seiten [Gelbe Seiten] in der online Version,
der Stadtplan von Darmstadt[Darmstadt] in der online Version sowie der In 3DCityviewer Applethttp://clustera.igd.fhg.de:8080/city3d002 verwendet. Im ersten
Schritt wählt man in den Gelben Seiten alle Hotels im Gebiet Darmstadt aus.
Abbildung 4.4: Gelbe Seiten - Auswahl eines Hotels
KAPITEL 4. IN 3D-CITYVIEWER
35
Abbildung 4.5: Stadtplan von Darmstadt mit selektiertem Bereich
Das nächste Ziel ist nun die Gauß-Krüger Koordinaten vom Hotel Alpha Garni in der Mühlstr. 72 herauszufinden. Dazu lädt man den Online-Stadtplan von
Darmstadt. Zunächst muss die Anzeige der Gauß-Krüger Koordinaten unter An”
sicht“ aktiviert werden. Nun wird der Ausschnitt, der die Mühlstrasse 72 beinhaltet über das Straßenverzeichnis ausgewählt. Danach kann man die Gauß-Krüger
Koordinaten am Rand des Stadtplanes ablesen. Der nächste Schritt besteht daraus, im 2D-Luftbild des In 3D-Cityviewer Applets die Gauß Krüger Koordinaten
einzugeben um dann das Hotel Alpha Garni im 2D-Luftbild zu sehen. Nachdem
der 2D-Ausschnitt bekannt ist, kann dieser im 3D-Fenster angezeigt werden. Im
3D-Fenster kann durch klicken auf das Gebäude die ID angezeigt werden. Um die
body ids herauszufinden, muss erst noch eine Datenbankabfrage gemacht werden.
Die resultierende body id kann nun in der neuen Tabelle building unter building id
mit der entsprechenden category id eingetragen werden. In diesem Fall ist die category id 1“. Dieses Verfahren muss für jedes Objekt, das kategorisiert werden
”
soll angewendet werden.
KAPITEL 4. IN 3D-CITYVIEWER
4.7
36
Applet
Im nachfolgenden Abschnitt wird auf den In 3D-Cityviewer eingenagen. Hierzu
wird zunächst das bestehende Konzept und die wichtigsten Klassen vorstellt. Danach werden die Erweiterungen, die am In 3D-Cityviewer durchgeführt wurden
gezeigt. Teilweise kann leider nur das Konzept vorstellt werden, da der Datenbankserver nicht stabil genug läuft um alle Ideen zu integrieren bzw. die Implementation zu testen.
4.7.1
Klassen und Funktionsbeschreibung
Einige der Klassen sind sehr umfangreich, daher wird in dieser Beschreibung sowie in den Klassendiagrammen nur auf die für diese Arbeit relevanten Funktionen
und Variablen eingegangen. Im Anhang findet man in Abbildung C.1 eine Übersicht über die Verzeichnisstruktur.
Cityviewer3D
Die Hauptklasse des Applets heißt Cityviewer3D. In der Funktion init() wird das
Java Applet initialisiert und somit auch das Menü des 3D-Viewers. Das Menü und
die Anordnung der einzelnen Komponenten wird mittels der Swing API realisiert.
Die Methode set2DMapfirstload(boolean b) wird aufgerufen, sobald der Benutzer
das erste Mal, die 2D-Luftbildkarte lädt. Es wird eine neue 2DMap angelegt.
In der Klasse Cityviever3D wurden die zwei Checkboxen adress und detail info
hinzugefügt. Hiermit können die Details der anzuzeigenden Sachdaten eingestellt
werden. Wenn die Box adress ausgwählt ist, dann wird die Adresse angezeigt.
Mit der anderen Checkbox kann eine detaillierte Kategorieninformation angezeigt
werden. Der Status der Checkboxen wird mittels der Funktion detailed.getState()
abgefragt.
MouseNavigator
Diese Klasse dient zum Abfangen aller Mausklicks und -bewegungen über der
3D-Szenerie.
Connect
Diese Klasse stellt eine Verbindung zur Datenbank her. Über die Funktion getConnection() können andere Klasse auf die Verbindung zugreifen und diese nutzen. Somit muss nicht jedes Mal eine neue Verbindung hergestellt werden. Die
Klassen DbQuery, Sachinfo und GetCategory nutzen die Verbindung.
KAPITEL 4. IN 3D-CITYVIEWER
37
DbQuery.java
In dieser Klasse können Objekte aus der Datenbank geladen werden. Zurzeit
können Gebäude, Grundrisse, Vegetation, Gelände und Mauern aus der Datenbank
extrahiert werden. Die Ergebnisse können entweder als VRML File gespeichert
werden oder direkt in die 3D-Karte integriert werden. Falls die Objekte direkt
in die 3D-Karte geladen werden, dann müssen diese erst von den Weltkoordinaten in Szenekoordinaten transformiert werden. Die Methode getBuilding(String
name, int restype) extrahiert ein Gebäude aus der Datenbank und fügt es der 3DSzene hinzu. Innerhalb der Methode getRegion(Rectangle2D r, int restype, boolean grundrisse ,boolean bewuchs, boolean gelaende, boolean gebaeude, boolean
mauern) wird mittels des Rectangle2D die ausgewählte Region bestimmt. Diese Methode muss verändert werden, um nur einzelne Kategorien in einer Region
auszuwählen. Es gibt zwei verschiedene Möglichkeiten die Kategorien sichtbar zu
machen. Entweder wird nur die ausgewählte Kategorie in der 3Dmap dargestellt
oder es werden alle Gebäude dargstellt, jedoch die gewählte Kategorie mit einer
anderen Farbe.
Zuerst wird geprüft, ob eine Kategorie ausgewählt ist. Falls keine Kategorie ausgewählt ist, wird die Funktion wie bisher ausgeführt. Andernfalls muss die Kategorie ermittelt werden und welche Anzeigeoption gewählt wurde. Im Falle, dass
die Anzeigeoption nur Kategorie“ gewählt wurde, muss die SQL-Query geändert
”
werden. Es findet eine Join Operation zwischen der Tabelle Body und der Tabelle
Building statt. Zusätzlich muss noch die Bedingung für die Kategorie hinzugefügt
werden. Als Resultat erhält man nur die Gebäude, die einer speziellen Kategorie
angehören.
Schwieriger wird es, wenn alle Gebäude einer Region dargestellt werden sollen
und sich die Kategorie in diesem Falle farblich vom Rest unterscheiden soll. Zuerst müssen alle Gebäude einer ausgewählten Region ermittelt werden. Die Menge
dieser Gebäude muss nun geteilt werden. Mit Hilfe des SQL minus“ Befehls wer”
den von der Menge aller Gebäude der Region die Gebäude der gewählten Kategorie entfernt. Nun wird zuerst diese Menge ganz normal angezeigt. Im nächsten
Schritt werden die Gebäude der Kategorie bevor sie in den Szenengraphen der
3D-Map integriert werden mit einer anderen Farbe versehen.
MapViewer
Die Klasse MapViewer werden die wesentlichen Bestandteile der 2DMap initialisiert und verwaltet. Der Benutzer muss in der 2D-Karte auswählen, welcher Ausschnitt im 3D-Viewer dargestellt werde soll. Dazu selektiert man mit der Maus
oder durch die Eingabe von Koordinaten den entsprechenden Bereich. MapViewer übermittelt die Selektionsdaten an die Klasse Cityviewer3D.
KAPITEL 4. IN 3D-CITYVIEWER
38
In der Klasse MapViewer muss zunächst das Menü erweitert werden, um dem Benutzer das Abfragen von Sachdaten über einzelne Objekte zu ermöglichen. Da die
Generierung der Auswahlliste dynamisch erfolgen soll, ist zuerst eine Datenbankabfrage notwenig. Hierbei werden alle möglichen Kategorien, die der Benutzer
zur Verfügung hat selektiert. Die Datenbankabfrage ist in einer neuen Klasse GetCategory realisiert. Diese Klasse stellt wie in 4.5.1 beschrieben die Verbindung
zur Datenbank her. Zuerst zählt wird die Anzahl der Zeilen gezählt, so dass das
Rückgabe Array initialisiert werden kann.
Dieses Array wird dann an die Klasse MapViewer zurückgegeben. Danach wird
die JList dynamisch durch das übergebene Array erstellt. Die Methode setSelectionMode() ist dafür verantwortlich, dass immer nur eine Kategorie ausgewählt
werden kann. Eine JList bietet standardmäßig keine Möglichkeit zum Scrollen ihres Inhalts an. Wird sie ohne weitere Maßnahmen auf dem Panel platziert, können
nur Elemente aus dem sichtbaren Bereich ausgewählt werden. Daher muss die
JList in ein JScrollPane eingebettet werde, das sich um alle Scrollbars kümmert.
//dynamisches erstellen der JList
GetCategory gc = new GetCategory();
category_list = gc.returnCategory();
private JList;
jltCategory = new
JList(category_list);
JScrollPane jspScroll = new JScrollPane(jltCategory);
jltCategory.setSelectionMode
(ListSelectionModel.SINGLE_SELECTION);
jlt.setToolTipText("Select Category.");
Es ist nur sinnvoll eine Kategorie auszuwählen, wenn Gebäude“ zur Anzeige
”
im 3D-Viewer gewählt ist. Daher wird immer der Status der Flag für Gebäude“
”
geprüft. Falls die Flag nicht gesetzt ist, wird die JList für Benutzereingaben mittels
der Funktion setEnabled(bool) deaktiviert. In der Methode getSomePanel() muss
noch der ListSelectionLister registriert werden.
jltCategory.addListSelectionListener
(new ListSelectionListener()) {
public void valueChanged(ListSelectionEvent e) {
selected_category =
jltCategory.getSelectedValues();
}
}
KAPITEL 4. IN 3D-CITYVIEWER
39
Feature3D
Feature3D ist die Super-Klasse aller dargestellten 3D-Objekte, die selektierbar
sind und stellt existenzielle Methoden zur Selektion“ zur Verfügung. Im Kon”
struktor werden die Knoten im Szenegraphen als lesbarbar“ markiert.
”
setCapability(Node.ALLOW_BOUNDS_READ);
Die Methode pickThisObject(Vector3f cameraPostion, double rotation, boolean leftMouseButton) wird aufgerufen, sobald ein pickable Object (also eine Subklasse) vom Suchstrahl“ eines Mausklicks erfasst wird. Wenn ein Objekt aus”
gewählt wurde, dann wird im String Sachdaten“ die ID des Objektes und die
”
Dachform gespeichert. In der Erweiterung dieser Klasse können je nach Auswahl
durch den Benutzer verschiedene Detailstufen der Sachdaten angezeigt werden.
Die Klasse Feature3D stellt diese Information mittels eines Sachdaten String bereit.
//hinzufuegen der Adresse zum Sachdatenstring
SachInfo si = new SachInfo();
String temp_adress = si.getAdress(_id);
if (temp_adress !=null){
sachdaten[2] = temp_adress;
}
//hinzufuegen der Detailinfos zum Sachdatenstring
String temp_detail_info =
si.getDetailInfo(_id); if (temp_detail_info != null){
sachdaten[3] = temp_detail_info;
}
PickableObject
Dies ist die Super-Klasse aller dargestellten 3D-Objekte,die anklickbar sind, und
stellt existenzielle Methoden zur Anklickbarkeit“ zur Verfügung.
”
Map3DScene
Hier wird eine leere 3D-Szene mit allen notwendigen Operationsmöglichkeiten
erstellt.
KAPITEL 4. IN 3D-CITYVIEWER
4.7.2
40
Erweiterung
Sachinfo
In der Klasse Sachinfo werden die Adressdaten sowie die erweiterten Informationen über die Objekte einer Kategorie bereitgestellt. Die Methode getAdress(String
id) erzeugt eine SQL-Query und gibt die Daten als String zurück.
String query;
query = "SELECT * FROM adresse WHERE id = ’"+id+"’ "
query+ = "AND adresse.plz = plz.plz";
Das Result wird im XML-Format3 gespeichert. Ein Rückgabe String könnte
wie folgt aussehen:
<id>7501</id><street>Muehlstr.</street><nr>72</nr>
<plz>64283</plz><city>Darmstadt</city>
Die Methode getDetailedInfo(String id) liefert die erweiterten Information des
Objektes einer Kategorie. Hierzu muss zuerst überprüft werden, ob und welche
Kategorie ausgewählt wurde. Dies ist recht einfach, da bei jeder Veränderung der
ausgewählten Kategorie die Variable selected category mit der entsprechenden
Kategorie gesetzt wird. Danach muss wieder eine Datenbankabfrage durchgeführt
werden.
String query;
query = "SELECT * FROM"+ selected_category +"
query+="WHERE id = ’"+id+"’";
Der Rückgabe String wird ebenfalls im XML Format erzeugt und könnte folgendermaßen aussehen:
<id>7501</id><category>hotel</category> <name>Alpha
Garni</name> <fon>0615117430</fon> <email></email>
<url></url> <ez>34</ez> <dz>44</dz>
<free>6</free>
Durch das Aufbereiten der Rückgabe Daten im XML-Format ist die spätere
Verwendung in verschiedenen Anzeigeformaten wesentlich einfacher.
3
Siehe 3.2
KAPITEL 4. IN 3D-CITYVIEWER
41
GetCategory
Diese Klasse stellt die Verbindung zur Datenbank her. Sie zählt zuerst die Anzahl
der Zeilen, damit das Rückgabe Array initialisiert werden kann.
//Zaehlen der Zeilen in der Tabelle um
//das Rueckgabe Array anlegen zu koennen
try{
String query;
query = "SELECT COUNT * FROM category";
resul t= s.getResultSet();
result = s.executeQuery(query);
} catch (Exception e) {
System.err.println("problems with sql query");
}
Im nächsten Schritt werden die verschiedenen Kategorien aus der Datenbank ausgelesen und in dem Array result[] gespeichert.
//fuellen des Rueckgabe Arrays mit Kategorien
try{
Sting query;
query = "SELECT typ FROM category";
result = s.executeQuery(query);
int i=0;
while(result.next()){
result[i]= result.getString(1);
i++;
}
} catch (Exception e) {
System.err.println("problems with sql query");
}
Kapitel 5
Fazit und Ausblick
Dieses letzte Kapitel gibt eine Zusammenfassung über die während der Studienarbeit erreichten Ziele. Dabei wird auch auf Probleme eingegangen, die innerhalb
dieser Arbeit auftraten. Zuletzt wird ein Ausblick über weiterführende Veränderungen am In 3D-Cityviewer sowie über zukünftige Weiterentwicklungen von 3DGIS gegeben.
Innerhalb dieser Arbeit wurde ein Datenbankkonzept für die Erweiterung eines
bestehenden Geo-Informationssystem entworfen. Das Datenbankkonzept wurde
mittels Java und SQL auch umgesetzt. In einem weiteren Schritt wurde die Datenbank mit Inhalt gefüllt, um Benutzerspezifische Abfragen zu ermöglichen. Der
Inhalt der Datenbank ist keineswegs vollständig und dient nur zur Veranschaulichung der Funktionen. Für den praktischen Einsatz ist eine Komplettierung der
Datensätze (soweit wie möglich) erforderlich. Dazu wurden im bestehenden In
3D-Cityviewer Veränderungen durchgeführt. Einerseits wurden die GUIs der 2DMap und des 3D-Vievers erweitert. Andererseits wurden Datenbank Queries verändert und es wurden Objekteigenschaften wie z.B. die Farbe von selektieren
Objekten einer Kategorie bevor sie im Szenengraphen in Ihre Branchgroup eingehängt wurden modifiziert.
Ursprünglich war die Entwicklung eines eigenes 3D-GIS für mobile Geräte geplant. Jedoch stelle sich im Laufe der Arbeit heraus, dass es bereits den In 3DCityviewer gibt. Daher wurde im Verlauf der Arbeit das Ziel geändert. Der In
3D-Cityviewer wurde um den Sachdatenteil ergänzt. Leider lief der Datenbankserver nicht so stabil, dass alle Veränderungen implementiert und getestet werden
konnten. Auf Grund dessen konnte in einigen Kapiteln nur die Konzeption vorstellt werden. Da der In 3D-Cityviewer wesentlich umfangreicher und mächtiger
als das geplante GIS für mobile Geräte ist, kann dieser trotz Verwendung von Java
nicht auf mobilen Endgeräten benutzt werden. Zusätzlich benötigt die Anbindung
42
KAPITEL 5. FAZIT UND AUSBLICK
43
der Datenbank hohe Ressourcen. In einem späteren Schritt könnte ein GIS entwickelt werden, das speziell auf die Nutzung auf mobilen Geräten ausgelegt ist. Dazu müsste die Datenbank auf eine Oracle lite umgestellt werden, die für den EinBenutzer-Betrieb ausgelegt und hauptsächlich für mobile und verteilte Anwendungen gedacht ist[Oracle]. Für dieses Aufgabengebiet optimiert, benötigt sie nur
wenige Ressourcen, z.B. 1 MB Hauptspeicher und bei minimaler Installation gerade 3 MB Festplattenkapazität. Vielleicht ist dies auch nicht mehr notwendig, da
der Start der UMTS Netze kurz bevor steht und diese über eine wesentlich höhere
Bandbreite als die momentanen GSM Netze verfügen. Unter Umständen kann die
Aufbereitung raumbezogener Informationen für mobile Systeme den UMTS Netzen zum Durchbruch verhelfen.
Benutzer mobiler Endgeräte stellen Fragen zu Sachdaten der Objekte einer Stadt
und Fragen zu geo-räumlichen Orientierung in der Stadt. Deshalb wäre es schön,
wenn Nutzer ausgehend von Ihrem lokalen Standpunkt, der über GPS oder das
GSM Netz bestimmt wird topologische Abfragen stellen könnten [GPS]. So wäre
eine weitere Idee für zukünftige Entwicklungen, dass dem Benutzer ein Flug ausgehend von seinem Standpunkt zu seinem Ziel durch die virtuelle Stadt gezeigt
wird. Dies würde Ihm sicher die Wegfindung stark erleichtern.
Anhang A
Installation des Oracle Treibers
Um eine Oracle Datenbank unter der Verwendung von Java zu nutzen muss zuerst
ein aktueller Treiber unter folgendem Link heruntergeladen werden:
http://otn.oracle.com/software/tech/java/sqlj jdbc/content.html
Dort erhält man die Datei oracle9i.jar. Diese Bibliothek muss dem aktuellen Java
SDK1 hinzugefügt werden. Dies geschieht durch einfaches kopieren der Datei
oracle9i.jar in den Ordner %java home%/jre/lib/ext.
1
Software Development Kit
44
Anhang B
Installation von TOMCAT
Die Installation von TOMCAT sollte bei Befolgung der folgenden Schritte schnell
und problemlos verlaufen.
1. Zuerst lädt man sich die Binaries unter der Adresse http://jakarta.apache.org
herunter.
2. Nun muss die Datei in ein beliebiges Verzeichnis z.B. tc entpackt werden.
In diesem Verzeichnis sollte dann automatisch ein Unterverzeichnis namens
tomcat angelegt werden.
3. Sollte dies nicht automatisch erfolgen, so ist es erforderlich das Verzeichnis
in tomcat umzubenennen. Nun wird eine neue Umgebungsvariable, die auf
das Basisverzeichnis Ihrer Tomcathierachie verweist, gesetzt. Unter Windows geht dies am einfachsten mit dem Befehl:
set TOMCAT_HOME=tc\tomcat
4. Falls noch kein %Java home% Verzeichnis existiert, muss dies erstellt werden. Die Einstellungen können unter Systemsteuerung > System > Umgebung kontrolliert werden.
Ferner kann TOMCAT mit der Benutzervariable CATALINA OPTS mehr Speicher
zugesichert werden:
-Xms256M -Xmx256M -DCATALINA_HOME=\%CATALINA_HOME\%
-DTMOBIL_CONNECT=D:\connect.txt
Nach der Ausführung dieser Schritte sollte nun TOMCAT als stand-alone servlet
container laufen.
45
ANHANG B. INSTALLATION VON TOMCAT
Abbildung B.1: Umgebungsvariablen unter WinXP
46
Anhang C
Verzeichnisstruktur
Abbildung C.1: Verzeichnisstruktur In 3D-Cityviewer
47
Literaturverzeichnis
[Bill] Bill, Ralf und Fritsch, Dieter
Grundlagen der Geo-Informationssysteme, Bd. 1 Hardware, Software und
Daten;
Wichmann Verlag, 3. Auflage, 1997
[Lorber] Lorber
Aufbau des 3D-Stadtmodells Graz. Beiträge zum XII. Internationalen Kurs für
Ingenieurvermessung, Bd. 2;
Dümmler Verlag Bonn, 1996
[Linder] Lindner, Wilfried
Geo-Informationssysteme;
Heidelberg-Springer-Verlag, 1999
[Bouvier] Bouvier, Dennis
Getting Started with the Java3D API, A Tutorial for Beginners;
http://developer.java.sun.com/developer/onlineTraining/java3d/index.html
Sun Microsystems, Inc., 1999
[MySQL] MySQL reference manual;
http://www.mysql.com/doc/
MySQL AB, 2003
[Tomcat] TOMCAT documentation;
http://jakarta.apache.org/tomcat/tomcat-4.0-doc
Apache Software Foundation, 2003
[Oracle] Oracle documentation;
http://otn.oracle.com/software/tech/java/sql jdbc/content.html
Oracle, 2003
[Gelbe Seiten] Gelbe Seiten online Version;
http://www.gelbe-seiten.de
Deutsche Post, 2003
48
LITERATURVERZEICHNIS
[Darmstadt] Darmstadt Stadtplan online Version;
http://www.darmstadt.de
Darmstadt, 2003
[GPS] U.S. Coast Guard Navigation Center (USCG NAVCEN);
http://www.navcen.uscg.gov/gps/default.htm
USCG, 2003
49