Analyse und Optimierung von UMN-Mapserversystemen - Herzlich ...

Fachhochschul-Diplomstudiengänge Technik
Performance- Analyse
und Optimierung von
UMN-Mapserversystemen
______Mai 2007____________ __________Johann Zettel______
Datum Verfasser

Titel der Diplomarbeit:
Eidesstattliche Erklärung:
Performance- Analyse und Optimierung von
UMN- Mapserversystemen
Eingereicht von: Johann Zettel
Diplomarbeit
Fachhochschul-Diplomstudiengänge Technik
am Fachhochschul-Diplomstudiengang
Geoinformationstechnologie
Begutachter: DI Brigitte Rudel
Wiener Neustadt: Mai 2007
_____________________________________________________
Ich versichere,
dass ich die Diplomarbeit selbständig verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfe
bedient habe und diese Diplomarbeit bisher weder im In- und Ausland in irgendeiner
Form als Prüfungsarbeit vorgelegt habe. Die von mir eingereichte schriftliche
Version stimmt mit der digitalen Version der Arbeit überein.
______________________________ _________________________
Datum Unterschrift

Kurzzusammenfassung:
Kurzzusammenfassung / Abstract:
Fachhochschul-Diplomstudiengänge Technik
Das World Wide Web erhält in den letzten Jahren stetig Zuwachs an neuen
WebGIS-Applikationen. Der UMN-Mapserver ist eine Möglichkeit solche
Anwendungen umzusetzen. Es handelt sich dabei um ein Open-Source-
Projekt, das auf vielen anderen freien Bibliotheken aufbaut. Da die Software
viele Einstellungen und mehrere Lösungswege offen lässt, ist die optimale
Konfiguration schwer zu finden. Dieser Umstand äußert sich oft in
Performance- oder Stabilitätsproblemen.
Aufbauend auf dieser Problematik untersucht diese Diplomarbeit die Performance
und Leistungsfähigkeit von UMN-Mapserversystemen. In einem
Netzwerklabor wurden unterschiedliche Einstellungen und Systemvarianten
getestet. Die analysierten Testbereiche gliedern sich in Datenhaltung,
Mapfile Modifikationen, Datenzugriff, Hardware und Betriebssystem. Eine
Analyse der Testergebnisse ergibt interessante Möglichkeiten UMN-
Mapserversysteme zu verbessern.
Schlagworte: UMN-Mapserver, PostGIS, Räumliche Daten, Performance, Web-
GIS;
Abstract:
In the last few years, WebGIS-applications have been continuously increasing
in the World Wide Web. The UMN-Mapserver is one option to develop
this kind of applications. An Open-Source-Project is supervising this
software package which is built on other free libraries. The UMN-
Mapserver allows many system settings and offers many different solutions
for the same problem. It is very difficult to find the best configuration.
This is the reason why many applications have problems with performance
and stability.
Based on this problem, this thesis analyses the performance and efficiency
of UMN-Mapserver systems. Many different settings and system compositions
were tested in a network laboratory. The tested areas are divided
into data management, mapfile modifications, data access, hardware and
operating system. The analyses of the results of the tests show interesting
options to improve the performance of UMN-Mapserver systems.
Keywords: UMN-Mapserver, PostGIS, Spatial Data, Performance, WebGIS;

Diplomarbeit Johann Zettel
Danksagung
Mein aufrichtiger Dank geht an Frau Dipl. Ing. Brigitte Rudel und an Dipl. Ing. Walter
Schneider für die Betreuung meiner Diplomarbeit sowie für die fachliche Unterstützung.
Außerdem möchte ich mich bei den Referenten der Fachhochschule Wiener Neustadt Stu-
diengang Geoinformationstechnologie und den Mitarbeitern des Unternehmens arsenal re-
search für deren fachlichen Ratschläge bedanken.
Ein weiteres herzliches Dankeschön geht an meine Eltern, die mich während des gesamten
Studiums motiviert und finanziell unterstützt, und mir somit diese Ausbildung ermöglicht
haben.
Ein besonders liebes Dankeschön geht an Sabine Schneidhofer, die mich während der Stu-
dienzeit immer motiviert und unterstützt hat.
Dankeschön !
4

Diplomarbeit Johann Zettel
Inhaltsverzeichnis
1. Einleitung......................................................................................................................... 7
1.1. Problemstellung.......................................................................................................... 7
1.2. Zielsetzung ................................................................................................................. 8
1.3. Arbeitsablauf .............................................................................................................. 8
1.4. Systemabgrenzung ................................................................................................... 10
2. Formulierung der Hypothese.................................................................................... 11
3. Stand der Technik ....................................................................................................... 12
3.1. Begriffsbestimmung................................................................................................. 12
3.2. Web Visualisierung.................................................................................................. 14
3.2.1. Präsentationsformen ......................................................................................... 15
3.2.2. Kartengenerierungstools................................................................................... 16
3.2.3. Grafikformate ................................................................................................... 16
3.2.4. Antialiasing ...................................................................................................... 21
3.2.5. Web-Programmierung...................................................................................... 22
3.3. Räumliche Daten ...................................................................................................... 24
3.3.1. Räumliche Vektordaten.................................................................................... 25
3.3.2. Räumliche Rasterdaten..................................................................................... 28
3.3.3. Räumliche Indizes............................................................................................ 29
3.3.4. Räumliche Abfragesprache .............................................................................. 31
3.4. UMN-Mapserver Architektur................................................................................... 34
4. Testanforderungen ...................................................................................................... 38
4.1. Testbereiche ............................................................................................................. 38
4.1.1. Datenhaltung .................................................................................................... 39
4.1.2. Mapfile ............................................................................................................. 39
4.1.3. Datenzugriff ..................................................................................................... 41
4.1.4. Hardware .......................................................................................................... 43
4.1.5. Betriebssystemplattform................................................................................... 44
4.2. Testlabor................................................................................................................... 47
4.3. Testdatensatz ............................................................................................................ 48
4.4. Testapplikation......................................................................................................... 52
5

Diplomarbeit Johann Zettel
5. Messung.......................................................................................................................... 55
5.1. Evaluierung .............................................................................................................. 55
5.2. Messablauf ............................................................................................................... 57
6. Analyse der Messreihen.............................................................................................. 58
6.1. Plattform................................................................................................................... 58
6.1.1. Windows Server 2003 ...................................................................................... 58
6.1.2. Linux Debian.................................................................................................... 59
6.2. Datenhaltung ............................................................................................................ 60
6.3. Mapfile ..................................................................................................................... 63
6.3.1. Antialiasing ...................................................................................................... 64
6.3.2. Ausgabeformat ................................................................................................. 65
6.3.3. Projektionsumrechnung.................................................................................... 68
6.4. Datenzugriff ............................................................................................................. 69
6.4.1. Datenorganisation............................................................................................. 69
6.4.2. Indizes .............................................................................................................. 69
6.5. Hardware .................................................................................................................. 71
6.5.1. Arbeitsspeicher................................................................................................. 71
6.5.2. CPU .................................................................................................................. 73
6.6. Weitere mögliche Optimierungsschritte................................................................... 74
7. Schlussfolgerung .......................................................................................................... 76
Abkürzungsverzeichnis:........................................................................................................... 80
Abbildungsverzeichnis:............................................................................................................ 81
Quellcodeverzeichnis: .............................................................................................................. 83
Literaturverzeichnis:................................................................................................................. 84
6

Diplomarbeit Johann Zettel
1. Einleitung
Im Zuge des Diplomstudiums wurde ein Praktikumssemester im Unternehmen arsenal re-
search in der Abteilung Verkehrstechnologien absolviert. Seit Jahren betreibt diese Abteilung
Forschung in nationalen und internationalen Projekten mit dem Schwerpunkt „Verkehrstele-
matik“. Ergebnisse dieser Forschung sind in der Regel Methoden zur Generierung von Ver-
kehrsdaten, die räumlichen Bezug zur Erdoberfläche aufweisen. Diese müssen, um sie sinn-
voll betrachten zu können, visualisiert werden.
An diesem Punkt setzte die Praktikumsarbeit an. Verkehrsdaten, die bis dato nur unzurei-
chend visualisiert worden waren, mussten analysiert, aufbereitet und in einer für die Allge-
meinheit einsehbaren Form visualisiert werden. Die Praktikumsarbeit mit dem Titel: „Ent-
wicklung und Umsetzung einer Anwendung zur Visualisierung von dynamischen Verkehrsin-
formationen im Internet“[ZETTEL 2007] beschäftigte sich mit der Analyse, dem Design und
der Umsetzung eines Systems, welches eine Internet-Schnittstelle besitzt und die Anforderun-
gen der Visualisierung erfüllt. Realisiert wurde diese Web-Gis-Applikation auf Basis des
UMN-Mapservers als Kartengenerierungstool und einer PostgreSQL-Datenbank mit PostGIS
Erweiterung für die Datenhaltung.
Aufbauend auf den erarbeiteten Erkenntnissen der Praktikumsarbeit beschäftigt sich die Dip-
lomarbeit mit der Leistungsfähigkeit und Performance von UMN-Mapserversystemen. In ei-
nem Netzwerklabor werden mit Hilfe von Zeitmessungen verschiedene Einstellungen und
Varianten getestet und anschließend verglichen.
1.1. Problemstellung
Der UMN-Mapserver ist geeignet, Kartengrafiken auf Basis von räumlichen Daten zu gene-
rieren. Seine Kompatibilität zu zahlreichen Datenformaten, Datenbanken, Programmierspra-
chen und anderen Systemen ist sehr groß. Außerdem sind durch die offene Programmstruktur
zahlreiche Möglichkeiten der manuellen Einstellung gegeben. Somit kann das System indivi-
duell eingerichtet werden.
7

Diplomarbeit Johann Zettel
Diese Häufung von Vorteilen bringt einen wesentlichen Nachteil mit sich. Da das gesamte
System sehr komplex ist, ist es schwer, alle Auswirkungen und Zusammenhänge in Bezug auf
verschiedene Einstellungen zu erkennen und zu analysieren. Dieser Nachteil äußert sich in der
Analyse folgendermaßen:
Performance
Unter Performance versteht man in diesem Bereich die Geschwindigkeit der Karten-
renderung oder die Geschwindigkeit einer Datenabfrage. Lässt die Performance nach,
verlängert sich die Dauer des Vorgangs. In der Praxis ist diese Performanceeinbuße
beim Seitenaufbau im Webbrowser zu erkennen. Das bedeutet, die Dauer, in der die
Seite vollständig geladen wird, verlängert sich und der Benutzer muss warten.
Stabilität
Hierbei handelt es sich um die Robustheit und Standfestigkeit eines Systems. Wenn
das System durch äußere oder innere Einflüsse einen instabilen Zustand erreicht, funk-
tioniert das System nicht mehr ordnungsgemäß.
Diese Arbeit beschäftigt sich hauptsächlich mit dem ersten Punkt. Da aber eine Trennung
dieser zwei Themengebiete nicht zielführend ist, wird auch in Teilbereichen die „Stabilität“
analysiert.
1.2. Zielsetzung
Das Ziel dieser Arbeit ist die Entwicklung von Empfehlungen zur Optimierung der Perfor-
mance in Bezug auf UMN-Mapserversysteme. Mit Hilfe eines Netzwerklabors sollen unbe-
einflusst und objektiv verschiedene Einstellungen getestet werden. Die resultierenden Tester-
gebnisse werden verglichen und analysiert. Daraus lassen sich danach Aussagen erarbeiten,
wie das System in bestimmten Situationen optimiert werden kann. Es werden praxisbezogene
Themenbereiche untersucht.
1.3. Arbeitsablauf
Die Umsetzung der vorhin beschriebenen Ziele der Arbeit kann in vier Hauptblöcke geglie-
dert werden. Da die Ergebnisse der einzelnen Arbeitsblöcke in den darauf folgenden Block
8

Diplomarbeit Johann Zettel
einfließen, ist die Reihenfolge der einzelnen Schritte einzuhalten. In Abb. 1 ist der Arbeitsab-
lauf grob skizziert.
Abb. 1 – Arbeitsablauf des Projektes
Planung
Der erste Arbeitsblock beschäftigt sich mit der Planung der Tests und des Testlabors.
Es werden die Anforderungen und Eigenschaften festgelegt, um objektive Tests durch-
führen zu können.
Entwicklung
In der Entwicklung wird das Testlabor nach den Vorgaben der Planung eingerichtet.
Der Server sowie der Client-Rechner werden installiert und vorbereitet. Außerdem
wird die Testapplikation programmiert und der Testdatensatz ausgewählt und ange-
passt.
Durchführung
Dieser Teil beinhaltet die Durchführung der Tests. Die Testapplikation wird gestartet
und führt die Anfragen an den Server aus. Falls die Notwendigkeit besteht, werden zu-
sätzlich Korrekturen, wie zum Beispiel ein Filter, vorgenommen.
Analyse
Die gemessenen Geschwindigkeiten werden in der Analyse bearbeitet. Testergebnisse
werden verglichen und Gründe für eventuelle Abweichungen werden analysiert. Da-
nach werden Empfehlungen entwickelt, die die Performance in ausgewählten Situatio-
nen erhöhen.
9

Diplomarbeit Johann Zettel
Iterativer Vorgang
Nach Ablauf der Analyse und der daraus resultierenden Optimierungsmöglichkeiten
werden diese noch einmal getestet. Anschließend werden sie ausgewertet und vergli-
chen, ob ein Performancezuwachs erkennbar ist.
1.4. Systemabgrenzung
Die größte Einschränkung dieser Arbeit ist der Umfang der zu testenden Bereiche. Diese Ar-
beit erhebt keinen Anspruch auf Vollständigkeit. Es werden lediglich beispielhafte Standard-
situationen gewählt. Nur diese werden gestestet und untersucht. Diese Abgrenzung ist not-
wendig, um objektiv testen, vergleichen und analysieren zu können. Das bedeutet, dass nicht
alle möglichen Kombinationen von Einstellungen und Systemkomponenten bearbeitet bzw.
aufgezeigt werden.
10

Diplomarbeit Johann Zettel
2. Formulierung der Hypothese
Die Performance eines UMN-Mapserversystems verändert sich, wenn Einstellungen oder die
Systemumgebung variiert werden. Diese Annahme bietet die Basis der Hypothese. Daher
muss es möglich sein, Einstellungen oder Systemumgebungen so zu wählen, dass die Perfor-
mance optimiert werden kann. Dies bezieht sich allerdings immer auf konkrete Situationen.
Nur wenige Einstellungen werden generell eine Optimierung bewirken. Weiters ist festzuhal-
ten, dass jede Einstellung oder Veränderung, die die Performance steigert, auch wiederum
eine nachteilige Wechselwirkung verursachen kann.
Im konkreten können folgende Annahmen getroffen werden, die jeweils Teilbereiche des
UMN-Mapserversystems betreffen.
Das Mapfile des UMN-Mapservers beinhaltet eine Vielzahl an Einstellungsmöglichkeiten. Es
wird angenommen, dass bestimmte Einstellungen Auswirkungen auf die Performance haben.
Besonders viel Performancepotenzial wird in den Bereichen Antialiasing, Ausgabeformat und
Projektionsumrechnung angenommen.
Die Wahl der Datenhaltung des Datenzugriffs betrifft auch die Leistungsfähigkeit. Räumliche
Daten in Dateiform oder in Datenbankform haben unterschiedliche Eigenschaften. Daher wird
angenommen dass damit die Performance des Gesamtsystems beeinflusst wird.
11

Diplomarbeit Johann Zettel
3. Stand der Technik
Dieser Teil der Arbeit wird einen Überblick über die Technologien geben, die derzeit in aktu-
ellen Systemen Anwendung finden. Vorwiegend werden UMN-Mapserver spezifische Ele-
mente beschrieben und erklärt. Um den Überblick zu wahren, wird auch auf Allgemeines ein-
gegangen.
3.1. Begriffsbestimmung
ASCII - American Standard Code for Information Interchange
Dieser amerikanische Standard wurde in den Sechziger-Jahren entwickelt. Es handelt
sich dabei um eine 7-Bit Zeichenkodierung, welche 33 nichtdruckbare sowie 95 druck-
bare Zeichen enthält [BRODMÜLLER-SCHMITZ 2002].
CGI - Common Gateway Interface
Mit Hilfe einer CGI-Schnittstelle können Scripte oder Programme im Internet bereit-
gestellt werden. Sie können zum Beispiel aus einem HTML-Dokument aufgerufen
werden und selbst wieder HTML-Code ausgeben. CGI-Programme können in vielen
Sprachen wie zum Beispiel Perl oder Python geschrieben werden.
DBMS - Datenbank-Managementsystem
Ein DBMS organisiert physisch eine zusammenhängende Menge von Daten - die Da-
tenbank -, durch die den unterschiedlichen Informationsbedürfnissen eines Unterneh-
mens Rechnung getragen werden soll. Es kombiniert einen Satz von Computerpro-
grammen zur Organisation der Informationen. Mit einem DBMS wird die Sicherheit,
Integrität und Konsistenz der Daten bei minimierter, kontrollierter Redundanz gewähr-
leistet. Durch die Integration der Daten und die Kontrolle des Zugriffs auf die Daten
durch ein DBMS können die Daten durch viele Benutzer gleichzeitig genutzt werden
[ROSTOCK 1 2007].
12

Diplomarbeit Johann Zettel
GIS - Geographic Information System
Ein GIS ist ein IT-System, welches aus Hardware, Software, Daten und einer Applika-
tion besteht. Zur Aufgabe dieser Systeme zählt das Erfassen, das Reorganisieren, das
Verwalten, das Verarbeiten, das Analysieren und das Aufbereiten bzw. Visualisieren
von raumbezogenen Daten.
HTTP - Hypertext Transfer Protocol
HTTP ist ein Protokoll, welches die Übertragung von Daten über ein Netzwerk regelt.
Im ISO/OSI-Schichtenmodell gehört dieses Protokoll der Anwendungsschicht
(Schicht 7) an. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus
dem Internet in einen Webbrowser zu laden.
MBR - Minimum Bounding Rectangle
Das MBR ist ein zu den Hauptachsen paralleles Rechteck, welches geometrische Ob-
jekte umschließt. Dadurch können komplizierte Geometrien leichter angesprochen
werden. Dies wirkt sich in einer Performancesteigerung in der Verarbeitung von die-
sen Objekten aus.
OGC - Open Geospatial Consortium
Das Open Geospatial Consortium ist eine 1994 gegründete gemeinnützige Organisati-
on, die sich zum Ziel gesetzt hat, die Entwicklung von raumbezogener Informations-
verarbeitung (insbesondere Geodaten) auf Basis allgemeingültiger Standards zum
Zweck der Interoperabilität festzulegen [WIKI 1 2007].
Open-Source
Open-Source wird Software bezeichnet, wenn ihr Quellcode der Öffentlichkeit zu-
gänglich ist. Meistens steht diese Software unter einer Open-Source-Lizenz, die die
Veröffentlichung und Weitergabe regelt.
Koordinatentupel
Der mathematische Begriff n-Tupel bezeichnet zusammengehörige Elemente. Ein 2-
Tupel wird häufig auch einfach nur als Tupel bezeichnet. Weiters kann auch ein 3-
Tupel ein Tripel genannt werden. Sind die zwei Elemente eines Tupels Koordinaten,
13

Diplomarbeit Johann Zettel
kann von einem Koordinatentupel gesprochen werden. In diesem Fall würde ein
Koordinatentupel einen Punkt in der Ebene definieren.
Quadratminute
Eine Quadratminute ist ähnlich wie ein Quadratkilometer ein Flächenmaß. Dabei hat
eine Seite des Quadrats die Länge einer Bogenminute auf einer Referenzfläche. Diese
Referenzfläche kann eine Kugel, aber auch ein Ellipsoid sein.
HTTP-Server
Ein HTTP-Server oder auch Webserver genannt ist ein Server, der Informationen über
das Hypertext Transfer Protocol (HTTP) einem Netzwerk zur Verfügung stellt.
WMS - Web Map Service
WMS ist ein Standard für das Veröffentlichen von Karten im Internet. Er ist Grundla-
ge für eine Geodateninfrastruktur. Ein WMS-Server implementiert folgende Funktio-
nen:
o GetCapabilities – Liefert die Fähigkeiten des Servers zurück. Zum Beispiel
welcher Layer oder welcher Kartenausschnitt zur Verfügung steht.
o GetMap – Liefert die Karte meist in Grafikform zurück.
o GetFeatureInfo – Verarbeitet Anfragen bezüglich der Sachdaten von räumli-
chen Objekten.
XML - Extensible Markup Language
Im Gegensatz zu HTML beschreibt XML nicht das Aussehen von Inhalten sondern die
Inhalte selbst. Die Daten werden in einer Baumstruktur abgelegt. Das World Wide
Web Consortium betreut diesen Standard
3.2. Web Visualisierung
Der folgende Teil der Arbeit handelt von den Möglichkeiten der Visualisierung von raumbe-
zogenen Informationen im Internet. Zu Beginn werden unterschiedliche Typen der Umset-
zung und in weiterer Folge genauer die einzelnen Technologien erklärt. Erwähnt werden vor-
14

Diplomarbeit Johann Zettel
wiegend Techniken, die sehr oft im Zusammenhang mit dem UMN-Mapserver Anwendung
finden.
3.2.1. Präsentationsformen
Um raumbezogene Daten im Internet zu visualisieren, gibt es viele Varianten. Die Benutzer-
schnittstellen unterscheiden sich vorwiegend in ihrer Funktionalität und Qualität der Karten.
Das übrige System, welches einem User nicht sichtbar ist, kann sich in einer Vielzahl von
Eigenschaften unterscheiden. Unterschiedlichste Technologien und Architekturen kommen im
heutigen System zum Einsatz. Folgende Unterteilung strukturiert die verschiedenen Arten:
Statische Karten
Eine rein statische Karte ist zum Beispiel ein eingescanntes analoges Bild. Die Grafik
wurde einmal erstellt und hat sich seit diesem Zeitpunkt nicht mehr verändert. Es steht
keine Interaktivität für den Benutzer zur Verfügung. Es gibt nur noch sehr wenige sta-
tische Karten im Internet, da der direkte Mehrnutzen nur geringfügig ist.
Dynamische Karten
Eine im Internet sehr weit verbreitete Variante ist die dynamisch generierte Karte. Sie
wird erst auf Anfrage des Users generiert. In der Praxis wählt der User die Karte mit-
tels eines Webbrowsers an. Der Server generiert das Bild nach Wunsch der Anfrage
und schickt es an den User zurück. Auf diese Weise sind Kartenfunktionalitäten wie
zum Beispiel Zoom-Funktion, Pan-Funktion oder Layer-Funktionalitäten möglich.
WebGIS-Applikation
Eine um Gis-Funktionalität erweiterte Dynamische Karte kann als WebGIS bezeichnet
werden. Sachdaten stehen mit räumlichen Daten in Verbindung und können abgefragt
werden. In dieser Applikation können auch räumliche Funktionen wie zum Beispiel
Verschneidungen, Buffer oder Selektionen integriert sein.
Eine genauere Unterscheidung und weitere Untergliederung ist schwierig und auch nicht ziel-
führend. Da sich diese Thematik sehr schnell entwickelt und in der Praxis meist Mischformen
Anwendung finden, verändern sich die Kategorien sehr schnell.
15

Diplomarbeit Johann Zettel
3.2.2. Kartengenerierungstools
Die Kartengenerierung ist Mittelpunkt von dynamischen Karten, WebGIS-Applikationen und
auch dieser Arbeit. Ein Mapserver kann Karten in Form von Grafiken generieren. Er benötigt
jedoch dafür ein geeignetes Umfeld, wie zum Beispiel die richtige Plattform oder die benötig-
ten räumlichen Daten. Im Folgenden werden einige relevante Mapserversysteme vorgestellt:
UMN-Mapserver
Der UMN (University of Minnesota) Mapserver ist ein Open-Source-Projekt und wird
von der Open Source Geospatial Foundation weiterentwickelt. Diese Software ver-
wendet weitere Open-Source- Module wie zum Beispiel Shapelib, FreeType, Proj.4,
GDAL/OGR, um dynamische Karten zu generieren.
ESRI ArcIMS
Der Mapserver des Unternehmens ESRI ist eine proprietäre Software. Er ist eng mit
der übrigen GIS-Software von ESRI verknüpft. Die Webseite, in der die Grafik einge-
bettet wird, muss programmiert werden. Lediglich ein Framework mit Grundfunktio-
nalitäten wird bereitgestellt.
Geomedia WebMap
Geomedia-WebMap vom Unternehemen Intergraph ist ein proprietärer Mapserver, der
eine Kartengrafik bereitstellen kann. Wie bei den anderen erwähnten Produkten muss
das Framework selbst gestaltet werden. Allerdings existieren auch für Geomedia ko-
mmerzielle Frameworks, die mit dem Mapserver zusammenarbeiten können [INTER-
GRAPH 2005].
3.2.3. Grafikformate
Eine Webapplikation benötigt Grafiken um Informationen zu visualisieren. In dieser Arbeit
handelt es sich um Räumliche Informationen, die als Karten in die Webapplikation eingebun-
den werden. Grafiken lassen sich in folgende zwei Typen unterteilen, die sich in ihrem Auf-
bau und damit in der Dateigröße und Verwendung voneinander unterscheiden.
16

Diplomarbeit Johann Zettel
Vektorgrafiken
Vektorgrafiken sind aus Vektoren aufgebaut, das heißt, die einzelnen Elemente wer-
den mathematisch beschrieben. Für eine Linie sind zum Beispiel ein Startpunkt, die
Richtung und die Länge anzugeben, ein Kreis wird durch seinen definierten Mittel-
punkt und seinen Radius beschrieben. Durch diese Art der Beschreibung eignen sich
Vektorgrafiken besonders für Strichzeichnungen, nicht hingegen für komplexere Gra-
fiken wie Fotos oder Bilder. Diese könnte man zwar auch mit Vektoren beschreiben,
was jedoch nicht sinnvoll wäre, da die Anzahl der einzelnen Vektoren in einem sol-
chen Fall extrem groß sein würde. Der Vorteil von Vektorgrafiken liegt darin, dass sie
problemlos zu skalieren sind. Dabei werden die einzelnen Vektoren entsprechend der
vorhandenen Größe neu errechnet und dargestellt. Ein weiterer Vorteil ist die Datei-
größe. Ist die Grafik entsprechend aufgebaut, kann Speicherplatz im Vergleich zu ei-
ner Rastergrafik gespart werden [BRODMÜLLER-SCHMITZ 2002].
Ein großer Nachteil von Vektorgrafiken in Webapplikationen ist die Unterstützung in
gängigen Browsern. Oft ist ein Plug-In notwendig um die Grafik darzustellen. Durch
diese Eigenschaften wird die Nutzergruppe im praktischen Einsatz eingeschränkt. Es
folgt eine Aufzählung von Vektorformaten, die im Internet gängig sind:
PDF - Portable Document Format
Das PDF-Format der Firma Adobe Inc. ist sowohl für Monitordarstellung als auch für
den Papierausdruck entwickelt worden. Infolge seiner hohen Auflösung bei gleichzei-
tig starker Datenkompression ist es hervorragend für die Kartendarstellung geeignet
[DICKMANN 2001].
In der Regel werden jedoch PDF-Grafiken nicht in die Webseite eingebunden, sondern
werden statisch in einem eigenen Programm geladen. Für WebGIS-Applikationen eig-
net sich dieses Format nur eingeschränkt.
SVG Scaleable Vector Graphics
Scaleable Vector Graphics ist ein Grafikstandard, mit dem Scripte verfasst werden
können, die Bilder exakt beschreiben [BADER 2004]. Dieses XML- basierende Datei-
format wurde vom W3C veröffentlicht und eignet sich sehr gut für Kartendarstellun-
17

Diplomarbeit Johann Zettel
gen. Da es sich um ASCII-Textfiles handelt, können herkömmliche Komprimierungs-
verfahren die Speichergröße stark reduzieren und somit die Dauer des Datentransfers
verringern. Zusätzlich zu statischen Grafiken kann auch Animation und Logik mittels
Scriptsprachen eingebaut werden. Es wird ein SVG- Plug-In von Adobe oder Corel
benötigt, um SVG in einem Webbrowser zu betrachten. Nur der Webbrowser Firefox
ab der Version 1.5 unterstützt nativ Teile der SVG- Funktionalität.
SWF - Small Web Format
Small Web Format ist ein proprietäres Vektorformat, welches von dem Unternehmen
Adobe Systems weiterentwickelt wurde. Um SWF in einem Webbrowser betrachten
zu können, ist wie bereits bei den vorhin erwähnten Vektorgrafiken ein Plug-In von
Adobe nötig.
Viele mit Flash erstellte Karten fallen auch in die Kategorie der animierten Webkar-
ten, da die Erstellung von Animationen mit Hilfe der vielen Funktionen von SWF sehr
einfach zu gestalten ist [FÜRPASS 2001].
Rastergrafiken
Neben der Vektorgrafik existiert mit der Rastergrafik ein weiteres Grafikmodell, das
auch unter den Bezeichnungen Bitmapgrafik oder Pixelgrafik bekannt ist. In einer
Rastergrafik werden einzelne Informationen über jeden Bildpunkt (Pixel) definiert,
und nicht wie bei der Vektorgrafik über ganze Elemente. Die Aufteilung in Bildpunkte
ist für die Bildschirmanzeige sehr gut geeignet, da diese auch auf einem Raster basiert.
Beim Skalieren verhält sich eine Rastergrafik anders als eine Vektorgrafik. Die Bild-
punkte werden beim Vergrößern verdoppelt, was zu ungewollten Effekten führen
kann. Eine Rastergrafik lässt sich also nicht ohne Qualitätsverlust skalieren.
Um die Dateigröße von Rastergrafiken zu verringern, werden Komprimierungsverfah-
ren eingesetzt, die auf unterschiedlichen Methoden beruhen. Dabei lassen sich verlust-
freie und verlustbehaftete Kompressionen unterscheiden [BRODMÜLLER-SCHMITZ
2002].
18

Diplomarbeit Johann Zettel
Die wichtigsten Rastergrafikformate sind folgende:
GIF - Graphics Interchange Format
Das von CompuServer 1987 entwickelte GIF ist ein Standard-Bildformat im Internet.
Es kann im Gegensatz zu vielen anderen Bildformaten auf fast allen Plattformen ver-
wendet werden. Es hat den Vorzug, nicht nur schnell heruntergeladen, sondern auf-
grund des Zeilensprungverfahrens (Interlacing) zudem beim Bildaufbau bereits wäh-
rend dieses Vorgangs, grob zur Ansicht gebracht werden zu können [DICKMANN
2001]. Ein weiterer Vorteil ist, dass die Möglichkeit besteht GIF-Bilder zu animieren.
JPEG - Joint Photographic Experts Group
JPEG Bilder erlauben eine Darstellung von 24 Bit. Daher können mehr als 16 Millio-
nen Farben dargestellt werden [FÜRPASS 2001]. Im Gegensatz zum GIF setzt das
JPEG eine verlustbehaftete Komprimierung ein, dies kann sich in der Verschlechte-
rung der Qualität auswirken.
PNG - Portable Network Graphics
Das Portable Network Graphics Format wurde speziell für den Einsatz im Internet als
patentfreies Datenformat entwickelt. Im Gegensatz zu GIF kann sein Quellcode abga-
benfrei verwendet werden. Es vereinigt Vorteile von GIF und JPEG. PNG kompri-
miert verlustfrei, kann progressiv aufgebaut werden und sein Farbumfang erstreckt
sich über 48 Bit Farbtiefe [DICKMANN 2001].
TIFF - Tagged Image File Format
Das TIFF-Format wurde ursprünglich von Aldus und Microsoft für gescannte Raster-
grafiken für die Farbseparation entwickelt. In einer Datei können mehrere Bilder abge-
legt werden. Dies kann zum Beispiel beim Kacheln großer Bilder Verwendung finden.
Größter Nachteil von TIFF ist seine Komplexität. Die Vielfalt möglicher gültiger
TIFF-Dateien kann von keinem einzelnen Programm unterstützt werden [WIKI 2
2007].
19

Diplomarbeit Johann Zettel
Im Folgenden wird die Speicherung zwischen Vektorgrafiken und Rastergrafiken verglichen:
Abb. 2 - Vergleich Vektor-Rastergrafik
Abb. 2 zeigt einen Vergleich zwischen Vektor- und Rastergrafik. Stark vereinfacht wird ein
ähnliches Bild einmal mit Vektoren und einmal in einem Raster dargestellt. Auf der rechten
Seite der Abbildung befinden sich vereinfacht die Daten, die notwendig sind, um eine solches
Bild abzuspeichern. Bemerkenswert ist der Unterschied der Datenmenge beider Systeme. Die
Vektorgrafik benötigt in diesem Fall um vieles weniger Daten als das Rastersystem. Wird die
Grafik jedoch komplexer, vergrößert sich auch die Datenmenge einer Vektorgrafik. Die Da-
tenmenge eines Rasterbildes ist hingegen von der Komplexität der Grafik unabhängig. Nur
die Auflösung des Rasters beeinflusst die Datenmenge. Dies gilt jedoch nicht, wenn die Ras-
tergrafik komprimiert wird, dabei ist diese Komplexität sehr wohl ein Faktor der Dateigröße.
20

Diplomarbeit Johann Zettel
3.2.4. Antialiasing
Bei der Rasterung von Vektordaten tritt der Aliasing-Effekt auf. Es soll ein mathematisch
unendlich genaues Objekt auf ein endlich genaues Raster abgebildet werden. Dieses Abtast-
problem hat zur Folge, dass ein unerwünschter Treppeneffekt entstehen kann.
In Abb. 3 ist eine schrägliegende Linie zu sehen, welche auf dem Raster abgebildet werden
soll.
Abb. 3 – Rasterung eines Vektors, Quelle: [3DCenter 2007]
Wird wie in Abb. 4 zu sehen ohne Antialiasing gerastert, wird der Wert, der in einem Pixel
am meisten Platz einnimmt, als neuer Pixelwert abgespeichert.
Abb. 4 - Aliasing-Effekt, Quelle: [3DCenter 2007]
Im Antialiasing-Prozess werden hingegen wie in Abb. 5 zu erkennen die Farben anteilsweise
in den neuen Wert übernommen. Dies hat zur Folge, dass die Übergänge besser dargestellt
werden. Dieser Prozess ist sehr rechenaufwändig. Durch geometrische Berechnungen muss
die eingenommene Fläche jedes Polygons ermittelt werden.
21

Diplomarbeit Johann Zettel
Abb. 5 - Antialiasing, Quelle: [3DCenter 2007]
Zusätzlich zur erhöhten Rechenleistung muss das Bild eine passende Farbskala aufweisen. Da
Zwischenwerte von Farben benötigt werden, muss das Bildformat diese unterstützen. Das
erhöht wiederum die Speichergröße des Bildes.
3.2.5. Web-Programmierung
In diesem Kapitel werden ausgewählte Technologien vorgestellt und erläutert, die verwendet
werden, um Informationen im Internet bereitzustellen. Um Funktionen in WebGIS-
Applikation zu implementieren, sind eine Reihe von Technologien notwendig. Diese hier be-
schriebenen Techniken beziehen sich auf eine Umsetzung mit dem UMN-Mapserver.
HTML - Hypertext Markup Language
Die Hypertext Markup Language ist eine ASCII basierende Auszeichnungssprache,
welche die Darstellung sowie die Inhalte von Text, Bildern, Hyperlinks und anderen
Medien in Dokumenten regelt. HTML-Dokumente können in einem Webbrowser dar-
gestellt werden und bilden die Basis des Internets.
CSS - Cascading Style Sheets
Mit Hilfe von Cascading Style Sheets wird das Erstellen von Formatvorlagen für ein-
zelne Webseiten oder ganze Websites ermöglicht. Es können Angaben zur Gestaltung
zentral verwaltet und gespeichert werden [BRODMÜLLER-SCHMITZ 2002].
Javascript
Javascript ist ein integrierter Bestandteil von HTML zur Gestaltung interaktiver Sei-
ten. Es handelt sich dabei um eine Scriptsprache, die clientseitig interpretiert wird. Die
22

Diplomarbeit Johann Zettel
Befehle können entweder im HTML-Dokument selbst integriert werden oder in eine
eigene Datei ausgelagert werden [BRODMÜLLER-SCHMITZ 2002]. In einer Web-
GIS-Applikation werden so die Kartenfunktionalitäten implementiert.
Serverseitige Dynamische Datengenerierung am Beispiel von PHP
PHP ist eine Scriptsprache, die serverseitig interpretiert wird und frei als Open-
Source-Projekt zur Verfügung steht. Mit ihr ist es möglich, Inhalte von Webseiten
voll-dynamisch zu befüllen.
Wie Abb. 6 zeigt, setzt der User zu Beginn mittels Webbrowser eine Anfrage an den
Webserver ab. Dort wird das gewünschte PHP Script dem PHP Interpreter übergeben.
Der Interpreter liefert ein Ergebnis, z.B. ein HTML, XML oder PDF Dokument, das
vom Webserver wieder an den Browser zurück gesendet wird.
Abb. 6 - PHP Interpretation
Mapscript
Diese Erweiterung greift auf die Programmierschnittstelle (API) des UMN-
Mapservers zu. Es können mittels Mapscripts fast alle UMN- Mapserver- Fähigkeiten
in eine Applikation integriert werden. Implementiert ist diese Erweiterung für mehrere
Programmier- und Script- Sprachen, unter anderem für C#, Java, PHP, Python und
Ruby.
Ein PHP- Script, welches ein vom UMN- Mapserver generiertes Bild einbindet, wird
in Codebeispiel 1 gezeigt. In weiterer Folge können alle Einstellungen am Mapfile
23

Diplomarbeit Johann Zettel
verändert und beigefügt werden. Auf diese Weise kann die Karte dynamisch verändert
und erzeugt werden. Außerdem können Daten jeglicher Art von Datenbanken abgeru-
fen und ein-gebunden werden.
// Einbindung der Mapscript Bibliothek
dl('php_mapscript_48.dll');
// Einbindung des Mapfiles
$map = ms_newMapObj("test.map");
// Erzeugen des Bildes
$image=$map->draw();
// Übergabe der Speicheradresse des Bildes an eine Variable
$image_url=$image->saveWebImage();
// Generierung des HTML Codes
echo("");
echo("");
echo("");
echo("");
echo("");
echo("");
//Einbindung des vom Mapserver generierten Bildes
echo("");
Codebeispiel 1 - PHP Mapscript - Codebeispiel
3.3. Räumliche Daten
Im folgenden Kapitel werden einige unterschiedliche Formen der Abspeicherung von räumli-
chen Daten erläutert. Es soll ein Überblick über die derzeit verwendeten Datentypen vermit-
telt werden. Grundsätzlich können sich räumliche Daten aus folgenden Teilmengen zusam-
mensetzen:
Geometriedaten
„Die Geometrie von räumlichen Objekten wird durch die Form und relative Lage von
Punkten vollständig beschrieben. Für diese Beschreibung können zum Beispiel Dis-
tanzen und Winkel verwendet werden, in der Regel wird allerdings auf Koordinaten
24

Diplomarbeit Johann Zettel
übergegangen, womit die Wahl eines Bezugssystems und die Metrik festliegt.“ [BILL
1 1999]
Topologiedaten
Innerhalb der Topologie ist wichtig, dass Punkte und Linien in einer bestimmten ge-
genseitigen Beziehung stehen, und nicht die geometrische Form dieser Beziehungen.
Der Punkt ist Träger der geometrischen Information. Linien und Flächen können als
Folge charakteristischer Punkte betrachtet werden. Der Unterschied zwischen Geomet-
rie und Topologie liegt darin, dass sich die Topologie eines räumlichen Gebildes inva-
riant gegenüber topologischen Transformationen verhält. Während sich die Geometrie
verändert [BILL 1 1999]. Am Beispiel eines U-Bahn-Plans wird der Unterschied
nochmals verdeutlicht. Vergleicht man einen Stadtplan und einen Schemaplan in Be-
zug auf das U-Bahn-Netz wird deutlich, dass sich die Geometrien verändert haben a-
ber die Topologie gleich geblieben ist.
Sachdaten
Als Sachdaten werden alle zusätzlichen Daten bezeichnet. Diese Daten stehen in enger
Verbindung mit Geometrien und können unterschiedlichen Inhalt haben. Normal sind
diese Art von Daten konventionelle, tabellarisch aufgelistete Werte, die ohne eine Ver-
bindung zu Geometrien nur einen möglichen indirekten räumlichen Bezug aufweisen.
Wie auch im Kapitel der verschiedenen Grafiktypen beschrieben, sind auch hier ein Raster-
system und ein Vektorensystem als Abspeicherungsformen unterscheidbar. Zum Unterschied
zu den Grafiktypen geht es bei diesen Formaten nicht um die Präsentation sondern um die
Speicherung der Daten.
3.3.1. Räumliche Vektordaten
Unter Vektordaten wird die auf Punkten beruhende Beschreibung von raumbezogenen Objek-
ten verstanden. Ihre Grundelemente sind der Punkt, die Linie und die Fläche. Ferner werden
noch Topologiebeziehungen angegeben, wie zum Beispiel Anfangs- und Endpunkt einer Li-
nie sowie daran angrenzende Flächen [BILL 1 1999]. Zum Beispiel besteht eine Linie, sofern
sie keine Zwischenpunkte besitzt, aus zwei Koordinatentupel. Um diese Koordinaten sinnvoll
25

Diplomarbeit Johann Zettel
verarbeiten zu können, sind Hintergrundinformationen wie zum Beispiel das Bezugssystem
zwingend notwendig.
Vorteile von Vektordaten sind die hohe Genauigkeit, der geringe Speicherbedarf und die ein-
fache topologische Abspeicherung. Im Gegenzug wären Nachteile die komplizierte Handha-
bung, der große Rechenleistungsbedarf beim Verarbeiten und die schwierige Ersterzeugung
von Daten [RUDEL 2003].
In folgenden zwei Kapiteln werden unterschiedliche Vektordaten erläutert, die sich in ihrer
Speicherform unterscheiden. Es wurden lediglich beispielhaft Formate gewählt, die im Mo-
ment in der Praxis eingesetzt werden.
Daten in Dateiform
Räumliche Daten in Dateiform zu halten ist sehr gebräuchlich und einfacher als eine
Datenbankspeicherweise. Da Dateien einfach zu handhaben sind, eignen sie sich sehr
gut zum Datenaustausch. Nachteile von Dateien sind, dass es keine Zugriffs- und
Transaktionskontrolle gibt. Außerdem wird die Speicherung von großen Datenmengen
unpraktisch und durch das Filesystem begrenzt. Im Folgenden werden wichtige Daten-
formate beschrieben:
o GML - Geography Markup Language
GML wurde von OGC entwickelt. Das Fileformat wurde in der Version 2 bereits
von ISO als Standard aufgenommen. Die Hauptaufgabe dieses Formats ist der Aus-
tausch von räumlichen Daten. Da es auf XML beruht, ist es ideal dafür geeignet.
Nachteil dabei ist, dass XML unkomprimierter, reiner Text ist, und somit die Spei-
cherung großer Datenbestände sehr speicheraufwändig und beim Bearbeiten sehr
leistungsaufwändig ist.
o SHAPE
Das Shapefile Format wurde von ESRI für ArcView entwickelt und hat sich in den
letzten Jahren zu einem Standard im Geoinformatik-Markt etabliert. Es besteht aus
mindestens drei Dateien, welche jeweils die Geometrien, den Räumlichen Index
und die Sachdaten beinhalten. Weitere Dateien können zusätzliche Informationen
26

Diplomarbeit Johann Zettel
wie zum Beispiel die dazugehörige Projektion beinhalten. In jedem Shapefile kön-
nen entweder Punkte, Linien oder Polygone abgespeichert werden [ESRI 1998].
o DXF - Drawing Exchange Format
Das Drawing Exchange Format wird als ASCII-Text abgespeichert und hat sich
ähnlich wie das SHAPE-Format als ein Standard im CAD-Markt etabliert. Es wur-
de von Autodesk für das Produkt AutoCAD entwickelt und wird ständig weiter-
entwickelt. Da das Format sehr wenig Funktionalität implementiert, eignet es sich
für GIS-Applikationen nur sehr eingeschränkt, aber ist für WebGIS-Applikationen
meist ausreichend.
o TAB, MIF/MID
TAB ist das native, binäre Speicherformat von MapInfo. MIF und MID sind hin-
gegen die nichtbinären Austauschformate von MapInfo zu anderen Programmen.
Die MIF- Datei enthält sowohl die Metadaten und Feature Definitionen als auch
die Koordinaten. Die MID Datei enthält die trennzeichenunterteilten Attribute.
[GISWIKI 2006]
Daten in Datenbankform
Komplexere und größere räumliche Datenbestände werden in der Regel in Datenban-
ken abgespeichert. Dazu benötigt die Datenbank erweiterte Funktionen, die sie von
herkömmlichen Systemen unterscheiden. Da die allgemeinen Vorzüge von Datenban-
ken auch bei räumlichen Daten Verwendung finden, entwickeln immer mehr Daten-
bankhersteller diese Erweiterungen, um diese Art von Daten verarbeiten zu können.
Im Gegensatz zu einzelnen Dateien eignen sich Datenbanken nicht sehr gut zum Da-
tenaustausch. Um einen Austausch durchführen zu können, müssen die Daten einer
Datenbank erst exportiert werden und danach wieder in eine kompatible Datenbank
importiert werden, während normale Dateien einfach kopiert werden.
o PostGIS
PostGIS wird von Refractions Research Inc. entwickelt und ist eine Erweiterung
für die OpenSource-PostgreSQL Objektrelationale-Datenbank. Diese Erweiterung
27

Diplomarbeit Johann Zettel
erlaubt der Datenbank das Speichern räumlicher Daten in Form von Objekten.
PostGIS unterstützt einen Gist und R-Tree als räumliche Indizes und inkludiert ei-
ne Reihe von Funktionen und Analysemethoden für räumliche Daten.
o Oracle Spatial
Oracle Spatial ist eine sehr fortschrittliche und umfangreiche Erweiterung einer
Oracle Datenbank, welche räumliche Funktionalitäten beinhaltet. Zusätzlich zu
räumlichen Datentypen und Funktionen stehen auch weitere Module wie zum Bei-
spiel Geocodierungs oder Routing Engines zur Verfügung [Oracle 2005]. Oracle
ist ein kostenpflichtiges Produkt.
o MySQL
Wie PostgreSQL ist auch MySQL ein Open-Source-Projekt und wird vom Unter-
nehmen MySQL AB betreut. Hauptanwendungsgebiet dieses DBMS sind Webser-
ver, da sie einfach zu bedienen und zusätzlich sehr performant sind. In der Version
5 stehen erstmalig zu dem eigentlich recht sparsamen Funktionsumfang von
MySQL auch räumliche Komponenten zur Verfügung. So können beispielsweise
Punkte oder Linien abgelegt werden. Jedoch ist diese Erweiterung noch sehr einge-
schränkt und ist nicht vergleichbar mit anderen räumlichen Datenbankerweiterun-
gen wie zum Beispiel PostGIS. [MYSQL 2007]
o ArcSDE
ArcSDE ist eine sehr umfangreiche Erweiterung für die Datenbanken Oracle,
Microsoft SQL Server, IBM DB2 und IBM Informix. Vorwiegend ermöglicht die-
se Erweiterung ArcGis den Zugriff auf diese Datenbanken, um räumliche Daten
abzuspeichern [ESRI 2007]. ArcSDE ist ein kostenpflichtiges Produkt.
3.3.2. Räumliche Rasterdaten
Im Gegensatz zu Vektordaten beziehen sich die Rasterdaten direkt auf Flächen statt auf Li-
nien. Das geometrische Grundelement ist das Pixel, welches zeilen- und spaltenweise in einer
Matrix gleichförmiger quadratischer oder rechteckiger Elemente angeordnet ist und einheitli-
che Flächenfüllung aufweist. Rasterdaten kennen keinen Unterschied nach Punkt, Linie oder
28

Diplomarbeit Johann Zettel
Fläche, das heißt es existieren keine logischen Verbindungen zwischen den einzelnen Bild-
elementen. Rasterdaten enthalten lediglich Werte über Eigenschaften der Pixel [BILL 1
1999]. Die Abspeicherung von Rasterdaten erfolgt meist in Dateiform. Zum Unterschied zu
Rastergrafiken werden in einem Pixel nicht zwingend Farben abgespeichert, sondern es kön-
nen unterschiedliche Daten wie zum Beispiel Höheninformationen sein. Das häufigste An-
wendungsgebiet sind dennoch Satelliten- bzw. Luftbilder und bestehende Karten.
Die einfache Struktur und die einfache Analyse sind Vorteile von Rasterdaten. Im Gegenzug
sind die niedrige Genauigkeit, die niedrige Auflösung und der hohe Speicherbedarf als
Nachteile aufzuzeigen [RUDEL 2003].
Folgende Formate werden in derzeitigen Geoinformationssystemen eingesetzt:
GeoTIFF
GeoTIFF ist ein Bildformat zur Speicherung georeferenzierter Bilddaten. Es beruht
auf der Spezifikation von TIFF in der Version 6. In so genannten „Keys“ und zusätzli-
chen Files werden die räumlichen Zusatzinformationen, die für eine Georeferenzie-
rung benötigt werden, gespeichert [RITTER 2000].
MrSID - Multi Resolution Seamless Image Database
MrSID ist ein von der Firma LizardTech entwickeltes Komprimierungsformat für
Bilddaten. Hier kommt ein sehr effektives Kompressionsverfahren auf der Grundlage
der Wavelet-Theorie zum Einsatz, das ohne große Qualitätseinbußen Kompressionsra-
ten von 30:1 erreicht. Viele Bildverarbeitungsprogramme, aber auch GIS greifen auf
das MrSID-Format zurück [ROSTOCK 2 2007].
3.3.3. Räumliche Indizes
Grundsätzlich werden Indizes in Datenbanken benötigt, um Abfragen effektiver zu machen.
Ohne Index müsste bei einer Abfrage, in der ein Vergleich gefordert wird, jeder Datensatz,
also die ganze Tabelle geladen und verglichen werden (Fulltablescan). Ein Index soll die
möglichen Kandidaten eingrenzen und somit nur noch die in Frage kommenden Datensätze
laden. Somit wird der aufwändige Vergleich verringert und zusätzlich die Zugriffe auf die
29

Diplomarbeit Johann Zettel
Festplatte optimiert, da nicht mehr die ganze Tabelle in den Hauptspeicher geladen werden
muss.
Räumliche Indizes unterscheiden sich von herkömmlichen Indizes in ihrer Dimension. Sie
können zwei- oder mehrdimensionale Räume indizieren, wo im Gegensatz herkömmliche nur
eine Dimension indizieren können. Diese Eigenschaft schlägt sich vorwiegend in der Kom-
plexität und im Rechenaufwand nieder [Meile 2007].
Wichtige räumliche Indizes werden im Folgenden näher erläutert:
R-TREE
Ein R-TREE ist ein immer vollständig ausbalancierter Baum und ist eine Erweiterung
des eindimensionalen B-Tree für mehrdimensionale Räume. Räumliche Objekte wer-
den durch ein MBR repräsentiert [SHEKHAR 2003]. Die nachfolgende Abb. 7 veran-
schaulicht diesen Indextyp.
Abb. 7 - R-Tree Räumliche Objekte, Quelle:[SHEKHAR 2003]
Die grau hinterlegten Rechtecke sind MBRs. Jedes davon beinhaltet Geometrien wie
zum Bespiel Polygone, Linien oder Punkte. Die einzelnen MBRs werden in größere
30

Diplomarbeit Johann Zettel
Gruppen zusammengefasst. Wie in Abb. 8 zu sehen, werden diese Gruppen wiederum
in Einheiten gegliedert.
Abb. 8 - R-Tree Hierarchie, Quelle:[SHEKHAR 2003]
Dieser Baum repräsentiert die Speicherstruktur, wie der Index abgelegt wird. Die
Kleinbuchstaben deuten auf zusammengefasste Gruppen. Die Zahlen sind die einzel-
nen MBRs, wie in Abb. 7 zu sehen die
GIST - Generalized Search Tree
Der GIST-Index verfolgt einen generischen Ansatz und wurde von Hellerstein,
Naughton und Pfeffer entworfen [HELLERSTEIN 1995].Es handelt sich dabei um ein
Framwork für beliebige Indizes. Beim Erstellen eines neuen Index muss zum Beispiel
nicht auf Mehrbenutzerzugriff oder Recovery geachtet werden, da diese nur einmal
umgesetzt werden. Nach Fertigstellung des GIST ist die Integration eines neuen Index-
typs also sehr einfach. Der GIST benötigt eine umfangreiche Implementation für jedes
zu unterstützende Betriebssystem und Datenbanksystem. Dieser Indextyp konnte sich
bei kommerziellen Datenbankanbietern noch nicht durchsetzen und ist nur als Prototyp
für diese verfügbar [SÖLLIG 2006]. In einer PostgreSQL-DB wird hingegen GIST als
Standardindex sowohl für eindimensionale als auch für mehrdimensionale Räume ein-
gesetzt.
3.3.4. Räumliche Abfragesprache
Eine Abfragesprache ist ein allgemeines Hilfsmittel, um Informationen über den Inhalt einer
Datenbank zu erfragen. Die Abfragesprache ist die wesentliche Schnittstelle zwischen An-
31

Diplomarbeit Johann Zettel
wender und Maschine. Der Nutzer teilt mittels Abfragesprache dem Datenbanksystem mit,
was er gerne aus dem Datenbestand erfahren möchte. Die Form der Ausgabe kann ebenfalls
zu spezifizieren sein, sie ist allerdings bei den derzeit gängigen relationalen Datenbanken vor-
gegeben und tabellenförmig.
Als wichtigste Abfragesprache gilt heute SQL (Structured Query Language), andere Abfrage-
sprachen wie SEQUEL (Structured Englisch Query Language), QUEL (Query Language)
oder QBE (Query By Example) fanden weniger Akzeptanz. Der Rahmen für eine SQL-
Abfrage sieht jeweils identisch aus, er hat die Form SELECT – FROM – WHERE und reflek-
tiert die drei Operatoren der relationalen Algebra: Projektion, kartesisches Produkt und Selek-
tion.
Da Probleme mit raumbezogenen Daten bei bekannten Abfragesprachen entstehen, gibt es für
jede der vorgenannten Abfragesprachen Weiterentwicklungen.
GEO-QUEL erweitert QUEL um raumbezogene Abfrage- und Displaymöglichkeiten, Query-
by-Pictorail-Example erweitern QBE um Funktionalitäten zur bildhaften Abfrage. Die we-
sentlichen Zielsetzungen aller dieser Vorschläge sind die Einbettung raumbezogener Datenty-
pen, raumbezogener Operatoren und graphischer Ausgabemöglichkeiten. Dennoch lehnt sich
die klare Mehrheit an SQL an [BILL 2 1999].
Die Entwicklung von SQL reicht bis in die 70 er Jahre zurück. Allgemeine Akzeptanz fand
SQL durch die Verbreitung der Oracle-Datenbank zu Beginn der 80 er Jahre. SQL wurde
1986 als ANSI- und 1987 als ISO- Standard normiert. SQL ist kein statisches Produkt, seine
Entwicklung und Fortschreibung dauert an. Erst der Standard SQL 3, welcher von ISO 1999
verabschiedet wurde, berücksichtigt eine Erweiterung SQL-MM für raumbezogene Daten
[STOLZE 2003].
In Abb. 9 ist das Objektmodell des Geometry-Datentyps ersichtlich. Dieses wurde vom Open-
Gis-Consortium OGC Standard in den SQL-MM Standard übernommen. Außerdem wurden
zahlreiche raumbezogene Operatoren definiert.
32

Diplomarbeit Johann Zettel
Abb. 9 - OGC Geometry Class Hierarchy [OGC 2005]
Hat eine Datenbank diesen Standard implementiert, ist beispielhaft in Codebeispiel 2 ersicht-
liches SQL-Statement möglich, welches die Nachbarländer Österreichs selektiert.
Codebeispiel 2 - SQL- Codebeispiel
Die räumliche Funktion „Touch“ gibt den Wert 1 zurück, wenn sich die zwei angegebenen
Geometrien berühren. In diesem Fall handelt es sich um Geometrien des Typs Polygon, wel-
che die einzelnen Länder repräsentieren. Die zweite WHERE-Bedingung ist wiederum eine
normale, herkömmliche Attributabfrage.
33

Diplomarbeit Johann Zettel
3.4. UMN-Mapserver Architektur
Grundsätzlich werden UMN-Mapserversysteme im Internet eingesetzt. Das bedeutet, dass es
sich meistens um bekannte Client –Server Architekturen handelt. Der Client fragt Informatio-
nen vom Server ab. Der Server liefert diese in Form einer Webseite mit eingebetteter Karten-
grafik zurück. Wie auch in anderen Bereichen dieser Arbeit gibt es unzählige Umsetzungsva-
rianten dieser Systeme. Im folgenden Teil werden die Hauptbestandteile, wie in Abb. 10 zu
sehen sind, vorgestellt und beschrieben.
Abb. 10 - UMN-Mapserver Systemarchitektur
Client
In den meisten Fällen ist der Client ein normaler Webbrowser wie zum Beispiel der
Mozilla-Firefox oder der Microsoft-Internet-Explorer. Mit diesen Webbrowsern wer-
den vorwiegend HTML-Dokumente interpretiert und angezeigt. Auch können Script-
sprachen wie zum Beispiel Javascript am Client ausgeführt werden.
Weiters können auch Webbrowser von mobilen Endgeräten auf das System zugreifen.
Hierbei muss die Benutzerschnittstelle, also der Output, den der Server liefert, dem-
entsprechend angepasst werden. In der Praxis bedeutet dies, dass viele Funktionen
nicht unterstützt werden. Jedoch befinden sich mobile Webbrowser gerade in starker
Weiterentwicklung.
Ein weiterer Client könnte eine Applikation wie z.B. ein weiterer UMN-Mapserver
oder ein Desktop-Programm sein. Mit Hilfe von WMS (Web Map Service) können
Karten standardisiert abgefragt, übertragen und in eine andere Applikation eingebun-
den werden.
34

Diplomarbeit Johann Zettel
HTTP-Server
Dieser Server hat die Aufgabe, mit dem Client über ein Netzwerk zu kommunizieren
und die gewünschten Daten bereitzustellen. In dem Fall einer WebGIS- Applikation
können dies zum Beispiel HTML-,CSS- und Javascript- Dokumente sein. Werden dy-
namische Dokumente angefordert, leitet der Server die Daten zum Beispiel weiter an
einen Interpreter oder ein CGI-Programm. Die neu generierten Daten übernimmt wie-
der der Server und leitet sie an den Client weiter.
UMN-Mapserverzugriff
Der Zugriff auf den Mapserver kann einerseits über CGI oder andererseits über
Mapscript erfolgen. Der Nachteil von CGI ist, dass es veraltet und recht langsam ist.
Außerdem steht nicht die komplette Mapserver- Funktionalität zur Verfügung. Der
Zugriff über Mapscript wurde bereits in Kapitel 3.2.5 beschrieben.
UMN-Mapserver
Wie bereits früher erwähnt hat der UMN-Mapserver die Aufgabe, eine Karte in Form
einer Grafik zu generieren. Er erhält Anweisungen über CGI oder Mapscript, welches
Mapfile verwendet werden soll. Auch werden zusätzliche Parameter, wie zum Beispiel
ein Zoom oder eine Datenabfrage, übergeben. Der UMN-Mapserver ruft das angefor-
derte Mapfile auf und interpretiert es. Danach bezieht er die nötigen Daten und rendert
eine Grafik.
Räumliche Daten
Die Daten können in unterschiedlichsten Formen abgelegt werden. Es kann grundsätz-
lich zwischen dateibasierenden und datenbankbasierenden Daten unterschieden wer-
den. Der UMN-Mapserver unterstützt eine Vielzahl an unterschiedlichen Formaten
und bietet auch eine Möglichkeit, selbst Schnittstellen individuell einzurichten.
Mapfile
Das Mapfile ist eine Ascii- Textdatei, welche in einem vom Mapserver zugänglichen
Ordner abgelegt ist. Es ist die Speicherstelle aller Einstellungen eines Mapserverpro-
jekts. Um ein funktionierendes Mapfile zu erzeugen, ist es notwendig, eine vorge-
35

Diplomarbeit Johann Zettel
schriebene Struktur einzuhalten. Die Struktur ist modular aufgebaut, wobei nicht jedes
Modul zwingend vorhanden sein muss. Mittels Layer können räumliche Daten
schichtweise eingebettet werden.
Die Inhalte beziehen sich beispielsweise auf Speicheradressen und Zugangsdaten der
räumlichen Daten, auf das Ausgabeformat des zu rendernden Bildes, auf Projektions-
einstellungen, auf Ausgabeeigenschaften der einzelnen Layer und Geodaten, auf Ei-
genschaften der Maßstabsleiste, Keymap und Legende und auf viele zusätzliche Ein-
stellungen wie zum Beispiel : WMS Service, Labels, Filter, usw.
Abb. 11 zeigt die Struktur eines Mapfiles mit den möglichen Objekten, wobei Layer-
und Class- Elemente öfters integriert werden können.
Abb. 11 - Mapfile Struktur vereinfacht
36

Diplomarbeit Johann Zettel
Ein einfaches Mapfile, welches Daten einer PostgreSQL- Datenbank einbindet, ist in
Codebeispiel 3 ersichtlich. Dieses Beispiel beinhaltet eine Map, einen Layer, eine
Class und ein Style Objekt:
Codebeispiel 3 - Mapfile- Codebeispiel
An diesem Beispiel wird deutlich, dass sich dieses File bei mehreren Layern und Er-
weiterungen schnell zu einem unübersichtlichen und sehr großen Textfile entwickeln
kann. Dieser Umstand ist ein großer Nachteil dieser Art der Speicherung.
37

Diplomarbeit Johann Zettel
4. Testanforderungen
Dieses Kapitel beschäftigt sich mit der Planung und Umsetzung der UMN-
Mapservertestumgebung. Es müssen unbeeinflusste und objektive Tests gewährleistet werden.
Um nützliche Ergebnisse erzielen zu können, werden einzelne Szenarien für die Tests entwi-
ckelt und gewählt. Das bedeutet, dass nicht alle möglichen Einstellungen getestet werden,
sondern lediglich beispielhafte Standardsituationen gewählt werden. An diesen für die Praxis-
relevanten Situationen werden verschiedene ausgewählte Varianten getestet.
4.1. Testbereiche
Die Testbereiche decken im Einzelnen kleine, spezifische Themengebiete ab. Werden jedoch
die Tests in ihrer Gesamtheit betrachtet, ergibt sich ein umfassender Überblick über die Ge-
samtheit dieser Systeme. Ingesamt werden, wie in Abb. 12 zu erkennen, sechs unterschiedli-
che Bereiche analysiert, die im Folgenden näher behandelt werden.
Abb. 12 - Testbereiche
38

Diplomarbeit Johann Zettel
4.1.1. Datenhaltung
Die Datenhaltung ist ein wichtiger Teil eines UMN-Mapserversystems. Auf Grund des großen
Umfangs der zu testenden Themengebiete befassen sich die Tests mit Vektordaten. Wie im
Kapitel „Stand der Technik“ beschrieben, gibt es zwei wesentliche Unterscheidungsmerkmale
bei der Datenhaltung von Vektordaten. Da räumliche Daten sowohl in Dateiform als auch in
Datenbankform in derzeitigen Systemen gehalten werden, ist es wichtig beide Arten zu testen.
Bei der Auswahl wurde auf die Relevanz derzeit gängiger Datentypen geachtet. Es wurden
drei folgende Varianten gewählt:
Shape-file / Dateibasierende Daten
TAB-file / Dateibasierende Daten
PostgreSQL-Datenbank mit PostGIS-Erweiterung / Datenbankbasierende Daten
4.1.2. Mapfile
Das Mapfile besitzt eine große Anzahl an Einstellungsmöglichkeiten, die alle unterschiedli-
chen Einfluss auf den Prozess der Kartengenerierung haben. Dadurch kann auch die Perfor-
mance des UMN-Mapservers verändert werden. Da nicht alle Einstellungen getestet werden
können, werden wiederum nur einige wesentliche behandelt. Bei den gewählten Mapfi-
leeinstellungen zeigte die Erfahrung, dass es sich dabei um sehr aufwändige Bereiche bei der
Generierung von Karten handelt. Im Folgenden werden die drei gewählten Testfälle beschrie-
ben.
Antialiasing
Der Befehl des Antialiasing kann im Mapfile aus- oder eingeschaltet werden. Je nach
Anwendungsfall kann sich daraus ein für den Betrachter anschaulicheres Bild ergeben.
Der Prozess des Antialiasings ist jedoch sehr rechenaufwändig. Im Mapfile werden da-
für folgende Modifikationen vorgenommen:
39

Diplomarbeit Johann Zettel
Ausgabeformat
Es stehen zahlreiche Ausgabeformate der Kartengrafik zur Verfügung. Die meisten
dieser Varianten unterscheiden sich aber in ihrer Struktur, Generierung und ihrer Spei-
chergröße. So braucht ein Grafikformat, welches eine hohe Kompression aufweist,
länger zum Generieren, kann aber im Gegenzug durch seine geringere Speichergröße
schneller übertragen werden. Folgende häufig eingesetzte Formate werden getestet:
o GIF
o PNG
o JPEG
40

Diplomarbeit Johann Zettel
Es sind auch andere mögliche Formate wie zum Beispiel SWF oder TIFF zu berücksichtigen.
Da diese Formate einen GDAL-Driver benötigen, sind diese Bilder langsamer zu generieren.
Die hier getesteten Formate verwenden einen GD-Driver. Dieser ist laut offizieller UMN-
Mapserver Webseite effizienter [MAPSERVER 2006].
Projektionsumrechnung
Das Mapfile bietet die Möglichkeit, Daten einzelner Layer On The Fly in eine andere
Projektion umzurechnen. Es liegt auf der Hand, dass dies aufwändige Rechenoperatio-
nen erfordert und damit die Performance beeinflusst. Gewählt wird hierbei die Um-
rechnung von WGS84- zu MGI- Koordinaten.
o WGS84 ist eine Latitude/ Longitude Projektion. Es handelt sich dabei um eine
„Normale Zylinderprojektion“, welche auf dem WGS84-Ellipsoid beruht. Im
Mapfile wird der EPSG- Code 4326 gesetzt
o MGI (Militärgeografisches Institut) ist eine Lambert-Projektion. Dabei wird eine
4.1.3. Datenzugriff
„Normale Kegelprojektion“ verwendet, die auf dem Bessel 1841-Ellipsoid be-
ruht. Im Mapfile wird der EPSG: 31287 gesetzt
Die Eigenschaften des Zugriffs auf die räumlichen Daten beeinflussen in großem Ausmaß die
Performance eines UMN-Mapserversystems. So ist z.B. zu vermuten, dass eine Auslagerung
der Datenbank auf einen Datenbankserver zusätzliche Ressourcen in der Verbindung dieser
zwei Server verbraucht. Dies äußert sich dadurch, dass bei jeder Abfrage erst eine Verbindung
zu diesem Datenbankserver aufgebaut werden muss und anschließend die Daten erst über ein
Netzwerk transferiert werden müssen, bevor sie verarbeitet werden können. Dieser Vorgang
benötigt Zeit und schlägt sich in der Performance des Systems nieder. Auf der anderen Seite
verbraucht eine Datenbank, die räumliche Operationen rechnet, Prozessorleistung, die wie-
derum auch der UMN-Mapserver benötigt. Daher gibt es vermutlich eine Situation, in der das
Auslagern der Datenbank Performance fördernd ist. Dieses Beispiel soll lediglich die Kom-
plexität dieses Punktes näher bringen. Da solche Untersuchungen den Rahmen dieser Arbeit
41

Diplomarbeit Johann Zettel
übersteigen würden, werden nur kleinere, abgeschlossene Teilgebiete analysiert. Diese wer-
den im Folgenden näher betrachtet:
Datenorganisation
Es wird getestet, inwieweit die Anordnung der Daten in der Datenbank Auswirkung
hat. Es werden zwei verschiedene Varianten analysiert.
o Räumliche Daten und Sachdaten werden in einer Datentabelle abgelegt. Dies hat
möglicherweise den Effekt, dass auch beim Generieren der Grafik Sachdaten ab-
gefragt werden. Dafür wird eine Spalte des typs „string“ eingefügt, die eine gro-
ße Datenmenge beinhaltet.
o Räumliche Daten werden so belassen, wie sie im Punkt „Testdatensatz“ be-
schrieben werden. Das bedeutet, es wird eine Tabelle erstellt, die Geometrien be-
sitzt und zusätzlich lediglich eine Spalte mit sachlichen Daten.
Weiters kann auch im Bereiche der Datenorganisation erwähnt werden, dass bei Da-
tenbanken das Filesystem einen Einfluss ausübt. Bei Windows-Plattformen ist dies a-
ber sekundär, da nur zwei gängige Filesystemr zur Verfügung stehen: NTFS und
FAT32.
Im Gegensatz zu Windows kann bei Linux Plattformen aus einer großen Anzahl an
verschiedenen Filesystemen gewählt werden. Im Testlabor wird das ReiserFS verwen-
det. In wichtigen Internetforen ist jedoch die Rede davon, dass ReiserFS und ähnliche
Filesysteme eher auf einen Desktopbetrieb ausgelegt sind. ReiserFS kann zum Bei-
spiel gut mit kleinen Dateien umgehen, aber bei größeren hat es Probleme. Da eine
Datenbank aber eher größere Blöcke verwendet, wäre ein Filesystem zu bevorzugen,
das diese Eigenschaft mehr unterstützt.
Räumlicher Index
Wie bereits im Kapitel „Stand der Technik“ erläutert, vereinfacht ein räumlicher Index
den Zugriff auf räumliche Daten. Es soll getestet werden, welchen effektiven Vorteil
ein Index im Prozess der Kartengenerierung wirklich bringt. Darum werden folgende
Varianten getestet:
42

Diplomarbeit Johann Zettel
o Kein Index
o GiST
4.1.4. Hardware
Es wird kein Index in Bezug auf die Geometrien der Datentabelle erstellt. Es
wird erwartet, dass dies den Zugriff auf die Daten stark erschwert und so mehr
Zeit benötigt wird, um die gewünschten Daten zusammenzustellen.
PostgreSQL besitzt einen eigenen Indextyp. Er wurde für Sachdaten in Verbin-
dung mit einer PosgreSql-Datenbank entwickelt. PostGIS implementiert diesen
Index in Kombination mit einem R-Tree. Dieser räumliche Index erleichtert den
Zugriff auf die Daten. Mit Hilfe eines solchen Index können die gewünschten
Daten schneller gefunden werden.
Da die Performance nahezu aller Softwaresysteme stark vom Faktor der Hardware abhängig
ist, wird dieser Punkt in einem eigenen Test durchgeführt.
Interessant hierbei ist, in welchem Bereich der unterschiedlichen Hardwarekomponenten Po-
tenzial zur Verbesserung der Leistung eines UMN-Mapserversystems liegt. Wird die Leistung
der Hardwarekomponenten gesteigert, erhöht sich auch die Performance des UMN-
Mapservers. Unklar ist jedoch die genaue Leistungsbeeinflussung der einzelnen Hardware-
komponenten auf dieses System. Getestet wird folgende Hardware, die in jedem Computer-
system ihre Anwendung findet und die sich außerdem hervorragend zum Aufrüsten eignet:
Arbeitsspeicher
Der Arbeitsspeicher dient als kurzzeitiges Speichermedium für die CPU, da er einen
schnelleren Schreibe- und Lesezugriff als eine Festplatte besitzt. Hierbei ist oft die
Speichergröße des Arbeitsspeichers ausschlaggebend für die Leistung eines Software-
systems. Aus diesem Grund werden folgende Speichergrößen untersucht.
512 MB, DDR 2, PC400
1024 MB, DDR 2, PC400
2048 MB, DDR 2, PC400
43

Diplomarbeit Johann Zettel
CPU - Central Processing Unit
Diese Hardwareeinheit ist die zentrale Recheneinheit und ist das Herzstück eines
Computersystems. Da herkömmliche, gebräuchliche Computersysteme lediglich eini-
ge Typen von Prozessoren unterstützen, wäre es notwendig, unterschiedliche Compu-
tersysteme bereitzustellen, um mehrere Prozessortypen zu testen. Es wird lediglich ein
Computersystem mit zwei verschiedenen Prozessoren untersucht. Diese sind folgende:
Intel Pentium D 805 2,66Ghz
Intel Core 2 Dual E830 1,67Ghz
4.1.5. Betriebssystemplattform
Die Art der Plattform ist ein wesentlicher Teil eines UMN-Mapserversystems. Sie besteht im
Wesentlichen aus dem Betriebssystem und aus Software, die die Umgebung des UMN-
Mapserver zusammenstellt wie zum Beispiel der HTTP- Server oder ein Scriptinterpreter.
Getestet wird ausschließlich das Betriebssystem in Kombination mit einem HTTP- Server.
Als zu testende Betriebssysteme werden Linux und Windows gewählt, da sie die meiste
Verbreitung als Webserverbetriebssystem haben. In allen Tests kommt bei der Windows Va-
riante der Microsoft IIS (Internet-Information-Server) und in der Linux-Variante ein Apache-
Server als HTTP-Server zum Einsatz. Eine Untersuchung von über 100 Millionen Domains
ergab, dass 58,7 % Apache, 31,09% Microsoft Internet Information Server und 10,21% sons-
tige Webserver verwenden (Stand Feb.2007) [NETCRAFT 2007].
Um die Komplexität eines HTTP-Servers zu erahnen, haben Techniker des Unternehmens
Sana Security versucht, dies in einer Grafik abzubilden. In Abb. 13 ist zu sehen was passiert,
wenn ein Client von einem Windows IIS ein einfaches HTML-Dokument mit eingebetteter
Grafik anfordert. Interessant ist der Vergleich mit Abb. 14, in der der gleiche Ablauf mit dem
Apache HTTP-Server auf Linuxbasis dargestellt ist. Es ist gut zu erkennen, dass der IIS um
ein Vielfaches mehr Systemcalls benötigt als ein Apache.
44

Diplomarbeit Johann Zettel
Abb. 13 - Systemcall IIS Quelle: [STIENNON 2006]
Abb. 14 - Systemcall Apache Quelle: [STIENNON 2006]
45

Diplomarbeit Johann Zettel
Im Folgenden werden die zwei unterschiedlichen Plattformen beschrieben.
Linux
Da es eine Vielzahl an unterschiedlichen Distributionen gibt, wurde ein Vertreter ge-
wählt, der sich in der Erfahrung als stabil und alltagstauglich erwiesen hat. Die Distri-
bution Debian 3.1. rev5., welche auf dem Linux-Kernel 2.6.15 beruht, wird in den
weiteren Untersuchungen als Linux Betriebssystem dienen. Es werden ausschließlich
folgende für den Standardbetrieb eines UMN-Mapservers notwendige Softwarepakete
installiert:
o Debian 3.1. rev5.
o Apache 2.0
o Php 5
Windows
o UMN Mapserver 4.10.
o PosgreSql 8.1.8.
o PostGIS 1.2.1. / GEOS 2.2.3. / PROJ 4.4.9.
Für diese Variante wurde ein Microsoft Windows Server 2003 gewählt. Dieser stellte
sich in einer Untersuchung als gebräuchlichster Windows Server heraus. Auch auf die-
ser Basis aufbauend wurden nur notwendige Softwarepakete installiert. Diese sind:
o Microsoft Windows Server 2003
o Servicepack 1
o IIS 6.0.
o Php 5.2.1.
o UMN Mapserver 4.10.
o PostgreSQL 8.1.8.
o PostGIS 1.2.1. / GEOS 2.2.3. / PROJ 4.5.
Ein Nachteil von UMN-Mapserverinstallationen auf Windows sind die vorkompilier-
ten Installationspakete. Da diese zeitsparende Variante die meisten Anwender verwen-
den, wurde auch in dieser Arbeit das fertig kompilierte Windows Installationspaket
(nicht zu verwechseln mit MS4W) verwendet. Der Nachteil besteht darin, dass
zwangsweise auch nur die zur Zeit des Kompilierens aktuellen Versionen anderer Pa-
46

Diplomarbeit Johann Zettel
kete verwendet werden. Das bedeutet, dass bei der Installation der Linux-Plattform
nicht die aktuellsten Pakete verwendet wurden sondern die Versionen, die im Win-
dowspaket einbezogen waren. Werden spezielle Einstellungen oder Kompatibilitäten
benötigt, muss der UMN-Mapserver auch auf Windows extra kompiliert werden.
4.2. Testlabor
Das Testlabor besteht, wie in Abb. 15 zu erkennen ist, aus mindestens einem Client und ei-
nem Server. Der Client setzt eine Anfrage an den Server ab und startet eine Zeitmessung. Der
Server generiert Daten und schickt diese wieder an den Client zurück, welcher wiederum die
Zeitmessung stoppt.
Abb. 15 - Server Struktur des Testlabors
Eine Anforderungsanalyse hat ergeben, dass das Testlabor folgende Eigenschaften erfüllen
muss, um ein unbeeinflusstes und objektives Testen zu ermöglichen:
Einfaches Client-Server-Netzwerk
Der Clientrechner wird mittels eines Fast-Ethernet-Netzwerkes mit dem Server ver-
bunden. Ein Netzwerk-Switch dient als Knotenpunkt.
Keine nicht notwendige Netzwerkaktivität
Außer Standardnetzwerkverkehr darf das Netzwerk nicht zusätzlich belastet werden.
Schubweise, nicht vorhersehbare Aktivitäten verfälschen die Messungen. Da auch der
Standardnetzwerkverkehr nicht konstant ist, müssen mehrere Messreihen erfolgen, um
Ausreißer filtern zu können.
47

Diplomarbeit Johann Zettel
Keine nicht notwendigen Prozesse auf dem Server
Es dürfen keine unnötigen Prozesse von anderen Anwendungen den Serverbetrieb be-
einflussen. Ausgenommen sind wiederum Standardprozesse, um den Betrieb aufrecht
zu erhalten.
4.3. Testdatensatz
Der Testdatensatz beinhaltet räumliche Daten, die vom UMN-Mapserver verarbeitet werden.
Je nach vorgegebener Datenhaltung werden sie in das jeweilige Daten- oder Datenbankformat
konvertiert. Die Eigenschaften des Datensatzes sollen ähnlich wie die Eigenschaften eines im
Alltag gebräuchlichen Datensatzes sein. Gewählt wurden Vektordaten, da sie in der Regel
öfters Anwendung finden als Rasterdaten. Teile eines Teleatlas-Datensatzes des österreichi-
schen Straßennetzes werden für den Testdatensatz dienen. Es werden insgesamt drei unter-
schiedliche Datensätze gewählt, die jeweils eine unterschiedliche Dichte an Vektoren aufwei-
sen. Dies hat zur Folge, dass im Prozess der Generierung der Karte eine unterschiedliche An-
zahl an Linien berücksichtigt werden muss und somit der Aufwand zur Generierung variiert.
Alle drei Datensätze umfassen, wie in Abb. 16 zu erkennen, ein Feld im Ausmaß von 15 x 15
Bogenminuten auf einem WGS84 Ellipsoid, welches den Bereich um Wien (Österreich) ab-
deckt.
Abb. 16 - Testdatensatz – Räumliche Abdeckung
Straßentypen werden in dem Teleatlasdatensatz mit Hilfe von Functional Road Classes FRC
unterschieden. Davon stehen folgende 8 Klassen zur Verfügung [TELEATLAS 2002]:
1. Motorways
2. Other Major Roads
48

Diplomarbeit Johann Zettel
3. Secondary Roads
4. Local Connecting Roads
5. Local Roads of High Importance
6. Local Roads
7. Local Roads of Minor Importance
8. Others
In den einzelnen Datensätzen wurden nach Bedürfnis der gewünschten Dichte eine bestimmte
Menge an FRC Klassen selektiert.
49

Diplomarbeit Johann Zettel
1. Datensatz - Geringe Dichte
In Abb. 17 ist der Datensatz mit geringer Dichte zu sehen. Er beinhaltet 3533 Vekto-
ren, die aus insgesamt 13.183 Knoten gebildet werden. Es ergibt sich ein Durchschnitt
von 59 Vektorentupel pro Quadratminute.
Verwendete FRC: 0, 1, 2; Dies entspricht im Wesentlichen Autobahnen,
Schnellstraßen und Bundesstraßen.
Abb. 17 - Testdatensatz, geringe Dichte
50

Diplomarbeit Johann Zettel
2. Datensatz - Mittlere Dichte
In Abb. 18 ist der Datensatz mit mittlerer Dichte zu sehen. Er beinhaltet 12.112 Vekto-
ren, die aus insgesamt 43.205 Knoten gebildet werden. Es ergibt sich ein Durchschnitt
von 192 Vektorentupel pro Quadratminute.
Verwendete FRC: 0, 1, 2, 3, 4, 5; Dies entspricht im Wesentlichen Autobahnen,
Schnellstraßen, Bundesstraßen, Landstraßen und wichtigen Ortsstraßen.
Abb. 18 - Testdatensatz, mittlere Dichte
51

Diplomarbeit Johann Zettel
3. Datensatz - Hohe Dichte
In Abb. 19 ist der Datensatz mit hoher Dichte zu sehen. Er beinhaltet 37.485 Vektoren,
die aus insgesamt 128.926 Knoten gebildet werden. Es ergibt sich ein Durchschnitt
von 573 Vektorentupel pro Quadratminute.
Verwendete FRC: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9; Dies beinhaltet alle Typen von Straßen.
Abb. 19 - Testdatensatz, hohe Dichte
4.4. Testapplikation
Auf dem Clientrechner des Testlabors wird eine Applikation implementiert, die den Test ini-
tialisiert und misst. Sie startet den HTTP-Request und empfängt den HTTP-Response. Die
Dauer dieses Vorgangs wird gemessen und abgespeichert. Jeder Test wird insgesamt 300 mal
durchgeführt. Bei dieser Anzahl ergeben sich in einer vertretbaren Zeit vergleichbare Ergeb-
nisse. Die einzelnen Testabfolgen werden, soweit sie die gleichen Systemeigenschaften besit-
zen, in der Applikation abgespeichert. Damit wird ein automatisiertes Testen erreicht. Die
52

Diplomarbeit Johann Zettel
gemessenen Daten werden in eine Text-Datei abgespeichert, um sie später manuell auszuwer-
ten.
Abb. 20 zeigt die genaue Zeitspanne, die gemessen wird. Der Zeitpunkt, in dem der HTTP-
Request die Testapplikation verlässt, wird abgespeichert. Wiederum wird beim Erhalt des
HTTP-Response die Zeit gemessen. Anschließend wird die Zeitdifferenz berechnet. Die Test-
applikation erreicht Zeitmessungen im Millisekundenbereich.
Abb. 20 - Testapplikation – Zeitmessung
Die Anfragen an den Server beinhalten nicht den gesamten Kartenausschnitt sondern immer
einen Teilausschnitt. Wie in Abb. 21 zu sehen wird an einer zufällig gewählten Position ein
Ausschnitt im Ausmaß von 70% der Gesamtkarte definiert. Das bedeutet, bei jeder Messung
wird ein anderer Bereich abgefragt. Diese Maßnahme führt zu folgenden zwei Eigenschaften:
Der Server kann die Grafik nicht cachen, da es sich immer um einen anderen Karten-
ausschnitt handelt. Dies hat zur Folge, dass die Grafik bei jeder Anfrage neu generiert
werden muss.
Beim Zugriff auf die Datengrundlage der zu generierenden Grafik kann ein räumlicher
Index verwenden werdet. Somit können Indizes untereinander verglichen werden.
Wird bei einer Anfrage ein gesamter Kartenausschnitt verlangt, benötigt der UMN-
Mapserver die gesamte Datengrundlage. Dies hat zur Folge, dass der Zugriff nicht op-
timiert werden muss und daher kein räumlicher Index benötigt wird.
53

Diplomarbeit Johann Zettel
Abb. 21 - Zufällige Kartenausschnitte
54

Diplomarbeit Johann Zettel
5. Messung
Das folgende Kapitel beschreibt den Ablauf der Messungen. Es erläutert die tatsächliche Um-
setzung der Tests und erklärt auftretende Probleme. Der grobe Ablauf sieht folgendermaßen
aus: Zu Beginn wurde das Testlabor nach Vorgaben aus Kapitel 4 eingerichtet. Die Testappli-
kation wurde anschließend in C# entwickelt und auf dem Clientrechner des Testlabors instal-
liert. Eine Folge von Probeläufen überprüfte danach die Zuverlässigkeit des Systems. Auftre-
tende Fehler und Unstimmigkeiten wurden entweder bereinigt oder durch andere Maßnah-
men, zum Beispiel durch Filter, ausgeglichen.
5.1. Evaluierung
In der ersten Phase nach Einrichtung und Installation des Systems wurden erste Probemes-
sungen durchgeführt. Damit wurden die einzelnen Elemente des Systems auf ihre Funktions-
tüchtigkeit überprüft.
In diesen ersten Probeläufen fiel eine ungewollte Regelmäßigkeit auf. Je nach Einstellung
wurden nach bestimmten Abständen an Testläufen extreme Ausreißer in der Zeitspanne ge-
messen. Liegt der arithmetische Mittelwert der gemessenen Zeitspannen einer Testreihe von
1000 Einzeltests bei zum Beispiel 200 Millisekunden, so gab es ungefähr alle 30 Messungen
einen Ausreißer der über 500ms für die Antwort benötigte. Da die Höhe dieses regelmäßig
auftretenden Phänomens variiert, können erst bei starker Erhöhung der Testanzahl vergleich-
bare Werte berechnet werden. Abb. 22 zeigt beispielhaft diese Ausreißer bei einer Messreihe
von 1000 Durchläufen.
55

Diplomarbeit Johann Zettel
Abb. 22 - Ungefilterte Messreihe
Aus diesem Grund wurde ein Filter implementiert, der diese regelmäßigen Ausreißer filtert.
Nach Ablauf einer Messreihe wird der arithmetische Mittelwert gebildet. Danach werden alle
Werte selektiert, die um 15 Prozent höher als der Mittelwert sind. Die selektierten Werte wer-
den anschließend durch neue Messungen ersetzt und nochmals überprüft. Abb. 23 zeigt eine
Messreihe, die gefiltert wurde.
Abb. 23 - Gefilterte Messreihe
56

Diplomarbeit Johann Zettel
5.2. Messablauf
Die einzelnen Messreihen sind in Abb. 24 zu sehen. Untersucht wurde in einem ersten Schritt,
welche Varianten technisch möglich sind. Weiters wurde untersucht, welche Einstellungen
voneinander abhängig sind. Zum Beispiel beeinflusst die Datengrundlage nicht die Generie-
rung der Grafik. Das bedeutet, das gewählte Grafikformat und die verwendete Datengrundla-
ge sind unabhängig. Als Standardeinstellung wurde PostGIS mit Index / PNG / 1GB RAM
und der Intel Core 2 Dual E830 1,67Ghz gewählt
Abb. 24 – Testszenarien
57

Diplomarbeit Johann Zettel
6. Analyse der Messreihen
Nach Ablauf aller geplanten Tests werden in diesem Kapitel die Ergebnisse ausgewertet und
analysiert. Nach diesem Vorgang werden Aussagen in Bezug auf Performanceoptimierung
getroffen. Funktional zusammenhängende Bereiche werden strukturiert betrachtet. Sofern
nichts anderes erwähnt, werden für die Vergleiche die in Kapitel 5.2 beschriebenen Standard-
einstellungen gewählt.
6.1. Plattform
Eingerichtet wurden die beiden Serverplattformen mit ihren Defaulteinstellungen. Das bedeu-
tet, es wurde keine Optimierung des Betriebssystems selbst vorgenommen. Zweifellos ist je-
doch in diesem Bereich auch ein großes Potenzial an Verbesserungen bezüglich der Perfor-
mance vorhanden. In den folgenden zwei Kapiteln wird auf jede Plattform nochmals allge-
mein eingegangen. Bereichsspezifische Testergebnisse unter unterschiedlichen Betriebssys-
temen sind bereits in den jeweiligen Kapiteln behandelt worden.
6.1.1. Windows Server 2003
Anders als bei Linux- Systemen werden bei der Installation eines Windows-Servers eine Viel-
zahl von nicht benötigter Software mitinstalliert. Diese Software benötigt wiederum System-
ressourcen. Dies hat den Nachteil, dass dem UMN-Mapserver nicht alle Ressourcen zu Ver-
fügung stehen.
58

Diplomarbeit Johann Zettel
In Abb. 25 sind Antwortzeiten in einem Diagramm dargestellt. Sie zeigen grundlegende Zeit-
spannen ohne dass eine Karte generiert wird.
Abb. 25 - Grundladezeiten von Windows
Ein leeres HTML-Dokument ist sehr schnell übermittelt. Das Aufrufen des PHP-Interpreters
benötigt ca. weitere 30ms. Weitere 60ms dauert es, bis die PHP-Mapscript Erweiterung gela-
den ist und ein leeres PHP-Dokument übermittelt wird.
6.1.2. Linux Debian
Großer Vorteil des UMN-Mapaservers auf Linux Basis ist, dass die Software selbst kompi-
liert werden muss. Das bedeutet, es brauchen nur benötigte Funktionalitäten implementiert
werden. Diese Eigenschaft macht das System wieder kleiner und dadurch schneller.
Das Linuxsystem kann sehr leicht auf die wesentlichen Serverprozesse optimiert werden. Alle
nicht benötigten Funktionen können ohne Schwierigkeiten abgeschaltet oder erst gar nicht
installiert werden.
59

Diplomarbeit Johann Zettel
In Abb. 26 wurden die Ladezeiten ohne die Generierung einer Karte dargestellt.
Abb. 26 - Grundladezeiten von Linux
Zu erkennen ist, dass ein HTML- Dokument sehr schnell bereitgestellt wird. Nur ca. 0,3 ms
werden benötigt, um den Pop-Interpreter zu laden. Das Laden der PHP-Mapscript Erweite-
rung benötigt insgesamt 94,15ms. Somit ist das Linux-System ähnlich schnell beim Laden der
Mapscript- Erweiterung wie das Windows-System.
6.2. Datenhaltung
Die Art der Datenhaltung stellte sich als ein sehr maßgeblicher Faktor bezüglich der Perfor-
mance heraus. Sehr unterschiedlich verhalten sich die einzelnen Varianten auf den zwei ver-
schiedenen Plattformen Windows und Linux. In Abb. 27 ist der Vergleich der drei Datenhal-
tungsformen Shape, Tab und PostGIS unter Windows abgebildet.
60

Diplomarbeit Johann Zettel
Abb. 27 - Datenhaltung im Vergleich unter Windows
Bildinhalte shape tab PostGIS
geringe Dichte 173,176 ms 173,396 ms 209,252 ms
mittlere Dichte 275,970 ms 267,249 ms 291,096 ms
hohe Dichte 546,770 ms 496,430 ms 503,035 ms
Zu erkennen ist, dass sich alle drei Varianten sehr ähnlich verhalten. Bei geringer Datendichte
sind das Shapefile und das TAB-File nahezu gleich. Die PostgreSQL-DB ist jedoch bei gerin-
ger Datendichte rund 20% langsamer als die übrigen zwei Formate. Dieser Unterschied ver-
ringert sich, wenn die Datendichte angehoben wird. Bei hoher Datendichte ist die
PostgreSQL-DB bereits um ca. 10% schneller als das Shapefile und der Unterschied zum
TAB-File ist nur noch minimal. Wird die Dichte weiter angehoben, ist anzunehmen, dass sich
der Trend fortsetzt. Erklärbar ist dieses Verhalten mit dem zusätzlichen Overhead bei der Da-
tenbankverbindung zwischen dem UMN Mapserver und der PostgreSQL-DB. Da die Daten-
bank besser mit größeren Datenmengen umgehen kann als ein Fileformat und der Overhead
konstant bleibt, ist sie bei höheren Datendichten schneller. [POSTGIS 2007]. In Abb. 28 ist
der Vergleich der Datenhaltung auf der Linux Plattform zu sehen.
61

Diplomarbeit Johann Zettel
Abb. 28 - Datenhaltung im Vergleich unter Linux
Bildinhalte shape tab PostGIS
geringe Dichte 153,799 ms 176,458 ms 367,369 ms
mittlere Dichte 198,360 ms 257,431 ms 498,197 ms
hohe Dichte 311,046 ms 460,540 ms 802,092 ms
Das Verhalten des Shapefiles und des TAB-files ist unter Linux anders als unter Windows.
Bei geringer Datendichte ist der Unterschied unwesentlich. Bei Erhöhung der Datendichte
wird das TAB-File jedoch langsamer. Das Shapefile ist dann im Gegenzug um ca. 30%
schneller als das TAB-File.
Die PostGIS- Variante unter Linux unterscheidet sich im Vergleich zu Windows deutlich.
Unter dem Linuxsystem ist die Datenhaltung in PostGIS um fast 40% langsamer. Die Ursache
dafür ist auch nach weiteren Untersuchungen und Analysen ungeklärt.
In einem weiteren, modifizierten Versuch wurde die PostgreSQL-DB mit der PostGIS-
Erweiterung unabhängig vom übrigen UMN-Mapserversystem getestet. Dafür wurde die
Testapplikation modifiziert und damit direkt vom Client SQL-Statements an die PostgreSQL-
DB abgesetzt.Auf Windows und Linux wurden so Antwortzeiten gemessen. In Abb. 29 sind
die Mittelwerte dieser Testreihen visualisiert.
62

Diplomarbeit Johann Zettel
Abb. 29 - Manueller Datenbankzugriff
Bildinhalte Windows Linux
geringe Dichte 10,419 ms 4,423 ms
mittlere Dichte 67,050 ms 11,210 ms
hohe Dichte 119,062 ms 27,141 ms
In dieser Situation tritt der umgekehrte Fall ein. Unter Windows ist der Datenbankzugriff um
ein Vielfaches langsamer als auf der Linux Plattform. Berücksichtigt man die Testergebnisse
in Bezug auf das Testsystem, scheint der Grund für die schlechte Performance der
PostgreSQL-DB im Bereich des Datenzugriffs des UMN-Mapservers zu liegen. Ein direkt
abgesetztes SQL-Statement wird sehr schnell von der Linux basierenden Datenbank abgear-
beitet. Nur wenn der UMN-Mapserver mit der Datenbank unter Linux kommuniziert, treten
hohe Verzögerungen auf.
6.3. Mapfile
Das Mapfile selbst beinhaltet eine Vielzahl an Einstellungsmöglichkeiten, die Auswirkungen
auf die Performance haben. Wie im Vorfeld der Messungen bereits angenommen, haben sich
63

Diplomarbeit Johann Zettel
die gewählten Einstellungsvarianten aber als besonders leistungs- beeinflussend herausge-
stellt.
6.3.1. Antialiasing
Beim Antialiasing-Test wurde eine modifizierte Einstellung im Outputformat des Mapfiles
verwendet. Da die Grafik mehr als 256 Farben benötigt, um diesen Prozess durchzuführen,
wurde der „IMAGEMODE“ auf den Wert „RGB“ gesetzt. In Abb. 30 ist ein Vergleich zu
sehen, bei dem einmal Antialiasing aktiviert wurde und einmal nicht.
Abb. 30 - Antialiasing Vergleich
Bildinhalte Antialiasing deaktiviert Antialiasing aktiviert
geringe Dichte 209,252 ms 376,989 ms
mittlere Dichte 291,096 ms 472,985 ms
hohe Dichte 503,035 ms 735,600 ms
Der Mehraufwand für das Antialiasing beträgt mehr als 40% und ist konstant bezüglich der
Datendichte. Betrachtet man die Zahlen, nimmt bei Erhöhung der Datendichte der zusätzliche
Zeitaufwand leicht zu. Die Hypothese bezügliche des Antialiasings- Prozesses ist damit bestä-
tigt.
64

Diplomarbeit Johann Zettel
6.3.2. Ausgabeformat
Als Ausgabeformat wurden drei verschiedene Grafikformate gewählt, die in der Regel am
häufigsten angewendet werden.
Außerdem ist zu beachten, dass der „IMAGEMODE“ im Mapfile verändert werden kann.
Dieser beschreibt die Farbtiefe, die gerendert werden soll. Eine höhere Farbtiefe erhöht den
Leistungsbedarf und den Speicherplatz. Auf der anderen Seite können mehr Farben verarbei-
tet werden. Diese Eigenschaft wird zum Beispiel bei Luftbildern benötigt.
In Abb. 31 ist ein Vergleich zwischen den drei getesteten Grafikformaten unter Windows dar-
gestellt.
Abb. 31 - Grafiken im Vergleich unter Windows
Bildinhalte GIF PNG JPG
geringe Dichte 164,260 ms 250,498 ms 173,176 ms
mittlere Dichte 249,745 ms 372,885 ms 275,970 ms
hohe Dichte 480,716 ms 673,653 ms 546,770 ms
Auf der Windows Plattform hebt sich das GIF-Format eindeutig als das schnellste Grafikfor-
mat ab. Ein PNG-Bild ist im Durchschnitt um 30% langsamer. Das JPG ist bei niedriger Da-
65

Diplomarbeit Johann Zettel
tendichte fast so schnell generiert wie ein GIF. Nimmt die Datendichte zu, verlangsamt sich
jedoch der Vorgang des Generierens. Dies kann auf den Komprimieralgorithmus zurückzu-
führen sein. In Abb. 32 werden die Grafiken unter Linux verglichen.
Abb. 32 - Grafiken im Vergleich unter Linux
Bildinhalte GIF PNG JPG
geringe Dichte 142,506 ms 153,799 ms 255,312 ms
mittlere Dichte 168,345 ms 198,360 ms 313,587 ms
hohe Dichte 239,560 ms 311,046 ms 449,410 ms
Wie auf Windows ist GIF eindeutig in Bezug auf die Performance das am schnellsten gene-
rierte Bild. Langsamer sind allerdings das PNG und JPG. Auf Linux benötigt das JPG mehr
Zeit als alle anderen Formate. Es ist anzunehmen, dass die Bibliotheken, die für das Rendern
verantwortlich sind, in beiden Plattformen verschieden implementiert sind.
Bezüglich des Ausgabeformats ist festzustellen, dass Linux generell schneller ist. Am Bei-
spiel des GIF-Formats hat dieser Unterschied eine Größenordnung von ca. 50% bei hoher
Datendichte.
66

Diplomarbeit Johann Zettel
Ein weiteres Merkmal ist die durchschnittliche Dateigröße der generierten Grafiken. Da das
Testlabor auf einem lokalen Gigabit Netzwerk beruht, hat die Übertragungskapazität des Net-
zes minimalen Einfluss auf das Ergebnis. Anders ist dies jedoch in einem realen Betrieb im
Internet. Hierbei ist die Datenmenge, die transferiert werden muss, ein maßgeblicher Faktor.
In Abb. 33 sind die Dateigrößen der drei Grafikformate visualisiert. Es sind Grafiken mit
1000x1000 Pixel. In der Praxis werden meistens kleinere Formate eingesetzt und die Datei-
größen werden somit auch kleiner sein.
Abb. 33 - Dateigrößen der Grafikformate
Auch hier ist das GIF das günstigste Format. Es hat die geringste Dateigröße und somit ver-
braucht es am wenigsten Übertragungskapazität. Ähnlich verhält sich das PNG. Um ein Viel-
faches größer ist das JPG-Format. Ein Grund dafür ist, dass das JPG nicht für diese Art von
Grafik ausgelegt ist. Werden im Hintergrund beispielsweise Luftbilder geladen, verhalten sich
die Dateigrößen anderes. Da sich die Effektivität der Kompressionen unterscheidet, verändert
sich die Dateigröße. In diesem Fall kann sich die Rangordnung verschieben.
Rechnet man mit einer durchschnittlichen Downloadgeschwindigkeit einer ADSL-
Verbindung von 125 KByte/s, verbraucht ein PNG bei hoher Datendichte mehr als 600ms, bis
es der Client anzeigen kann. Hier wird erkennbar, dass die Dateigröße einen der größten An-
teile an der Ladezeit einnimmt.
67

Diplomarbeit Johann Zettel
6.3.3. Projektionsumrechnung
Wie in Kapitel 4.1.2 beschrieben wurde für eine Messreihe eine Projektionsumrechnung akti-
viert. WGS84 Koordinaten wurden vom UMN-Mapserver in MGI-Koordinaten umgerechnet.
In Abb. 34 sind zwei Messreihen abgebildet, jeweils einmal ohne Projektionsumrechnung und
einmal mit Projektionsumrechnung.
Abb. 34 - Vergleich Projektionsumrechnung
Bildinhalte keine Projektionsumrechnung mit Projektionsumrechnung
geringe Dichte 209,252 ms 323,328 ms
mittlere Dichte 291,096 ms 466,919 ms
hohe Dichte 503,035 ms 818,556 ms
Bei geringer Datendichte ist eine WebGIS-Applikation um ca. 35% schneller, wenn die Daten
bereits in der Ausgabe-Projektion vorliegen. Das bedeutet, dass eine Projektionsumrechnung
sehr zeitaufwändig ist. Außerdem erhöht sich dieser Unterschied auf ca. 39% bei Erhöhung
der Datendichte.
68

Diplomarbeit Johann Zettel
6.4. Datenzugriff
Wie auch in den anderen Testbreichen werden auch hier interessante Ergebnisse erzielt. Zu
erwähnen ist, wie bereits schon öfters in dieser Arbeit, dass hier nur ein sehr kleiner Teilbe-
reich analysiert wurde. In der Praxis müssen hierbei oft individuelle Einstellungen getestet
werden.
6.4.1. Datenorganisation
Im Bereich der Datenorganisation benötigte jede Variante die gleiche Zeit für das Generieren
des Bildes. Das bedeutet, dass Sachdaten die in der gleichen Tabelle abgespeichert werden
wie die Geometrien, keinen Einfluss auf die Performance haben. Daher brauchen alle Sachda-
ten nicht in andere Datentabellen ausgelagert werden.
Der Grund dafür ist, dass der UMN-Mapserver nur die Geometrie-Spalte abfragt. Nur bei Se-
lektionen oder Beschriftungen bezieht der Mapserver weitere Spalten, in denen diese Daten
abgespeichert werden.
6.4.2. Indizes
Bei der Auswertung der Messreihen ergab sich eine ähnliche Situation wie im Bereich der
Datenorganisation. In dieser Testanordnung hatte ein Index keinen Einfluss auf die Generie-
rungszeit. Der Grund dafür ist, dass der räumliche Index nicht verwendet wurde. Der abge-
fragte Kartenausschnitt war immer, wie in Kapitel 5 beschrieben, 70% der Gesamtdaten-
grundlage. Aufgrund dieses Kartenausschnittes entschied das DBMS den Index nicht zu ver-
wenden, da dieser keinen Performancegewinn erbringen würde. Bevor eine Suche beginnt,
vergleicht das DBMS die Effizienz aller möglichen Queryplans in Bezug auf ihren benötigte
CPU und I/O Verbrauch. Danach wählt dieser den effizientesten Weg. Die Abb. 35 veran-
schaulicht die Funktion eines Index.
69

Diplomarbeit Johann Zettel
ohne Index mit Index
Abb. 35 - Funktion eines Index [Meile 2007]
Wenn ein Index verwendet wird, wird er im ersten Schritt geladen. Nach Auswertung des
Index entsteht entweder ein Result-Set oder ein Kandidaten-Set. Wurde ein möglicher Result-
Set identifiziert, werden nur diese von der Festplatte geladen. Bei einem Kandidaten-Set wer-
den diese zuerst von der Festplatte geladen und danach weiter ausgewertet, bis ein Result-Set
übrig bleibt. Wird kein Index verwendet, wird der komplette Datensatz von der Festplatte
geladen und mittels Fulltablescan das Result-Set erzeugt. Diese Form ist sehr aufwändig in
Bezug auf den Speicherzugriff.
Ist das Result-Set sehr groß im Verhältnis zum ganzen Datensatz, kann es effizienter sein oh-
ne Index zuarbeiten, da das Laden und Auswerten des Index auch Zeit in Anspruch nimmt.
Da die angenommenen 70% nicht zum gewünschten Ergebnis führten, wurden in einer weite-
ren Versuchsreihe Kartenausschnitte mit 50%, 25% und 5% des Gesamtdatensatzes getestet.
Bei dieser Verkleinerung des möglichen Result-Sets bindet die Datenbank den Index bei der
Suche ein. In Abb. 36 sind diese Messreihen abgebildet.
70

Diplomarbeit Johann Zettel
Abb. 36 - Testwiederholung – Indizierung
Bildinhalte ohne Index mit Index
5% Kartenausschnitt 180,963 ms 155,260 ms
20% Kartenausschnitt 207,691 ms 194,999 ms
50% Kartenausschnitt 416,951 ms 400,922 ms
Gut zu erkennen ist, dass die Abfragen mit einem Index schneller sind. Dieser Trend drückt
sich deutlicher aus wenn die Tests mit einer größeren Datenmenge vorgenommen werden.
6.5. Hardware
Wie bereits in vorherigen Kapiteln zu erkennen ist, widmet sich ein kleiner Teil dieser Arbeit
der Hardware des Servers. Es wurden Arbeitsspeichervarianten und zwei verschieden schnelle
CPUs getestet. Auch andere Hardwareelemente des Gesamtsystems haben erhebliches Poten-
tial zur Leistungssteigerung. Jede Hardware, die das Rendern, die Datenbankeigenschaften
oder die Netzwerkkapazitäten verbessert, eignet sich für Performanceverbesserungen.
6.5.1. Arbeitsspeicher
Allgemein zu anderen Testgebieten ist zu erkennen, dass in diesem Bereich relativ geringfü-
gige Unterschiede in den einzelnen Arbeitsspeichervarianten 512MB, 1024MB und 2048MB
71

Diplomarbeit Johann Zettel
gemessen wurden. Grund dafür ist, dass der Arbeitsspeicher fast nicht ausgelastet wird. Da
die Datenmengen sehr gering sind, verbrauchen sie sehr wenig Speicher und belasten dadurch
nicht das restliche System. Kommen in WebGIS-Applikationen größere Datenmengen zur
Anwendung, hat der Arbeitsspeicher mehr Einfluss als hier. Sind die zu verarbeitenden Da-
tenmengen größer als der verfügbare Speicherplatz im Arbeitsspeicher, können nur Teile ge-
laden werden. Dies schlägt sich natürlich in der Leistungsfähigkeit nieder. In Abb. 37 ist der
Vergleich der Arbeitsspeichervarianten abgebildet.
Abb. 37 - Arbeitsspeichervergleich
Bildinhalte 512MB RAM 1024MB RAM 2048MB RAM
geringe Dichte 214,622 ms 209,252 ms 201,697 ms
mittlere Dichte 301,745 ms 291,096 ms 275,630 ms
hohe Dichte 523,167 ms 503,035 ms 472,890 ms
Grundsätzlich waren die Tests mit 512MB Arbeitsspeicher um 5% langsamer als die mit
1024MB. Die Steigerung auf 2048 MB brachte einen noch geringeren Performancezuwachs.
72

Diplomarbeit Johann Zettel
6.5.2. CPU
Ähnlich wie im Vergleich des Arbeitsspeichers wurden nur geringe Unterschiede zwischen
den beiden Prozessoren gemessen.
Abb. 38 - CPU- Vergleich
Bildinhalte Pentium D 805 Core2 Dual E 830
geringe Dichte 225,559 ms 155,260 ms
mittlere Dichte 313,924 ms 194,999 ms
hohe Dichte 542,976 ms 400,922 ms
Der Intel Pentium D 805 ist bei jeder Datendichte ca. 5% langsamer als der Core2 Dual E830.
Trotz der niedrigeren Taktfrequenz arbeitet die Core2 Dual CPU effizienter. Da beide Prozes-
soren zwei Kerne besitzen, ist nicht zuerkennen, ob dies Vorteile in Bezug auf die Performan-
ce bringt. Jedoch ist anzunehmen, dass bei einem realen Serverbetrieb Mehrkern-
Technologien Vorteile verschaffen, da Aufgaben aufgeteilt werden können.
73

Diplomarbeit Johann Zettel
6.6. Weitere mögliche Optimierungsschritte
Betriebssystem Optimierungen
Im Betriebssystem selbst können viele Einstellungen vorgenommen werden, die die
Leistung und Effizienz des Systems beeinflussen. Zum Beispiel kann die Größe der
Auslagerungsdateien oder die Verteilung der Systemressourcen optimiert werden.
Datenbank Optimierung
Auch Datenbanken, hier im speziellen Fall eine PostgreSQL- Datenbank, besitzen vie-
le Konfigurationsoptionen. So können in der PostgreSQL.conf zum Beispiel die Res-
sourcenverwaltung oder einzelne Abfrageeinstellungen verändert werden.
Räumliche Rasterdaten
Ein weiterer großer Teil, der nicht im Detail getestet wurde, sind räumliche Rasterda-
ten als Datengrundlage für die Generierung der Bilder. In diesem Bereich kommen ei-
ge Optimierungsverfahren, wie zum Beispiel Kacheln, zum Einsatz. Das scheint inte-
ressant zu sein, da Rasterbilder oft eingesetzt werden und meistens große Datenmen-
gen besitzen.
Weitere Datenanbindungen, Plattformen
Sehr interessant wären auch andere Datenbankanbindungen, wie zum Beispiel ArcS-
DE oder Oracle Spatial. Besonders bei sehr großen Datenmengen wäre ein Vergleich
mit PostgreSQL/ PostGIS sehr informativ.
Außerdem wären auch andere Plattformen interessant zu testen. Messungen auf ande-
ren Linux Distributionen oder auf einem Solaris Betriebssystem würden wiederum an-
dere Eigenschaften erzielen.
Auch ist der Einsatz anderer HTTP-Server möglich. Zum Beispiel würde sich auch ein
ZOPE-Webanwendungsserver für einen UMN-Mapserver eignen.
Stresstests
Ein in dieser Arbeit nicht behandeltes Themengebiet ist das Verhalten eines UMN-
Mapserversystems in Stresssituationen. Da von einem Server oft mehrer Clients
74

Diplomarbeit Johann Zettel
gleichzeitig abrufen, ist dieser Aspekt sehr wichtig. Ein Test mit mehreren simulierten
Clients würde hier neue Informationen bringen, welche Einstellungen sich besonders
gut für hochfrequentierte Webseiten eignen.
Weitere Hinweise
Alle getesteten Situationen wurden mit PHP-Mapscript abgewickelt. Ein weiterer Weg
ist die Abfrage über CGI. Auch diese Variante wird noch oft in Verbindung mit
WMS-Anfragen angewendet.
Eine weitere Analyse der einzelnen UMN-Mapserver-Komponenten würde weitere
aufschlussreiche Erkenntnisse bezüglich der Performance bringen. Außerdem könnte
der UMN-Mapserver selbst untersucht werden.
75

Diplomarbeit Johann Zettel
7. Schlussfolgerung
Ausgangspunkt dieser Arbeit war die Suche nach Optimierungsmöglichkeiten von UMN-
Mapserversystemen in Bezug auf die Performance. In einer Planungs- Umsetzungs- und Ent-
wicklungsphase wurden verschiedene Teilbereiche dieses Systems untersucht. In einem
Netzwerklabor wurden diese Varianten getestet und anschließend ausgewertet. Die zu Beginn
erwähnte Hypothese, dass gezielte Einstellungen die Performance von UMN-
Mapserversystemen steigert, wurde bestätigt. Dies zeigte die Analyse der Ergebnisse der ein-
zelnen Testbereiche.
Im Folgenden werden wichtige Ergebnisse zusammengefasst:
Plattform
Die Wahl des richtigen Betriebssystems ist schwierig. Durchwegs ist Linux in den
einzelnen Bereichen deutlich schneller. Allerdings traten Probleme bei der Datenan-
bindung mit PostgreSQL auf. Auch in einem Testlabor konnte diese Schwierigkeit
nicht gelöst werden. Problem dabei ist, das diese Engstelle in der Praxis nur schwer
festzustellen ist, da kein Vergleichssystem zur Verfügung steht. Ein weiterführender
Versuch hat jedoch gezeigt, dass PostgreSQL mit PostGIS auf Linux um ein Vielfa-
ches schneller ist.
Datenhaltung
Bei der Entscheidung über das Format der räumlichen Daten ist die Datenmenge aus-
schlaggebend. Werden kleiner Datenmengen verwendet, ist das Shapefile zu bevorzu-
gen. Eine Datenbank sollte bei größeren Datenmengen zum Einsatz kommen. Das
Tab-File ist durchwegs etwas langsamer als das Shapefile.
Mapfile
Antialiasing sollte aus Performance-Sicht vermieden werden. Um den Treppeneffekt
zu vermeiden, kann es aber in manchen Anwendungen notwendig sein, diese Einstel-
lung zu aktivieren. Es sollte aber sparsam damit umgegangen werden.
76

Diplomarbeit Johann Zettel
Insgesamt stellte sich heraus, dass das GIF auf jeder Plattform am schnellsten gene-
riert wird. Außerdem ist seine durchschnittliche Dateigröße sehr klein. Ein Nachteil im
Gegenzug ist, dass die Farbtiefe nicht mehr als 256 Farben betragen kann. Ein weiterer
Nachteil, der berücksichtigt werden muss: Die Erstellung eines GIF- Bildes erfordert
eine Lizenz.
Eine Projektionsumrechnung „on the fly“ ist nicht ratsam. Aber es kann in einigen
Anwendungsfällen sinnvoll sein, die Ausgangsdaten in einer anderen Projektion zu be-
lassen. Wird die Datentabelle auch von anderen Systemen benutzt, kann eine Umrech-
nung des kompletten Datensatzes in Bezug auf die Kompatibilität sehr schwer sein.
Dies sollte aber ein kleinerer Teil der zu visualisierenden Daten sein und aus Perfor-
mancesicht, wenn möglich, vermieden werden. Eine weitere Optimierungsmöglichkeit
ist die Einstellung im Mapfile selbst. Bei den Tests wurde, um die Umrechnung zu ak-
tivieren, der EPSG-Code eingetragen
PROJECTION
"init=epsg:4326"
END
Dabei muss die Proj4 Bibliothek Daten zu dem EPSG-Code in ihrer Projektionsdaten-
bank abfragen. Dies geschieht wiederum bei jedem Aufruf des Mapfiles. Daher wird
empfohlen, entweder aus dieser Projektionsdatenbank alle nicht benötigten Projektio-
nen zu löschen, oder die Daten wie folgt selbst anstatt des EPSG-Codes einzutragen.
[MAPSERVER 2006]
PROJECTION
"proj=latlong"
"ellps=WGS84"
"datum=WGS84"
END
In Bezug auf die Performance können weitere Faktoren im Mapfile berücksichtigt
werden. Im Folgenden sind einige Grundregeln und Vorschläge aufgelistet
[MAPSERVER 2006]:
77

Diplomarbeit Johann Zettel
o Kleines Mapfile
Das Mapfile wird bei jedem Aufruf einer Karte komplett abgearbeitet. Daher ist es
wichtig, das Mapfile klein zuhalten. Angaben, die nicht benötigt werden, verlang-
samen das Parsen dieser Datei.
o Layer
Es sollte generell auf die Dateigröße geachtet werden. Layer mit dem STATUS
ON oder DEFAULT werden geladen und für das Visualisieren vorbereitet, auch
wenn sie nicht angezeigt werden. Mapfiles mit sehr vielen Layern können aufge-
teilt oder dynamisch geladen werde,n um nicht jedes Mal abgearbeitet zu werden.
o Label
Um Objekte mit Labels beschriften zu können ist eine Schriftart notwendig. Im
Mapfile wird der Name der Schriftart festgelegt. Damit der UMN-Mapserver die
Schrift aufrufen kann, muss er die Datei fonts.list aufrufen. In dieser fonts.list soll-
ten nur benötigte Schriftarten vorhanden sein, da das Abarbeiten viel Zeit in An-
spruch nimmt.
Datenzugriff
Im Bereich der Indexierung der Daten kommt es individuell auf die Anwendung an.
Werden meistens eine Gesamtansicht oder große Teile des Datensatzes abgefragt, ist
ein räumlicher Index nicht notwendig. Dies ist sehr selten der Fall. Ist eine WebGIS-
Applikation voll zoomfähig, ist ein Index über die Geometrien sehr zu empfehlen.
Da in einer WebGIS-Applikation aber auch Sachdaten abgefragt werden, sind normale
Indizes zu berücksichtigen. Die Daten, die ein User über die Benutzerschnittstelle ab-
fragen kann, sollten indiziert werden, um die Abfragezeiten zu minimieren. Hierbei
kommen je nach Datentyp zum Beispiel B-Tree-Indizes oder ein GIST zum Einsatz.
Hardware
Im Bereich der Hardware gilt grundsätzlich, dass effektivere Prozessoren schnellere
Antwortzeiten liefern. Außerdem sind alle Hardwareelemente zu empfehlen die das
Rendern, die Datenbankeigenschaften oder die Netzwerkkapazitäten verbessern.
78

Diplomarbeit Johann Zettel
Eine Aufstockung des Arbeitsspeichers ist nur notwendig, wenn es die Datenmenge
verlangt. Reicht der vorhandene Arbeitspeicher aus, um den kompletten Datensatz zu
laden, ist kein zusätzlicher Speicherplatz notwendig. Tritt eine gegenteilige Situation
auf, so gilt je mehr Arbeitspeicher, desto besser.
Grundsätzlich können diese Ergebnisse als Richtlinien betrachtet werden. Wird eine neue
UMN-Mapserver-Anwendung entwickelt, können diese Richtlinien berücksichtigt werden um
bereits im Vorhinein Performance Engpässe zu vermeiden. Treten trotz Einhaltung Engpässe
auf, müssen individuell weitere Einstellungen gestestet werden.
Wie zu Beginn der Arbeit erwähnt, erhebt diese Arbeit keinen Anspruch auf Vollständigkeit.
Das bedeutet, es gibt zahlreiche weitere Optimierungsmöglichkeiten, die nicht behandelt wur-
den. Die vorliegende Arbeit liefert grundsätzliche Ideen, wie die Performance von UMN-
Mapserversystemen gesteigert werden kann.
79

Diplomarbeit Johann Zettel
Abkürzungsverzeichnis:
ADSL Asymmetric Digital Subscriber Line
API Application Programming Interface
ASCII American Standard Code for Information Interchange
CGI Common Gateway Interface
CSS Cascading Style Sheets
DB Database
DXF Drawing Interchange Format
EPSG European Petroleum Survey Group
FRC Functional Road Classes
GIF Graphics Interchange Format
GIS Geographic Information System
GIST Generalized Search Tree
GML Geography Markup Language
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IIS Internet Information Server
ISO International Organization for Standardization
JPEG Joint Photographic Experts Group
JS Javascript
MGI Militärgeografisches Institut
OGC Open Geospatial Consortium
PDF Portable Document Format
PHP PHP Hypertext Preprocessor
PNG Portable Network Graphics
SQL Structured Query Language
SVG Scalable Vector Graphics
SWF Small Web Format
TIFF Tagged Image File Format
UMN University of Minnesota
WMS Web Map Service
XML Extensible Markup Language
80

Diplomarbeit Johann Zettel
Abbildungsverzeichnis:
Abb. 1 – Arbeitsablauf des Projektes ............................................................................. 9
Abb. 2 - Vergleich Vektor-Rastergrafik....................................................................... 20
Abb. 3 – Rasterung eines Vektors, Quelle: [3DCenter 2007] ...................................... 21
Abb. 4 - Aliasing-Effekt, Quelle: [3DCenter 2007]..................................................... 21
Abb. 5 - Antialiasing, Quelle: [3DCenter 2007] .......................................................... 22
Abb. 6 - PHP Interpretation.......................................................................................... 23
Abb. 7 - R-Tree Räumliche Objekte, Quelle:[SHEKHAR 2003] ................................ 30
Abb. 8 - R-Tree Hierarchie, Quelle:[SHEKHAR 2003] .............................................. 31
Abb. 9 - OGC Geometry Class Hierarchy [OGC 2005]............................................... 33
Abb. 10 - UMN-Mapserver Systemarchitektur ............................................................ 34
Abb. 11 - Mapfile Struktur vereinfacht ........................................................................ 36
Abb. 12 - Testbereiche ................................................................................................. 38
Abb. 13 - Systemcall IIS Quelle: [STIENNON 2006]................................................. 45
Abb. 14 - Systemcall Apache Quelle: [STIENNON 2006].......................................... 45
Abb. 15 - Server Struktur des Testlabors ..................................................................... 47
Abb. 16 - Testdatensatz – Räumliche Abdeckung ....................................................... 48
Abb. 17 - Testdatensatz, geringe Dichte ...................................................................... 50
Abb. 18 - Testdatensatz, mittlere Dichte...................................................................... 51
Abb. 19 - Testdatensatz, hohe Dichte........................................................................... 52
Abb. 20 - Testapplikation – Zeitmessung..................................................................... 53
Abb. 21 - Zufällige Kartenausschnitte.......................................................................... 54
Abb. 22 - Ungefilterte Messreihe ................................................................................. 56
Abb. 23 - Gefilterte Messreihe ..................................................................................... 56
Abb. 24 – Testszenarien ............................................................................................... 57
Abb. 25 - Grundladezeiten von Windows .................................................................... 59
Abb. 26 - Grundladezeiten von Linux.......................................................................... 60
Abb. 27 - Datenhaltung im Vergleich unter Windows................................................. 61
Abb. 28 - Datenhaltung im Vergleich unter Linux....................................................... 62
Abb. 29 - Manueller Datenbankzugriff ........................................................................ 63
Abb. 30 - Antialiasing Vergleich.................................................................................. 64
81

Diplomarbeit Johann Zettel
Abb. 31 - Grafiken im Vergleich unter Windows ........................................................ 65
Abb. 32 - Grafiken im Vergleich unter Linux.............................................................. 66
Abb. 33 - Dateigrößen der Grafikformate .................................................................... 67
Abb. 34 - Vergleich Projektionsumrechnung............................................................... 68
Abb. 35 - Funktion eines Index [Meile 2007] .............................................................. 70
Abb. 36 - Testwiederholung – Indizierung................................................................... 71
Abb. 37 - Arbeitsspeichervergleich.............................................................................. 72
Abb. 38 - CPU- Vergleich............................................................................................ 73
82

Diplomarbeit Johann Zettel
Quellcodeverzeichnis:
Codebeispiel 1 - PHP Mapscript - Codebeispiel .......................................................... 24
Codebeispiel 2 - SQL- Codebeispiel ............................................................................ 33
Codebeispiel 3 - Mapfile- Codebeispiel....................................................................... 37
83

Diplomarbeit Johann Zettel
Literaturverzeichnis:
[3DCenter 2007]
3DCenter Anti-Aliasing im Detail
http://www.3dcenter.org/artikel/anti-aliasing/index03.php (02.04.2007)
[BADER 2004]
Herbert Bader (2004) SVG Reporting Vektorgrafiken im Web einsetzen, Software & Support
Verlag
[BILL 1 1999]
Ralf Bill ( 1999) Grundlagen der Geo-Informationssysteme, Band 1, Hardware,Software und
Daten. Wichmann Verlag
[BILL 2 1999]
Ralf Bill ( 1999) Grundlagen der Geo-Informationssysteme, Band 2, Analysen, Anwendungen
und neue Entwicklungen. Wichmann Verlag
[BRODMÜLLER-SCHMITZ 2002]
Alexandra Brodmüller-Schmitz (2002) HTML Kompakt Komplett Kompetent,
Markt+Technik-Verlag
[DICKMANN 2001]
Frank Dickmann (2001) web-mapping und web-gis, Westermann Verlag
[ESRI 1998]
ESRI (1998) Shapefile Technical Description, Whitepaper
http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf (26.03.2007)
[ESRI 2007]
ESRI, The Geodatabase, http://www.esri.com/software/arcgis/geodatabase/index.html
(26.03.2007)
84

Diplomarbeit Johann Zettel
[FÜRPASS 2001]
Christian Fürpaß (2001) Mapserver als Hilfsmittel zur Datenvisualisierung im Internet – Er-
läutert anhand des Internetprojektes AtOS, der Internetversion des "Atlas Ost- und Südosteu-
ropa", Diplomarbeit Universität Wien
[GISWIKI 2006]
GisWiki, Heinz-Josef Lücking, Map Info Interchange Format,
http://www.giswiki.org/wiki/MIF_/_MID (27.03.2007)
[HELLERSTEIN 1995]
J. M. Hellerstein, J. F. Naughton, A. Pfeffer (1995), Generalized Search Trees for Database
Systems; In: Proceedings 21st International Conference on VLDB
[INTERGRAPH 2005]
Intergraph (2005) GeoMedia WebMap , PRODUCT SHEET
http://www.intergraph.com/literature/geomedia_webmap.pdf (06.04.2007)
[MAPSERVER 2006]
David Fawcett (2006) Map File Tuning,
http://mapserver.gis.umn.edu/docs/howto/mapfiletuning (12.04.2007)
[Meile 2007]
Rolf Meile, Dirk Burghardt (2007) Räumliche Datenbanken, Universität Zürich Vorlesungs-
unterlagen,
http://www.geo.unizh.ch/gis/teaching/vorlesungen/spatial_db/ (30.03.2007
[MYSQL 2007]
MySql (2007), MySql 5.1 Referenzhandbuch, MySql AB
http://downloads.mysql.com/docs/refman-5.1-de.a4.pdf (28.03.2007)
[NETCRAFT 2007]
Netcraft , Feb 2007, http://survey.netcraft.com/Reports/, February 2007 Web Server Survey
[OGC 2005]
OGC (2005) Implementation Specification for Geographic information - Simple feature ac-
cess, http://www.opengeospatial.org/standards/sfa (26.03.2007)
85

Diplomarbeit Johann Zettel
[Oracle 2005]
Oracle (2005) Oracle Spatial 10g An Oracle White Paper, Oracle Corporation
http://www.oracle.com/technology/products/spatial/pdf/10gr2_collateral/spatial_twp_10gr2.p
df (28.03.2007)
[POSTGIS 2007]
PostGIS, PostGIS Manual, http://PostGIS.refractions.net/docs/PostGIS.pdf (10.04.2007)
[RITTER 2000]
Niles Ritter, Mike Ruth (2000) GeoTIFF Format Specification 1.8.2 Revision 1, JPL Carto
Group, SPOT Image Corp. http://www.remotesensing.org/geotiff/geotiff.html (26.03.2007)
[ROSTOCK 1 2007]
Universität Rostock, Datenbank-Managementsystem Geoinformatik-Lexikon,
http://www.geoinformatik.uni-rostock.de/einzel.asp?ID=399 (28.03.2007)
[ROSTOCK 2 2007]
Universität Rostock, MrSID Geoinformatik-Lexikon,
http://www.geoinformatik.uni-rostock.de/einzel.asp?ID=1480715484 (28.03.2007)
[RUDEL 2003]
Brigitte Rudel (2003) Einführung in GIS – Vorlesung, Fachhochschule Wiener Neustadt Stu-
diengang Geoinformationstechnologie
[SHEKHAR 2003]
Shashi Shekhar, Sanjay Chawla (2003), Spatial Databases: A Tour, Pearson Education Inc.
[SÖLLIG 2006]
Gunnar Söllig (2006) Umsetzung von nutzerdefinierten Indexstrukturen in ORDBMS am Bei-
spiel eines Indexes für mehrdimensionale Datenstrukturen, Universität Rostock
Institut für Informatik, Studienarbeit
[STIENNON 2006]
Richard Stiennon (2006) Why Windows is less secure than Linux, ZDNET
http://blogs.zdnet.com/threatchaos/?p=311 (06.04.2007)
86

Diplomarbeit Johann Zettel
[STOLZE 2003]
Knut Stolze (2003) SQL / MM Spatial: The Standard to Manage Spatial Data in Relational
Database Systems, Leipzig
[TELEATLAS 2002]
Tele Atlas (2002) Tele Atlas MultiNet Data Model Version 3.2, S.113, Tele Atlas Dokumen-
tation
[WIKI 1 2007]
Wikipedia, Open Geospatial Consortium
http://de.wikipedia.org/wiki/Open_Geospatial_Consortium (28.03.2007)
[WIKI 2 2007]
Wikipedia, Tagged Image File Format,
http://de.wikipedia.org/wiki/Tagged_Image_File_Format (28.03.2007)
[ZETTEL 2007]
Johann Zettel (2007) Entwicklung und Umsetzung einer Anwendung zur Visualisierung von
dynamischen Verkehrsinformationen im Internet, Praktikumsarbeit Fachhochschule Wiener
Neustadt
87