Hanno Rahn
Marktanalyse, Konzeption und Umsetzung eines Intranet-Auskunftsystems für die
kommunale Verwaltung
Auf Basis von Open Source Software und unter Berücksichtigung von OGC-
Spezifikationen
ISBN: 978-3-8366-0853-4
Druck Diplomica® Verlag GmbH, Hamburg, 2008
Zugl. Fachhochschule Oldenburg/Ostfriesland/Wilhelmshaven, Oldenburg, Deutschland,
Diplomarbeit, 2007
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2008
Printed in Germany
1
Inhaltsverzeichnis
1 Einleitung zum Thema und Anforderungsprofil ...7
2 Umzusetzender
Musterdatenbestand
(Ausgangsdaten) ...8
3 OGC
Spezifikationen...10
3.1 Einleitung Geo-Daten Dienste...10
3.2 Überblick über den Web Map Service (WMS) ...11
3.3 Überblick über den Web Feature Service (WFS)...13
3.4 Überblick über den Web Coverage Service (WCS) ...14
3.5 Überblick über den Coordinate Transformation Service (CTS)...15
3.6 Überblick über das Simple Feature Model (SFM) ...15
3.7 Überblick über die Geography Markup Language (GML) ...19
4
Marktanalyse: Open Source Software ...19
4.1 Open Source Definition...19
4.2 Einleitung Geo-Daten Server...21
4.2.1 Überblick über Deegree...21
4.2.2 Überblick über den Geoserver...22
4.2.3 Überblick über den UMN Mapserver (MS4W)...23
4.2.4 Bewertung und Entscheidung für einen Geo-Daten Server...24
4.3 Einleitung
Web-GIS-Clients ...26
4.3.1 Überblick über Flexible Internet Spatial Template (Fist)...26
4.3.2 Überblick über MapLab ...28
4.3.3 Überblick über Chameleon...29
4.3.4 Überblick über CartoWeb...30
4.3.5 Überblick über Mapbender...31
4.3.6 Bewertung und Entscheidung für einen Web-GIS-Client ...32
4.4 Grundlagen
über
map-Dateien...34
4.4.1 Aufbau einer map-Datei ...34
4.4.1.1 Das
Map-Objekt
(Header) ...34
4.4.1.2 Symbole und ihre Definitionen in der map-Datei ...37
4.4.1.3 Das
Layer-Objekt ...39
4.4.1.4 Verwendbare Datenformate im UMN Mapserver ...41
4.4.2 Software zum Erstellen von map-Dateien...44
4.4.2.1 Überblick über Avein für ArcView...44
4.4.2.2 Überblick über Gix Export Tool für ArcView ...46
4.4.2.3 Überblick über MapEdit ...49
4.4.2.4 Überblick über Quantum GIS...50
4.4.2.5 Bewertung und Entscheidung für eine Software ...52
2
4.5 Sonstige
Software ... 53
4.5.1 Einleitung
Konverter
Software ... 53
4.5.1.1 Überblick über CAD2Shape 3.0 ... 53
4.5.1.2 Überblick über AutoCAD dxf to Shapefile Converter... 54
4.5.1.3 Überblick über Dxf2PostGIS... 55
4.5.1.4 Überblick über shp2pgsql ... 56
4.5.2 Überblick über PostgreSQL/PostGIS ... 56
4.6 Fachbegriffe zum Thema ... 57
4.6.1 Kurze Einführung in JavaScript... 57
4.6.2 Kurze Einführung in PHP ... 58
4.6.3 Kurze Einführung in MapScript... 58
4.7 Benutzte
Softwarekomponenten
/ Software Architektur ... 59
5 ibt
Geo-Viewer... 60
5.1 Umsetzung des Musterdatenbestands (Besonderheiten und Schwierigkeiten)... 60
5.1.1 Umsetzung des Themas: Luftbilder ... 61
5.1.2 Umsetzung des Themas: Übersicht... 61
5.1.3 Umsetzung des Themas: Bebauungsplan-Übersicht... 61
5.1.4 Umsetzung des Themas: Bebauungspläne... 62
5.1.5 Umsetzung des Themas: ALK ... 63
5.1.6 Umsetzung des Themas: Wasser... 63
5.1.7 Umsetzung des Themas: Kanal... 63
5.1.8 Umsetzung der Beschriftungen in den einzelnen Themen... 64
5.1.9 Alternative
Umsetzungsmöglichkeiten
am Beispiel der Beschriftungen ... 66
5.2 Einbinden einer map-Datei in Mapbender ... 69
5.3 Auskunftssystem Oberfläche und Elemente ... 76
5.4 Funktionen und Bedienung des Auskunftssystems... 79
5.4.1 Erläuterung der geometrischen Grundfunktionen... 79
5.4.2 Erläuterung
der
Abfragefunktionen ... 80
5.4.3 Erläuterung
der
Themensteuerungsmöglichkeiten... 82
5.4.4 Erläuterung
sonstiger
Funktionen ... 84
6
Performance-Überlegungen für bessere Zugriffszeiten ... 85
7
Bewertung, Schlußfolgerung und Ausblick... 88
3
Anhang ...89
A. Installationen ...89
a.
Kurzanleitung (Windows Installer) ...89
b. Installation
PostgreSQL...89
c. Installation
Mapserver
4
Windows...93
d. Installation
Mapbender...96
B. Pflichtenheft ...105
C. Tabellen OGC Spezifikationen...106
a.
Web Map Service ...106
b.
Web Feature Service...108
c.
Web Coverage Service ...109
d.
Simple Feature Model ...110
e. Sonstige
Spezifikationen ...111
D. Tabelle Zeichenvorschrift...112
E. map-Datei
Beispiele ...115
a. map-Datei
Header...115
b.
jpg-Datei Einbinden eines Raster Layers ...116
c.
shp-Datei Einbinden eines Polygon Layers...116
d.
shp-Datei Einbinden eines Linien Layers...117
e.
shp-Datei Einbinden eines Punkt Layers...118
f.
WMS aus anderer Quelle einbinden über eine URL ...118
F. Literaturverzeichnis...119
a. Buch-Quellen...119
b. Sonstige
Quellen...119
c. Internet-Quellen...120
Abbildungsverzeichnis
Abb. 1: Teil des Musterdatenbestands im ArcView-Projekt...9
Abb. 2: Beispiel WMS GetCapabilities Aufruf...12
Abb. 3: Beispiel WMS GetMap Aufruf ...12
Abb. 4: Beispiel WFS GetCapabilities Aufruf ...13
Abb. 5: Beispiel WFS GetFeature Aufruf ...14
Abb. 6: Beispiel WFS DescribeFeature Aufruf...14
Abb. 7: 9IM-Matrix ...17
Abb. 8: Topologie zweier Geometrien (2 Polygone) ...17
Abb. 9: 9IM-Matrix mit boolschen Werten für Abb.8 ...17
Abb. 10: DE-9IM-Matrix für Abb.8...18
Abb. 11: Topologie zweier Geometrien (2 Geraden) ...18
Abb. 12: abschließende DE-9IM-Matrix für Abb.11 ...18
Abb. 13: Geoserver Daten Konfigurations-Fenster...22
4
Abb. 14: Luftbild in der Geoserver Vorschau (MapBuilder)... 23
Abb. 15: UMN Mapserver - Startbildschirm ... 24
Abb. 16: Fist - Nutzer-Oberfläche mit Testdatensatz von Dissen aTW ... 27
Abb. 17: MapLab - Komponentenauswahl... 28
Abb. 18: Beispiel Chameleon - cwc-tag für die Projektionen in einer html-Datei... 29
Abb. 19: Chameleon - Nutzer-Oberfläche mit Testdatensatz von Dissen aTW ... 30
Abb. 20: Mapbender Startseite... 31
Abb. 21: Mapbender - Nutzer-Oberfläche mit Testdatensatz von Dissen aTW ... 32
Abb. 22: Beispiel STYLE Objekt ... 37
Abb. 23: TrueType-Schriftart-Datei - Auszug aus MapInfo... 37
Abb. 24: Beispiel CLASS Objekt ... 40
Abb. 25: Beispiel Mapserver interne Mechanismen - Einbindung einer jpg-Datei... 41
Abb. 26: Beispiel Mapserver interne Mechanismen - Einbindung einer Polygon shp-Datei .. 41
Abb. 27: Beispiel OGR-Bibliothek - Einbindung der Punkt-Daten einer dgn-Datei... 42
Abb. 28: Beispiel Einbinden des externen Layers TK100 vom LGN ... 43
Abb. 29: Beispiel PostGIS Datenbank - Einbindung eines Polygon Layers ... 43
Abb. 30: Avein Grundeinstellungen ... 45
Abb. 31: Avein Beschriftungen ... 46
Abb. 32: GIX Export Auswahl ... 47
Abb. 33: GIX Header Einstellungen... 47
Abb. 34: GIX Sonstige Einstellungen... 47
Abb. 35: GIX Mapserver Optionen... 48
Abb. 36: MapLab - Anlegen der Header-Angaben einer neuen map-Datei ... 49
Abb. 37: MapLab - Angabe eines Layer Elements in der map-Datei... 50
Abb. 38: Quantum GIS - Beispiel-Oberfläche - Auswahl des map-Datei Exports... 51
Abb. 39: Quantum GIS - map-Datei Export Einstellungsfenster... 52
Abb. 40: CAD2Shape - Einstellungsfenster ... 54
Abb. 41: AutoCAD DXF 2 Shapefile Converter ... 55
Abb. 42: Dxf2PostGIS - Einstellungsfenster ... 56
Abb. 43: Beispiel Indizierte Luftbilder ... 61
Abb. 44: Sachdatenabfrage - Bebauungspläne - pdf-Dokumente... 62
Abb. 45: Beispiel OFFSITE Element - Bebauungspläne Layer ... 62
Abb. 46: Beispiel CLASS Objekt - Layer: Leitungen ... 63
Abb. 47: CAD2Shape - Datenauswahl ... 64
Abb. 48: CAD2Shape - Attributauswahl ... 65
Abb. 49: CAD2Shape - Ausgabeoptionen ... 65
Abb. 50: Beispiel Gruppierung von Layern - Beschriftung der Flurstücksnummern... 66
Abb. 51: Beispiel Nutzung einer PostGIS Datenbank ... 66
Abb. 52: Auszug - Rasterbild der Beschriftungen ... 67
Abb. 53: Beispiel Beschriftung und Drehung (LABELITEM, LABELANGLEITEM) ... 68
Abb. 54: Beispiel GetCapabilities Aufruf für einen WMS Dienst (Lokal) ... 69
Abb. 55: Beispiel GetCapabilities Aufruf für einen WFS Dienst (Lokal)... 70
5
Abb. 56: Mapbender - WMS Capabilities-Dokument einbinden...70
Abb. 57: Mapbender - WFS Capabilities-Dokument einbinden ...70
Abb. 58: Mapbender - WMS Einstellungen - Reihenfolge der Themen ...71
Abb. 59: Mapbender - WMS Einstellungen ...71
Abb. 60: Mapbender - WMS Einstellungen - Layer Auflistung ...72
Abb. 61: Mapbender - WMS Einstellungen - Gruppierung von Layern...72
Abb. 62: Mapbender - WMS Einstellungen - Layer-Steuerung; Sachdatenabfrage ...73
Abb. 63: Mapbender - WMS Einstellungen - Darstellungsmaßstab; Reihenfolge; WFS ...73
Abb. 64: Mapbender - WFS Einstellungen - Layerauswahl...74
Abb. 65: Mapbender - WFS Einstellungen - Sonstige Einstellungen ...74
Abb. 66: Mapbender - WFS Einstellungen - Element Auflistung...75
Abb. 67: Mapbender - WFS Einstellungen - Element Einstellungen...75
Abb. 68: Auskunftssystem - Oberfläche ...77
Abb. 69: Auskunftssystem - Oberflächen-Elemente editieren ...78
Abb. 70: Auskunftssystem - Suchabfrage über einen Suchbegriff...81
Abb. 71: Auskunftssystem - Druckeinstellungen...82
Abb. 72: Auskunftssystem - Themen-Auflistung...83
Abb. 73: Auskunftssystem - Legende ...84
Abb. 74: Auskunftssystem - WMC-Dokument laden ...85
Abb. 75: shptree - Einteilung der shp-Dateien in Blöcke - Thema Wasser...87
Tabellenverzeichnis
Tabelle 1: Klassensystem des Simple Feature Model ...16
Tabelle 2: Bereiche von Geometrien ...16
Tabelle 3: Zeichenerklärung für 9IM-Matrix ...17
Tabelle 4: Symboldefinitionen ...38
Tabelle 5: Softwarekomponenten...59
Tabelle 6: Auskunftssystem - geometrische Grundfunktionen ...80
Tabelle 7: Auskunftssystem - Abfragefunktionen...82
Tabelle 8: Auskunftssystem - Themensteuerung...84
Tabelle 9: Auskunftssystem - Sonstige Funktionen ...85
Tabelle 10: Performance - Ladezeiten von Luftbildern...87
1 - Einleitung zum Thema und Anforderungsprofil
7
1 Einleitung zum Thema und Anforderungsprofil
Als Ziel dieser Ausarbeitung sollte ein Auskunftssystem für die kommunale Verwaltung
entstehen. Für die Nutzung des Auskunftssystems sollte ausschließlich Open Source Software
benötigt werden, um Kosten für Lizenzen und Software Beschaffung möglichst gering zu
halten. ArcView wurde nur für die Umsetzung genutzt und wird im späteren
Auskunftssystem, als Software-Komponente, nicht mehr benötigt (siehe Tabelle 5:
Softwarekomponenten). Zu diesem Zweck empfiehlt sich eine Web-GIS-Lösung. Dabei wird
nur eine Lizenz für einen zentralen Server benötigt. Alle Nutzerstellen können danach über
einen einfachen Webbrowser darauf zugreifen. Die Software Lösung sollte zunächst für das
Intranet einer jeweiligen Kommune konzipiert werden, sodass gewisse
Sicherheitsbeschränkungen, welche für das Internet notwendig wären, vorerst vernachlässigt
werden konnten.
Das Open Geospatial Consortium (OGC) hat eine Reihe von Standards entwickelt, welche
zum Ziel haben Geo-Daten durch so genannte Geo-Daten-Dienste über Webtechnologien zur
Verfügung zu stellen. Einige dieser Dienste sollen für diese Arbeit berücksichtigt werden. Die
Berücksichtigung von OGC Diensten war bei der Umsetzung wichtig, weil z.B. nicht jede
kleinere Kommune ihre Daten selber erfasst und vorhält. Viele öffentliche Stellen erlauben
den Zugriff auf ihre Daten über das Netz. Mit diesen Daten kann dann gearbeitet werden,
ohne dass unbedingt selber Daten vorgehalten werden müssen. Der Vorteil hierbei liegt auch
an der Aktualität. Werden Daten nur an einer Stelle vorgehalten (wünschenswert beim
Erfasser), sind die Daten an dieser Stelle in der Regel auch die aktuellsten, welche zur
Verfügung stehen. Diese Vorraussetzungen sind u.a. auch der Grund, warum auf weitere
Möglichkeiten eines Desktop Geoinformationssystems wie z.B. die Digitalisierung usw.
zunächst verzichtet werden sollte.
Um das Programm portabel, erweiterbar und offen zu halten, ist es notwendig verschiedene
Katasterformate in unterschiedlichen Datenformaten integrieren zu können. Die endgültige
Lösung bezieht sich in diesem Fall auf einen Musterdatenbestand der Stadt Dissen am
Teutoburger Wald (kurz Dissen aTW). Vorlage der Umsetzung ist ein vorhandenes Desktop-
Projekt, in einer etwas veralteten Geomedia-Umsetzung, welches bisher die Grundlage der
täglichen Arbeit der Kommune war. Dieses veraltete System war auch ein Hauptgrund,
warum überhaupt ein solches Web-GIS auf den Markt gebracht werden sollte. Um den
Kommunen eine Umstellung auf ein neues System zu erleichtern und die Bedienung
möglichst einfach zu halten, sollte sich das neue Intranetsystem in Bedienung und Funktion
nach Möglichkeit eng an der bisher vorhandenen Lösung orientieren. Hierbei war auch
wichtig den Mitarbeitern eine deutschsprachige Version an die Hand zu geben, um die
Einführung neuer Software so angenehm wie möglich zu machen. Ein Verkaufsargument der
zu entwickelnden Software ist die Integration von benötigten Grundlagen-Daten, wie z.B. die
ALK-Daten, das Wasser- und Kanalnetz der Gemeinde, aktuelle Bebauungspläne der Stadt,
sowie Hintergrund-Luftbilder des Gemeindegebietes im Rasterformat. Die Möglichkeit Daten
in verschiedenen Formaten, wie z.B. shp, dgn, dxf, gif, ecw, usw. einzulesen, soll bei der
Umsetzung berücksichtigt werden.
Die graphische Ausprägung sollte annähernd den Fachvorschriften entsprechen. Eine
besondere Beachtung finden hierbei die Beschriftungen der einzelnen Themen. Diese
Textobjekte sollen neben der Einhaltung der Fachvorschriften auch in Position, Ausrichtung
und Größe korrekt verarbeitet werden und nach Möglichkeit ein- bzw. ausblendbar sein.
Um sich von anderen Produkten auf dem Markt zu unterscheiden und besser auf die
Kommunen als Kunden einzugehen, wird die gesamte Software Lösung, wie schon erwähnt,
mit deutscher Oberfläche umgesetzt. Dazu gehören neben den Beschriftungen und Tooltipps
auch die Online Hilfe und die zugehörigen Handbücher.
1 - Einleitung zum Thema und Anforderungsprofil
8
Abfragemöglichkeiten der Sachattribute über die Selektion im Kartenbild oder die Eingabe
eines Suchbegriffes, sowie die Druckausgabe als pdf-Datei gehören zu den Grundfunktionen
genauso wie Navigationsmöglichkeiten (Zoom, Pan, usw.) der Karte.
Für die Konzeption des Systems sollte eine umfangreiche Marktanalyse der vorhandenen
Open Source Software Möglichkeiten als Grundlage dienen. Zunächst sollten einige Geo-
Daten-Server untersucht und im Anschluss einige passende Clients auf die benötigten
Funktionen hin analysiert werden, bevor in einem zweiten Schritt die Umsetzung mit den
gewählten Komponenten realisiert werden soll.
Zusammenfassend soll ein im Intranet lauffähiges Geoinformations- und Auskunftssystem,
für unterschiedliche Katasterformate, in verschiedenen Datenformaten realisiert werden.
Hierbei sollen bestimmte Grundfunktionen bereitgestellt und OGC Standards eingehalten
werden. Grundlage der Konzeption und Umsetzung soll eine umfangreiche Marktanalyse
passender Open Source Software sein.
Aus dieser Zusammenfassung und der anschließenden Umsetzung wurde folgende
Themenbeschreibung abgeleitet:
"Marktanalyse, Konzeption und Umsetzung eines Intranet-Auskunftssystems für
die kommunale Verwaltung auf der Basis von Open Source Software wie UMN
Mapserver und Mapbender und unter Berücksichtigung von OGC-
Spezifikationen."
2 Umzusetzender Musterdatenbestand (Ausgangsdaten)
Für die Konzeption und Umsetzung des Auskunftssystems wurde zunächst ein
Musterdatenbestand aufgebaut. Als Musterdatenbestand wurde ein bestehendes Projekt der
Stadt Dissen am Teutoburger Wald genutzt. Wie schon erwähnt, soll sich das neue System in
Bedienung, graphischer Ausprägung und Oberfläche eng an die bisher verwendeten
Geomedia Desktop Lösungen anlehnen. Zu diesem Zweck wurde ein Geomedia Projekt der
Stadt Dissen genutzt und die zugehörigen Projekt-Daten in das neue Auskunftssystem
integriert. Um einige Softwarekomponenten zum Erstellen von map-Dateien nutzen zu
können, wie z.B. Avein oder das Gix-Export-Tool (siehe Kapitel 4.5.1 Einleitung Konverter
Software), wurde das gleiche Projekt mit identischen Musterdaten auch als ArcView-Projekt
zur Verfügung gestellt. Der umzusetzende Datenbestand soll an dieser Stelle anhand des
ArcView-Projektes näher beschrieben und die einzelnen Themen kurz erläutert werden. Eine
detaillierte Beschreibung der eigentlichen Umsetzung und Integration der Daten erfolgt im
späteren Kapitel über das Auskunftssystem (siehe Kapitel 5.1 Umsetzung des
Musterdatenbestands (Besonderheiten und Schwierigkeiten). Das ArcView-Projekt besteht
aus mehreren Themen unterschiedlicher Vektor- und Rasterformate (siehe Abb. 1: Teil des
Musterdatenbestands im ArcView-Projekt). Wegen der besseren Übersicht, sollen diese
Themen hier schon einmal in sechs Themengruppen zusammengefasst werden. Diese Themen
werden auch später im Auskunftssystem angepasst und ergänzt übernommen. Jedes dieser
Themen hat mehrere Unterthemen.
-
Luftbilder
-
Übersicht
-
Bebauungsplan-Übersicht
-
ALK
-
Bebauungspläne (später im Auskunftssystem)
-
Wasser
-
Kanal
2 - Umzusetzender Musterdatenbestand (Ausgangsdaten)
9
Die Luftbilder liegen gekachelt in einer Größe von 5000x5000 Pixeln vor. Zu jeder jpg-
Bilddatei existiert eine jgw-World-Datei mit der zugehörigen Georeferenzierung. Die
Luftbilder decken das Gebiet der Gemeinde Dissen aTW als Hintergrund ab.
Zur Übersicht gehört eine Google Map. Dieses ebenfalls georeferenzierte Kartenbild (tif-
Datei + zugehörige tfw-World-Datei) deckt das komplette Gemeindegebiet ab und dient zur
groben Orientierung. Für höhere Zoom-Stufen ist die Auflösung des Bildes nicht ausreichend.
Die Gemeindegrenze liegt als flächenhafte shp-Datei vor. Die Fläche ist dabei transparent
dargestellt, sodass nur der Umring als Gemeindegrenze im Kartenbild zu sehen ist.
Die Bebauungspläne beziehen sich auf das Stadtgebiet Dissen aTW. Hierbei sind die aktuell
gültigen Flächen der Bebauungspläne der Stadt dargestellt. Eine weitere shp-Datei zeigt die
Änderungen der verschiedenen Bebauungspläne in unterschiedlichen Änderungsstufen. Über
die ArcView Tooltipp Funktion lassen sich zu jeder Fläche die zugehörigen Pläne als pdf-
Datei aufrufen. Im späteren Auskunftssystem sollen sich georeferenzierte Bilddateien der
Pläne über die Flächen einblenden lassen und bei Bedarf auf sollen die pdf-Dateien, aus dem
System heraus, geladen werden können.
Abb. 1: Teil des Musterdatenbestands im ArcView-Projekt
Die ALK des Gemeindegebietes liegt in verschiedenen Vektor-Shapes vor. Neben den
Flurstücken, den Gebäuden mit Schraffuren usw. und den unterschiedlichen Nutzungsarten,
werden auch politische Grenzen und Flurgrenzen dargestellt. Als Besonderheit gibt es noch
einzelne shp-Dateien für die Bruchstriche der Flurstücksnummern und Zuordnungspfeile für
die Flurstücksnummern, falls diese nicht in die Fläche passen sollten. Die Flurstücksnummern
werden getrennt nach Zähler und Nenner in jeweils einer AutoCAD dwg-Datei gespeichert
3 -
OGC Spezifikationen
10
und somit nicht automatisch anhand der Flurstücke beschriftet. Dadurch soll die Lesbarkeit
verbessert werden, wenn Flurstücksnummern bei sehr kleinen Flurstücken nicht in die Fläche
geschrieben werden, sondern mit einem Zuordnungspfeil daneben notiert sind. Diese
Problematik bezieht sich auf sämtliche Beschriftungen und wird im späteren Zusammenhang
noch einmal erklärt und soll hier nur erwähnt werden (siehe Kapitel 5.1.8 Umsetzung der
Beschriftungen in den einzelnen Themen). Neben den Flurstücksnummern werden noch die
Hausnummern und topographische Elemente, wie z.B. Straßennamen mit jeweils einer dwg-
Datei beschriftet.
Das Wassernetz der Stadt wird, je nach Durchmesser der verschiedenen Leitungen,
unterschiedlich dargestellt. Grundlage hierfür sind zwei Linien-Shape-Dateien. Die
Beschriftung erfolgt wiederum mit einer dwg-Datei.
Zum Kanalnetz gehören, neben Gullys, Pumpstationen und Druckleitungen u.a., Schächte,
Haltungen und Hausanschlüsse jeweils für Schmutzwasser und Regenwasser. Die linien- bzw.
flächenhaften Daten liegen ebenfalls in shp-Dateien vor. Die Beschriftungen sind in
unterschiedlichen dwg-Dateien gespeichert.
3 OGC Spezifikationen
Das Open Geospatial Consortium, im späteren OGC, hat sich zum Ziel gesetzt, offene,
Hersteller unabhängige Programmschnittstellen zu entwickeln, sowie gebräuchliche GIS-
Funktionalitäten zu standardisieren. Der häufig benutzte Begriff der Interoperabilität soll mit
der Umsetzung von de facto Normen und Standards mit Leben erfüllt werden. Der Nutzen
dieser Standards soll es sein, die Dienste einem möglichst großen Anwenderkreis auf einfache
Weise bereitzustellen. Ziel der Interoperabilität ist es, die Geodatenverarbeitung in bestehende
Informationstechnologien, bzw. entsprechende Software usw. zu integrieren, sowie die
eigentlichen Geodaten durch Geodatendienste zur Verfügung zu stellen und nicht, wie bisher
üblich, in vielen unterschiedlichen Formaten, oft in doppelter Datenhaltung vorzuhalten.
Interoperabilität soll die systemunabhängige Kommunikation zwischen verschiedenen
Informationssystemen ermöglichen, d.h. den einfachen Zugang zu verschiedenen Geo-Daten,
aus verschiedenen Systemen heraus.
In diesem Rahmen sollen hier einmal die OGC- Geodatendienste
-
Web Map Service (WMS)
-
Web Feature Service (WFS)
-
Web Coverage Service (WCS),
der Daten-Verarbeitungsdienst
-
Coordinate Transformation Service (CTS),
sowie die Implementierungsspezifikation
-
Simple Feature Model (SFM)
und die Datenbeschreibungssprache
-
Geography Markup Language (GML)
in ihren Grundzügen erläutert werden. Die nachfolgenden Erläuterungen sind nicht als
abschließend oder vollständig zu bewerten. Sie sollen lediglich einen Überblick verschaffen.
Andere Techniken, wie z.B. der Web Map Context, welcher es zulässt eine Art ,,Projektdatei"
über Sitzungen anzulegen, finden hier nur der Vollständigkeit wegen eine Erwähnung und
werden nicht näher erläutert.
3.1 Einleitung Geo-Daten Dienste
Um in einem herkömmlichen Desktop-Geo-Informations-System (GIS) Daten nutzen zu
können, müssen diese zunächst einmal aus den unterschiedlichen Datenformaten in ein
3 -
OGC Spezifikationen
11
Format überführt werden, welches von dem eingesetzten GIS unterstützt wird. Nachdem die
Daten dann entsprechend importiert wurden, können sie lokal genutzt werden. Beim Export in
ein anderes System müssen wieder alle Daten entsprechend konvertiert und erneut
vorgehalten werden.
Mit Hilfe von Geodatendiensten sollen Konvertierungen zwischen verschiedenen Systemen
und doppelte Datenhaltung überflüssig werden. Geo-Daten sollen in einem für alle Systeme
lesbaren, standardisierten Datenformat über das Internet oder das Intranet bezogen werden
können. Somit entfällt die doppelte Speicherung der Daten, und der Nutzer hat außerdem den
Vorteil immer die aktuellsten Daten zu bekommen, wenn die Datenhaltung ausschließlich
beim Erzeuger erfolgt.
Die Nutzung eines solchen Dienstes kann in einem vorhandenen GIS erfolgen, indem man die
URL des Geodatendienstes bekannt macht, d.h. sich seine gewünschten Parameter und
Zeichenvorschriften usw. auswählt. Das GIS übernimmt dann die Visualisierung der
gewählten Daten.
Die zweite Möglichkeit einen Geodatendienst zu nutzen kann über einen unabhängigen Client
erfolgen, welcher die Möglichkeiten des Internet Protokolls http nutzt. Die einfachste Form ist
ein einfacher Web-Browser, mit dem man URL-Anfragen senden kann. Auf die genaue
Zusammensetzung einer URL und das Prinzip einer Anfrage wird bei der Beschreibung der
einzelnen Dienste noch genauer eingegangen. Um den Nutzer nicht mit der Formulierung von
kompliziert zusammengesetzten URLs und Parametern zu belasten, werden oft graphische
Benutzeroberflächen auf der Basis von HTML, PHP, Javascript oder ähnlichen
Scriptsprachen bereitgestellt. Der Anwender kann dann z.B. seine Layer bequem aus einem
Menü auswählen und muss seine Anfragen nicht selber zusammensetzen. Oft werden hierbei
auch schon geometrische Grundfunktionen wie Zoom oder Pan bereitgestellt.
Im Prinzip gibt es zwei verschiedene Stufen bei der Nutzung eines Geodatendienstes.
Zunächst wird beim Server angefragt, welche Fähigkeiten und Operationen der Service zur
Verfügung stellt (GetCapabilities später). Danach wird in einem zweiten Schritt eine
Anfrage an den Server gestellt. Hierbei werden die angeforderten Daten direkt aus der
angeschlossenen Datenbank geholt. Es ist aber auch möglich, dass der aufgerufene Dienst
einen weiteren Service aufruft und von diesem Daten bezieht, welche er dann weiterleitet. Die
Kombination verschiedener Server erlaubt z.B. auch die Überlagerung von Rasterdaten mit
Vektorgeometrien.
3.2 Überblick über den Web Map Service (WMS)
Der Web Map Service (WMS) des Open Geospatial Consortiums ist ein webbasierter Dienst
im Internet oder Intranet zur Bereitstellung von Kartenausschnitten entweder im Rasterformat
oder vektorbasiert im Datenformat SVG. Ein WMS dient hauptsächlich zur Visualisierung
von Kartenbildern. Die Karten entstehen dabei aus georeferenzierten, geographischen Daten,
welche als digitales Bild angezeigt werden können. Aus den georeferenzierten Daten, wozu
auch Metadaten, wie z.B. Bezugssystem oder Kartenausschnitt usw., gehören, wird ein
Kartenbild generiert und dieses über das ebenfalls standardisierte HTTP-Protokoll übertragen.
Diese beiden Standards im Verbund ermöglichen den technischen Zugriff auf verteilt
vorliegende Geodatenbestände, von verschiedenen Servern, von verschiedenen Orten und aus
unterschiedlichen Systemen heraus. Die Rasterdaten werden über einen standardisierten URL-
Aufruf als Ergebnisbild vom angesprochenen Server generiert und zurückgeschickt. Die
Übermittlung der Daten durch das HTTP-Protokoll erfolgt im GET- oder POST-Verfahren.
Beim POST-Verfahren wird hierbei immer ein kompletter Datenblock über den Request-
Header übermittelt. Dieser Datenblock liegt meist in Form einer XML-Beschreibung vor und
muss nachträglich, z.B. über das Lesen von CONTENT_LENGTH, in eine entsprechende
3 -
OGC Spezifikationen
12
Variable geschrieben werden. Bei der GET-Methode werden zusätzliche Parameter
hintereinander in der Form von ,,key-value" Parametern an die URL angehängt.
Request = ,,GetCapabilities" wäre ein Beispiel für ein ,,key-value" Parameter.
Der WMS ermöglicht drei verschiedene Funktionen bzw. Operationen, welche über den URL-
Aufruf angesprochen werden können. GetCapabilities (siehe Abb. 2: Beispiel WMS
GetCapabilities Aufruf), GetMap (siehe Abb. 3: Beispiel WMS GetMap Aufruf) und
GetFeatureInfo.
Die Operation GetCapabilities gibt ein Capabilities-Dokument zurück. Dieses XML-
Dokument listet zum einen die Diensteigenschaften, wie z.B. den Dienstnamen auf und zum
anderen die Fähigkeiten des Service. Es werden Informationen über die unterstützen
Operationen, das Verhalten im Fehlerfall oder die darstellbaren Layer angezeigt. Der Aufruf
von GetCapabilities soll alle Informationen zurückgeben, welche der Server benötigt um eine
Karte generieren und zurückgeben zu können. Aus einem Capabilities-Dokument lassen sich
alle benötigten Informationen entnehmen, um einen GetMap-Aufruf, welcher im Folgenden
erklärt wird, zusammenzusetzen.
http://www.mapserver.niedersachsen.de/freezoneogc/mapserverogc?
SERVICE=WMS&REQUEST=GetCapabilities&VERSION=1.1.1
Abb. 2: Beispiel WMS GetCapabilities Aufruf
Der GetMap-Aufruf ist die eigentliche Kartenanforderung. Über die Angabe von zusätzlichen
Parametern wie z.B. Größe, Maßstab, Referenzsystem, Layer, usw. (siehe Abb. 3: Beispiel
WMS GetMap Aufruf), generiert der Server ein fest definiertes Ergebnisbild und gibt dieses
zurück zur Visualisierung im Client. Das Ergebnis kann in Rasterformaten wie jpg, png oder
gif oder im Vektorformat svg angefordert werden. Optional lassen sich auch Angaben über
die Transparenz und den Hintergrund machen.
http://www.mapserver.niedersachsen.de/freezoneogc/mapserverogc?
SERVICE=WMS&REQUEST=GetMap&VERSION=1.1.1&
LAYERS=TK100&SRS=EPSG:31467&
BBOX=3436610.5021210127,5769987.98197597,3453389.4978789873,
5782012.01802403&
WIDTH=614&HEIGHT=440&FORMAT=image/png&BGCOLOR=0xffffff&
TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml
Abb. 3: Beispiel WMS GetMap Aufruf
Als letzte Möglichkeit bietet der WMS die Operation GetFeatureInfo an. GetFeatureInfo
ermöglicht es Informationen über ein bestimmtes ausgewähltes Geo-Objekt (meist per
,,Klick" in die Karte) zu erhalten. Die Identifikation erfolgt über die Mausposition. Der Server
errechnet sich intern aus den übergebenen Bildschirmkoordinaten die Weltkoordinaten im
entsprechenden Referenzsystem. Um diese ,,Points-of-Interest" besser auswählen zu können,
wird häufig ein Toleranzbereich um die Punkte gewählt. Da der Server zustandslos
(,,stateless") ist, d.h. keinerlei Daten zu bisherigen Anfragen speichert, müssen bei jedem
GetFeatureInfo-Aufruf die entsprechenden Parameter einer GetMap-Anfrage wiederholt
werden, damit der Server ,,weiß", aus welchen Datensätzen er Informationen anzeigen soll.
Durch den Parameter Query-Layers müssen abfragbare Layer zusätzlich bekannt gemacht
werden. Das Ergebnis ist eine Datei, im ebenfalls per Parameter wählbaren, info_Format (z.B.
text/html). Diese Technik soll es jedem Nutzer bzw. Client ermöglichen, sofern die Software
WMS unterstützt, von jedem Server Daten zu holen. Jeder Client kann sich somit Daten nach
3 -
OGC Spezifikationen
13
eigenem Bedarf laden, diese bei gleichem Bezugssystem überlagernd darstellen und nach
Belieben kombinieren. Ein weiterer Vorteil ist es, dass die Geodaten nur noch beim Erzeuger
vorliegen müssen. Eine doppelte Datenhaltung ist, wie bereits in der Einleitung erwähnt, nicht
mehr notwendig und der Nutzer greift automatisch auf die aktuellsten Daten zu. Als
Anmerkung ist zu erwähnen, dass als Ergebnis immer nur fertig aufbereitete
Kartenausschnitte ausgeliefert werden. Der Nutzer bekommt also keine Geodaten als
Beschreibung, sondern nur Rasterbilder.
3.3 Überblick über den Web Feature Service (WFS)
Der Web Feature Service dient, ähnlich wie der Web Map Service, zur Bereitstellung
verteilter Geo-Daten. Der Dienst liefert, im Gegensatz zum WMS, vollständige Geometrie-
und Sachdaten zu einem Geo-Objekt. Außerdem ist es zusätzlich möglich, Vektorgeometrien
zu lesen, zu ändern und zurückzuschreiben. Der WFS arbeitet auf der Grundlage des Simple
Feature Model des Open Geospatial Consortiums, welches später kurz erläutert wird (siehe
Kapitel 3.6 Überblick über das Simple Feature Model (SFM)). Das Datenaustauschformat
für die Simple Features ist die Geography Markup Language (GML). Eine kurze
Beschreibung von GML erfolgt ebenfalls im Anschluss (siehe Kapitel 3.7 Überblick über
die Geography Markup Language (GML)). Ein Feature ist hierbei eine Beschreibung eines
Objektes der realen Welt mit einem räumlichen Bezug. Die Funktionsweise eines solchen
Dienstes ist genauso wie ein Web Map Service. Ein entsprechender Client stellt eine Anfrage
über angehängte Parameter an eine URL an den Server. Der Server generiert das Ergebnis und
liefert es zurück an den Client. Im Unterschied zum WMS, liefert der WFS aber eine
vollständige Beschreibung der angeforderten Objekte inklusive der Geometrien und der
zugehörigen Sachdaten. Diese Informationen kann der Nutzer nun in einem Kartenbild
nutzen, kombinieren oder verwalten. Dadurch wird z.B. eine Darstellung nach bestimmten
Bereichen möglich wobei eine Selektion nach räumlichen Merkmalen oder nach den
Sachattributen unterstützt wird. Es ist auch die gezielte Suche nach bestimmten Elementen
möglich. Außerdem können zu jedem Objekt die Koordinaten des jeweiligen Bezugssystems
abgefragt werden, was im WMS nicht direkt möglich ist.
Zur Abfrage bietet der WFS bis zu fünf Operationen, die auch durch einen entsprechend
zusammengesetzten URL-String ausgeführt werden können.
Die Funktion GetCapabilities (siehe Abb. 4: Beispiel WFS GetCapabilities Aufruf) gibt,
analog zum WMS, ein XML-Dokument zurück, aus dem die Fähigkeiten und Eigenschaften
des Dienstes entnommen werden können. Zu diesen Informationen gehören die Service
Identifikation, die Eigenschaften des Providers sowie die unterstützten Operationen aus denen
die Angaben für die Anfrage nach einem Geo-Objekt ersichtlich sind.
http://gis.melle.info/ogc/Cadcorp.SIS.ISAPI.dll?
SERVICE=WFS&REQUEST=GetCapabilities&VERSION=1.0.0
Abb. 4: Beispiel WFS GetCapabilities Aufruf
Die GetFeature Operation (siehe Abb. 5: Beispiel WFS GetFeature Aufruf) funktioniert
prinzipiell ähnlich wie die GetMap-Methode des WMS. Das Ergebnis einer GetFeature
Operation ist aber kein Kartenbild, sondern ein bestimmtes Geo-Objekt. Die Anfrage nach
einem Objekt kann dabei raumbezogen, wie z.B. seine geometrische Lage, sein oder nach
seinen Sachattributen gefunden werden. Mit den zurückgegebenen Objekten können dann
weitere Bearbeitungsschritte erfolgen.
3 -
OGC Spezifikationen
14
http://gis.melle.info/ogc/Cadcorp.SIS.ISAPI.dll?
SERVICE=WFS&REQUEST=GetFeature&VERSION=1.0.0&
Typename=ns:Fl_chennutzungsplan
Abb. 5: Beispiel WFS GetFeature Aufruf
Die DescribeFeature Funktion (siehe Abb. 6: Beispiel WFS DescribeFeature Aufruf) gibt eine
Beschreibung des Schemas eines Geo-Objektes zurück. Ein Schema oder Feature Type gibt
die Eigenschaften, Methoden und Beziehungen eines Objektes an und beschreibt somit die
Struktur des Features.
http://gis.melle.info/ogc/Cadcorp.SIS.ISAPI.dll?
SERVICE=WFS&REQUEST=DescribeFeatureType&VERSION=1.0.0
Abb. 6: Beispiel WFS DescribeFeature Aufruf
Web Feature Services, die nur diese Operationen anbieten, erlauben nur lesenden Zugriff und
ermöglichen noch keinerlei Manipulation oder Modifizierung der Daten. Services dieser Art
werden als Basic-WFS oder Read-Only WFS bezeichnet. Werden zusätzlich noch
Manipulationsmöglichkeiten bereitgestellt, so ist es ein Transaction-WFS, der die
gleichnamige Transaction Operation ermöglicht.
Die zusätzliche Transaction Operation stellt Funktionen zum Verwalten und Abfragen der
Objekte. Neue Instanzen können erstellt, Objekte gelöscht, geändert oder bearbeitet werden.
Dadurch sind z.B. Digitalisierungen möglich. Durch den optionalen Aufruf von LockFeature,
kann der Nutzer die Sperrung eines Objektes durchführen. Das ist nützlich, wenn das Objekt
bearbeitet werden soll, um sicherzustellen, dass es während der Bearbeitung nicht von
anderen Anwendern geändert werden kann. Objekte können auch direkt gesperrt aufgerufen,
um dann bearbeitet zu werden. So eine Kombination bekommt man mit der Funktion
GetFeatureWithLock.
3.4 Überblick über den Web Coverage Service (WCS)
Ähnlich dem Web Map Service dient der Web Coverage Service der Bereitstellung von
Rasterdaten im Internet bzw. Intranet. Die Rasterdaten definieren sich aber in diesem Fall als
digitale, rasterisierte, raumbezogene Daten mit zusätzlichen, differenzierten, räumlich
veränderbaren Attributen. Diese so genannten Coverages sind z.B. Luftbilder mit
unterschiedlichem Aufnahmedatum. Ein Coverage beschreibt einen abgeschlossenen Raum in
einem raumbasierten Datenmodell. Durch die zusätzlichen Attribute werden keine statischen
Ergebnisbilder ausgeliefert, sondern Geo-Daten mit Detail-Beschreibungen und
Sachinformationen in Form von Coverages, also die Daten in ihrer ursprünglichen Semantik.
Diese können visualisiert, verarbeitet, interpretiert oder analysiert werden. Die Abfrage nach
Rasterbildern oder die ebenfalls mögliche Abfrage nach Attributen erfolgt ähnlich dem WMS.
Die Operation GetCapabilities ermöglicht, identisch zum WMS und WFS, die Abfrage einer
Kurzbeschreibung des Dienstes, die möglichen, abfragbaren Coverages usw. in Form eines
XML-Dokuments.
Die Eigenschaften und Attribute eines Coverages gibt die Methode DescribeCoverage,
ähnlich der DescribeFeatureType Operation beim WFS, an. Dem Ergebnis sind u.a.
unterstützte Referenzsysteme, der Wertebereich der Daten oder die unterstützten Formate zu
entnehmen.
Die eigentliche Anforderung nach einem Coverage erfolgt durch den Aufruf von
GetCoverage. Dieser Aufruf ist ebenfalls analog zu den anderen Services zu sehen. Als
3 -
OGC Spezifikationen
15
Parameter übergibt man z.B. das gewünschte Format, das Bezugssystem, den zeitlichen
Rahmen oder die gewünschte Größe des geforderten Bildes.
3.5 Überblick über den Coordinate Transformation Service (CTS)
Der Coordinate Transformation Service ist ein Verarbeitungsdienst im Internet. Der CTS
funktioniert ähnlich wie die anderen vorgestellten Geodatendienste. Zunächst werden
Anfrageparameter in einem standardisierten Format an den Dienstserver geschickt. Der Server
verarbeitet diese Anfrage und überträgt das Ergebnis zurück. Der CTS im Speziellen
ermöglicht eine webbasierte Transformation von Raster- oder Vektordaten in andere bekannte
Koordinatensysteme. Der Server ist in der Lage aus dem überlieferten Datensatz das
Koordinatensystem zu lesen. Mit Hilfe von Listen der entsprechenden Projektionen und
Referenzsysteme und den dazugehörigen Transformationsregeln, ist es dem Server möglich,
die Daten in das gewünschte Format zu transformieren und als Ergebnis zurückzuliefern. Der
Dienst läuft auf der Grundlage von GML (Geography Markup Language) und kann beliebig
viele Dimensionen bearbeiten.
Der Nutzen eines solchen Services soll darin liegen, dem Anwender den Datenimport zu
erleichtern. Falls kein passendes, darstellbares Koordinatensystem für die Daten vorliegt,
sollen die Daten automatisch im Hintergrund an den CTS geschickt und transformiert werden.
Das hat den Vorteil, dass Nutzer beim Import gewünschter Geo-Daten deren
Koordinatensystem nicht mehr kennen müssen, sondern sich eines aus einer Liste auswählen
können. Der Dienst ist noch in der Entwicklung und somit noch nicht in der Anwendung.
3.6 Überblick über das Simple Feature Model (SFM)
Das Simple Feature Model ist eine Implementierungsspezifikation des OGC. Das Modell soll
einen strukturierten Zugriff auf Geo-Objekte ermöglichen und dessen Binärstrukturen, die
Normalform sowie Methoden definieren. Durch die Standardisierung wird ein transparenter
Zugriff auf Geo-Daten in verschiedenen, verteilten Systemen ermöglicht.
Simple Features sind hierbei ,,einfache" Geo-Objekte, wie z.B. Punkte, Strecken oder
Polygone, welche die Objekte der realen Welt darstellen sollen. Durch die Einführung des
Simple Feature Models wird es möglich, dass GIS-Software Funktionen für den Zugriff oder
die Manipulation von räumlichen Informationen, auch unter verschiedenen Technologien, zur
Verfügung stellen kann. Das Simple Feature Model ist eine Beschreibung der
Vektorgeometrien von Geo-Objekten in maximal zwei Dimensionen, sowie deren
topologischen Beziehungen. Das Modell verweist auf ein räumliches Bezugssystem und
basiert auf dem komplexeren Feature Geometry Model. Auf das Feature Geometry Model soll
hier aber nicht näher eingegangen werden.
Zum Verständnis des Aufbaus soll hier kurz das Datenmodell anhand des Klassensystems
erläutert werden (siehe Tabelle 1: Klassensystem des Simple Feature Model). Im
Klassensystem des Simple Feature Model werden drei geometrische Primitive deklariert:
-
Point (Punkt)
-
Curve (Strecken, abstrakte Klasse)
-
Surface (Flächen, abstrakte Klasse)
Die Zusammenfassung von mehreren Objekten einer gleichen Klasse und eines gleichen
Koordinatensystems wird der Klasse GeometryCollection zugeordnet.
Streckenzüge können in LineString, einer direkten Unterklasse von Curve, gespeichert
werden. LineString hat wiederum zwei mögliche Unterklassen. Mit Hilfe von Line lassen sich
Streckenzüge speichern und die Klasse LinearRing ermöglicht geschlossene Streckenzüge.
3 -
OGC Spezifikationen
16
Hierbei dürfen sich keine Streckenabschnitte überschneiden und von jedem Stützpunkt dürfen
höchstens zwei Strecken abgehen.
Die Unterklasse Polygon der abstrakten Klasse Surface ermöglicht die Modellierung von
Polygonen. Polygone werden definiert durch einen äußeren Rand, welcher die
Vorraussetzungen für einen geschlossenen Streckenzug aufweisen muss, und beliebig vielen
inneren Aussparungen. Die inneren Ringe müssen ebenfalls die Voraussetzungen eines
geschlossenen Streckenzuges erfüllen, aber zwei innere Ringe dürfen sich in höchstens einem
Punkt schneiden.
Punkt
Strecke
Fläche
Geometrie-Sammlung
Oberklasse Point Curve
Surface
GeometryCollection
- LineString Polygon
MultiPoint,
MultiCurve,
MultiSurface
Unterklassen
- Line,
LinearRing
MultiPolygon,
MultiLineString
Tabelle 1: Klassensystem des Simple Feature Model
Mehrere Geometrien lassen sich zu einer Gruppe oder Geometriesammlung zusammenfassen.
Einzige Voraussetzung hierfür ist, dass sie ein einheitliches Koordinatensystem haben. Es
lassen sich also mehrere Punkte oder mehrere Strecken bzw. Streckenzüge oder mehrere
Polygone gruppieren. Die entsprechenden Unterklassen für die Speicherung heißen
MultiPoint, MultiLineString, MultiPolygon.
Für die einzelnen Geometrien gibt es unterschiedliche Methoden. Es gibt für jede Geometrie
entsprechende Zugriffsfunktionen, um z.B. die X,Y-Koordinaten abzufragen oder die
Dimension, den Geometrietyp, das Koordinatensystem oder das minimal umgebende
Rechteck zu erfragen. Daneben gibt es noch einige Geometrie spezifische Methoden, wie z.B.
die Abfrage nach dem n-ten Simple Feature einer Geometriesammlung oder der Test, ob eine
Geometrie einfach ist. Ein Streckenzug ist einfach, wenn die einzelnen Streckenabschnitte
keine Überlappungen aufweisen außer in den Stützpunkten.
Außer der Geometrie lässt sich mit dem Simple Feature Model auch die Topologie eines
Objektes, bzw. die Beziehung von zwei Objekten zueinander abbilden. Zu diesem Zweck
wurde das 9 Intersection Model (9IM) implementiert. Jedes Geometrieobjekt besteht aus
einem Rand, dem Inneren und dem Äußeren der Geometrie (siehe Tabelle 2: Bereiche von
Geometrien). Ein Polygon hat z.B. einen äußeren Ring, sowie eventuell innere Ringe. Diese
bilden zusammen den Rand der Geometrie. Alle Punkte innerhalb des äußeren Rings, die
nicht innerhalb der inneren Ringe liegen, bezeichnen das Innere. Der übrige Datenraum ist das
Äußere.
Punkt
Strecke
Fläche
Rand
-
Streckenendpunkte
Äußerer Ring + innere Ringe
Äußeres
Übriger Datenraum Übriger Datenraum
Übriger Datenraum
Inneres Punkt
Restliche
Streckenpunkte
Punkte innerhalb des äußeren
Rings und nicht innerhalb der
inneren Ringe
Tabelle 2: Bereiche von Geometrien
Grundüberlegung bei diesem Modell ist, dass ein Punkt nicht in zwei Bereichen gleichzeitig
liegen kann. Verglichen werden jeweils das Innere, das Äußere und der Rand einer Geometrie
3 -
OGC Spezifikationen
17
mit dem Inneren, dem Äußeren und dem Rand einer zweiten Geometrie (siehe Tabelle 3:
Zeichenerklärung für 9IM-Matrix).
Geometrie A
Geometrie B
Rand AR BR
Äußeres AA
BA
Inneres AI
BI
Tabelle 3: Zeichenerklärung für 9IM-Matrix
Wenn zwei Geometrien bezüglich ihrer Topologie zueinander verglichen werden, so ergeben
sich neun unterschiedliche Kombinationen von möglichen Beziehungen. Die Darstellung
erfolgt in einer 3x3-Matrix (siehe Abb. 7: 9IM-Matrix).
AI BI
AI BR
AI BA
AR BI
AR BR
AR BA
AA BI
AA BR
AA BA
Abb. 7: 9IM-Matrix
Die Matrix beschreibt jede Geometrie mit einem boolschen Wert true oder false. Liegt ein
Schnitt zwischen den Geometrien vor, so ist der Wert true, wenn kein Schnitt vorliegt ist der
Wert false. In der Theorie können somit 2
9
unterschiedliche Matrizen entstehen. Praktisch
bleiben aber nur 8 sinnvolle topologische Beziehungen, da sich die meisten von selber
ausschließen und in der Realität nicht möglich sind. Es kann z.B. keine Matrix vorkommen in
der alle Werte false sind. Wenn sich das Innere eines Polygons mit dem Inneren einer anderen
Fläche nicht schneidet (AI BI = FALSE), so muss zwangsläufig ein Schnittpunkt der
jeweiligen Äußeren vorliegen (AA BA = TRUE) (siehe Abb. 8: Topologie zweier
Geometrien (2 Polygone) und Abb. 9: 9IM-Matrix mit boolschen Werten für Abb.8).
Abb. 8: Topologie zweier Geometrien (2 Polygone)
FALSE FALSE TRUE
FALSE FALSE TRUE
TRUE TRUE TRUE
Abb. 9: 9IM-Matrix mit boolschen Werten für Abb.8
Damit auch Beschreibungen der Art des Schnittpunktes möglich werden, wird das 9IM
erweitert. Statt die Schnitte mit boolschen Werten zu beschreiben, sind im Dimensionally
Extended 9 Intersection Model (DE-9IM) vier unterschiedliche Werte in der Matrix erlaubt.
Geometrie A
AI
BI
BA
BR
AR
AA
Geometrie B
3 -
OGC Spezifikationen
18
· -1 = kein Schnittpunkt
· 0 = Schnitt durch einzelne Punkte
· 1 = Schnitt durch Linien und eventuell zusätzliche Punkte
· 2 = Schnitt durch Flächen und eventuell zusätzliche Punkte oder Linien
-1 -1 2
-1 -1 1
2 1 2
Abb. 10: DE-9IM-Matrix für Abb.8
Die Beziehungen können abschließend durch sechs Zustände beschrieben werden. Entweder
liegt ein Schnitt vor (0,1,2), dann wird der Wert T in die Matrix eingetragen. Wenn kein
Schnitt vorliegt (-1), wäre der Wert mit F deklariert. Wenn eine Beziehung sich durch die
anderen schon von selbst ergibt, wie im Beispiel Abb.8, und somit nicht mehr wichtig ist (-
1,0,1,2) steht ein * in der Matrix. Die Werte 0,1,2 beim Schnitt durch Punkte, Linien oder
Flächen können auch weiterhin genutzt werden, wenn der Schnitt eindeutig ist. Beim Schnitt
von zwei Strecken in einem Punkt sind dadurch alle anderen Beziehungen klar und eindeutig
und werden nicht mehr als wichtig untersucht (siehe Abb. 11: Topologie zweier Geometrien
(2 Geraden)) und Abb. 12: abschließende DE-9IM-Matrix für Abb.11).
Abb. 11: Topologie zweier Geometrien (2 Geraden)
0 * *
* * *
* * *
Abb. 12: abschließende DE-9IM-Matrix für Abb.11
Es ergeben sich abschließend 8 wichtige, sinnvolle, topologische Beziehungen zwischen zwei
Geometrien A und B.
· A disjoint B ( A berührt B nicht (getrennt/disjunkt) )
· A touches B ( A berührt B )
· A crosses B ( A schneidet B ( Schnitt ist bei den Geometrien unterschiedlich A<B ) )
· A crosses B ( A schneidet B ( Schnitt ist bei beiden Geometrien gleich 1 ) )
· A within B ( A liegt innerhalb von B )
· A overlaps B ( A überlappt B ( Schnitt ist bei beiden Geometrien gleich aber 1 ) )
· A overlaps B ( A überlappt B ( Schnitt ist bei beiden Geometrien gleich 1 ) )
Im Simple Feature Model sind eine Reihe verschiedener Methoden implementiert, um die
Topologie oder Geometrie zu untersuchen. Es kann erfragt werden, ob eine bestimmte
topologische Beziehung zwischen zwei Geometrien vorliegt. Außerdem gibt es Möglichkeiten
AI
BR
AR
BI
Geometrie A Geometrie B
4-
Marktanalyse: Open Source Software
19
zur Distanzabfrage und zur Pufferberechnung. Auch die konvexe Hülle kann berechnet und
der Schnitt oder die Differenz kann ebenfalls durch Methodenaufruf erzeugt werden.
3.7 Überblick über die Geography Markup Language (GML)
GML ermöglicht eine XML-basierte Beschreibung von Geo-Objekten. Die Geo-Objekte
können dabei in maximal drei Dimensionen beschrieben werden. Die Beschreibung bezieht
sich hierbei auf die Geometrie, temporale Eigenschaften und die Topologie, bzw. auf die
Beziehungen zwischen Geo-Objekten.
GML ist eine Datenbeschreibungssprache, bzw. ein Datenformat auf der Grundlage einer
XML-Implementierung für Geo-Daten. Die GML3-Spezifikation gibt sozusagen einen
Modellierungsrahmen vor. Der Aufbau ist dadurch sehr ähnlich zu XML. GML ist das
Standard-Austauschformat für den Web Feature Service. Das GML Schema soll die
Modellierung, Übertragung und Speicherung von geographischen Informationen ermöglichen.
Die Beschreibung bezieht sich hierbei z.B. auf das Referenzsystem, die Geometrie, die
Topologie, die Zeit oder Maßeinheiten, usw. (z.B. Coordinate Reference System, Features,
Feature Collection, Geometry, Topology). Der GML-Standard soll offen und Software
unabhängig bzw. Produkt neutral sein. Modelliert wird GML anhand der
Modellierungskonzepte der ISO 19100-Serie einschließlich geographischer und nicht
geographischer Eigenschaften.
Quellen: Kapitel 3 - OGC Spezifikationen
[WEB.MAP], [Standards], [Normen], [OGC], [Wheregroup], [FerGI], [FISCHER],
[MITCHELL]
4
Marktanalyse: Open Source Software
4.1 Open Source Definition
Die Idee des freien Zugangs zu Wissen, Informationen oder auch speziell Software ist in der
Öffentlichkeit viel diskutiert und erörtert worden. Aus diesen Diskussionen sind eine ganze
Reihe unterschiedlicher Begriffe und Definitionen hervorgegangen, die hier nicht alle
abschließend erklärt werden können. Es gibt z.B. die Free Software Definition (FSD), Open
Source, Open Content, usw.. Die Online Bibliothek Wikipedia ist ein gutes Beispiel für den
freien Zugang zu Wissen und Informationen in Form des Open Content.
Im Rahmen dieser Ausarbeitung soll versucht werden den Begriff Open Source und die damit
verbundene Definition etwas genauer zu erörtern. Der Begriff Open Source soll sich hierbei
auf Software beziehen, auch wenn er in anderer Literatur häufig auch in anderen
Zusammenhängen gebraucht wird.
Open Source geht aus der Free Software Definition hervor und stimmt in den Grundzügen
damit überein. Die Free Software Definition von Richard Stallman spricht von vier Freiheiten,
welche eine Software haben muss, um als ,,frei" zu gelten.
1) Ein Programm darf für jeden Zweck eingesetzt werden
2) Ein Programm darf untersucht werden, um es zu verstehen und den Wünschen des
Benutzers angepasst werden
3) Ein Programm darf beliebig oft kopiert und an andere weitergegeben werden
4) Ein Programm darf beliebig verbessert und dann der Allgemeinheit zur Verfügung
gestellt werden
4 -
Marktanalyse: Open Source Software
20
Aus dieser Grundlage entwickelte die Open Source Initiative (OSI) die Open Source
Definition (OSD). Die Open Source Definition (OSD) formuliert die Ziele und Grundsätze
der FSD etwas genauer. Die Initiative hatte dabei zum Ziel, dass freie Software nicht
gleichgesetzt werden sollte mit kostenloser Software, da der Begriff ,,free" oft zu
missverständlichen Assoziationen geführt hatte. Zum anderen wurde versucht ein wenig Licht
ins Dunkel der vielen unterschiedlichen Lizenz-Modelle zu mehr oder weniger freier Software
zu bringen. Die Open Source Definition soll einen Standard für Lizenzen definieren, welcher
von Software Firmen anerkannt wird. Im Detail gibt die Open Source Definition neun Punkte
vor, die eine Software erfüllen muss. Wird die Software-Lizenz dann von der OSI abgesegnet,
so darf sie sich Open Source Software nennen.
Die folgenden neun Grundsätze für Open Source Software wurden in der OSD festgelegt.
1) Freier Zugang und Weitergabe: Die Software muss frei zur Verfügung stehen und die
Lizenz erlaubt eine freie Weitergabe oder einen Verkauf innerhalb einer Distribution
mit anderer Software ohne Lizenzgebühren für die Nutzung.
2) Quellcode offen: Die Software muss vollkommen offen sein, d.h. dem Nutzer muss
der Quellcode zugänglich sein in einer von einem Programmierer lesbaren Form.
3) Veränderung: Die Software darf beliebig, den eigenen Wünschen entsprechend,
angepasst und verändert werden. Abgeleitete Arbeiten dürfen unter derselben Lizenz
weiterverbreitet oder veröffentlicht werden.
4) Quellcode des Autors: Der Quellcode des Autors muss ersichtlich bleiben, z.B. durch
eine neue Versionsnummer, einen neuen Namen oder in einem zusätzlichen
Dokument.
5) Keine Diskriminierung: Die Software darf nicht bestimmten Personen oder Gruppen
vorenthalten werden. Die Lizenz darf z.B. nicht verbieten das Programm Mitarbeitern
eines Atomkraftwerkes oder einer Abtreibungsklinik zu überlassen.
6) Keine Nutzungsbeschränkungen: Die Software darf nicht einer bestimmten
Nutzungsbeschränkung unterliegen. Die Software darf z.B. auch zur Entwicklung von
Waffen benutzt werden oder zur Steuerung eines Kernkraftwerkes dienen.
7) Lizenzweitergabe: Jede Person, die die Software nutzt hat die gleichen Rechte an dem
Programm, wie alle anderen Nutzer auch, ohne dass eine eigene Lizenz notwendig ist
oder erworben werden muss.
8) Lizenz Programmunabhängig: Die Lizenz darf nicht nur für ein bestimmtes
Programmpaket gelten. Für einzelne Programmteile gilt die Lizenz des gesamten
Programmpakets.
9) Keine Einschränkung anderer Software: Die Lizenz darf keine andere Software
beeinträchtigen. Das Programm darf nicht zwangsläufig nur mit anderen
Programmteilen eingesetzt werden. Bei mehreren Programmen auf einer CD
beispielsweise, müssen die anderen Produkte auf der CD nicht zwangsläufig auch
quelloffen zugänglich sein.
Aus diesen Definitionen ergeben sich einige Vorteile, aber auch einige Beschränkungen
gegenüber kommerziellen Lösungen, die hier einmal exemplarisch aufgeführt werden sollen.
Die kommerzielle Software beschränkt sich oft nicht auf einen bestimmten Nutzerkreis,
sondern versucht die grundlegenden Anwendungsfälle und Bedürfnisse abzudecken, woraus
ein recht großer Funktionsumfang resultiert. Konsequenz ist außerdem, dass sehr spezielle
Funktionen in der Standard-Ausführung oft nicht ins Programm integriert werden können, da
sich die Entwickler meist auf die allgemein geforderten, oft benötigten Methoden
beschränken. Die Realisierung spezieller Funktionen ist somit sehr aufwändig und teuer. Da
Hersteller oft versuchen ihre eigenen Standards durchzusetzen, sind die Programme oft wenig
kompatibel und es sind nur wenige Erweiterungen erhältlich. Auch das äußere
Erscheinungsbild ist auf den Hersteller zugeschnitten und erlaubt, wegen des nicht offenen
4 -
Marktanalyse: Open Source Software
21
Quellcodes, in der Regel keinerlei individuelle Anpassungen. Der große Funktionsumfang
und der, oft im Preis inbegriffene, direkte, individuelle und persönliche Support bzw. Kontakt
zum Hersteller, ist aber großer Vorteil, um auf kommerzielle Software zurückzugreifen.
Open Source Software besticht meist durch die geringen Anschaffungskosten, die weite
Verbreitung und der daraus resultierenden großen Flexibilität. Durch den offenen Quellcode
kann jedes System an die individuellen Wünsche angepasst werden und auch die Erweiterung
auf spezielle Funktionen ist leichter möglich. Durch die Nutzung von Standards ist das
Programm offen und kompatibel zu anderer Software. Dadurch ist man nicht an einen
bestimmten Anbieter gebunden und unabhängiger. Durch die große Entwicklergemeinde
solcher Software, kann flexibler und schneller auf Fehler reagiert werden und die
Entwicklung im Ganzen ist in der Regel schneller. Hier kann aber auch gegenübergestellt
werden, dass es durch die fehlende, zentrale Organisation meist keine übersichtlichen
Entwicklungsziele gibt. Durch das Fehlen eines Handbuches oder einer Dokumentation bleibt
dem Nutzer oft nur die umständliche Suche in Foren usw. für den Support, wodurch auch die
Kosten für Wartung und Pflege nicht zu unterschätzen sind.
Quellen: Kapitel 4.1 Open Source Definition
[MITCHELL], [DAALK], [DAImmo], [OSD], [GNU], [ETeaching], [OSI], [OpenSource],
[ContentMan]
4.2 Einleitung Geo-Daten Server
Grundlage eines Web-Informationssystems für die Nutzung von OGC Standards sind u.a.
Geo-Daten-Server. Ein Geo-Daten-Server bearbeitet Anfragen nach georeferenzierten
Informationen und generiert daraus die entsprechenden Ergebnisse in z.B. Kartenbildern usw..
Auf dem Markt gibt es zurzeit drei geläufige Server. Deegree, Geoserver und UMN
Mapserver. Jeder der hier vorgestellten Server berücksichtigt die minimalen Anforderungen
für das umzusetzende Auskunftssystem, wie z.B. die Einhaltung von bestimmten OGC
konformen Diensten. An dieser Stelle sollen die entsprechenden Geo-Daten-Server kurz
erläutert und näher beschrieben werden. Dabei soll auf Details über die Software-Architektur
usw., verzichtet werden. Vielmehr soll die prinzipielle Funktionsweise skizziert werden und
untersucht werden, inwiefern sich die Software zur Umsetzung der benötigten Funktionen
eignet.
4.2.1 Überblick über Deegree
Das deegree-Projekt ermöglicht flexible Lösungen für die Handhabung räumlicher Daten.
Durch eine verteilte, service-basierte Software Infrastruktur wird erreicht, dass die Daten von
unterschiedlichen, unabhängigen Applikationen erreichbar sind. Die Software besteht aus
mehreren Java Packages, Classes und Interfaces. Durch die Nutzung von Java wird auch eine
Plattform Unabhängigkeit erreicht. Die Architektur ist Komponenten-basiert, d.h. sie besteht
aus mehreren unabhängigen Modulen. Dadurch wird gewährleistet, dass das System leicht um
weitere Module erweiterbar ist, ohne dass dafür die Grundkonfiguration geändert werden
müsste. Dadurch ist es z.B. auch möglich, Daten von unterschiedlichen Servern zu laden. Es
werden die OGC-Spezifikationen Web Map Service (WMS), Web Feature Service (WFS),
Web Coverage Service (WCS), Web Terrain Service (WTS), Web Coordinate Transformation
Service (WCTS), sowie XML und XSLT unterstützt. Diese Vielfalt an Spezifikationen wird
bisher von den anderen Mapservern nicht unterstützt, ist aber bei den meisten in
Vorbereitung. Konfiguriert wird der deegree-Server durch eine zentrale servlet-Datei, den so
genannten dispatcher. In dieser Datei werden alle nötigen Einstellungen zur Konfiguration
4 -
Marktanalyse: Open Source Software
22
vorgenommen. Zur Verbreitung der Ergebnisse im Netz wird deswegen ein Web-Server
benötigt, der solche Java-Servlets oder Server-Pages behandeln kann. Es kommt meist der
Apache Tomcat Server zum Einsatz, welcher mit diesen Dateien umgehen kann. Die Version
deegree2 stellt so genannte war-Dateien zur Installation zur Verfügung. Diese Dateien können
vom Tomcat Server gelesen werden. In der Administrationsoberfläche, dem Tomcat Manager,
lässt sich für jeden gewünschten Service (WMS, WFS, WCS,...) eine entsprechende Datei
auswählen und laden. Die Installation des Dienstes und das Einbinden und Bereitstellen im
Tomcat erfolgt danach automatisch. Die Darstellung von Geo-Daten im Browser wird durch
einen Client ermöglicht. Im deegree-Projekt lässt sich der Client iGeoportal, analog zu den
unterschiedlichen Diensten, mit Hilfe einer war-Datei hinzuladen. Dieser Client übernimmt
dann die Visualisierung und stellt auch schon geometrische Grundfunktionen, wie Zoom oder
Pan, zur Verfügung. Außer iGeoportal kann auch jeder andere Client verwendet werden. Das
Einbinden eigener Daten oder das Nutzen anderer Clients erfordert eine Anpassung von
mehreren Konfigurationsdateien und ist deshalb ein wenig mühsam und umständlich.
4.2.2 Überblick über den Geoserver
Der Geoserver ist ein Server, welcher das Anzeigen und Editieren von geographischen Daten
mit Hilfe von vordefinierten Standards realisiert. Zurzeit werden die OGC-Spezifikationen
eines WMS und eines WFS-T voll unterstützt. Die Einbindung von WCS ist in Vorbereitung
bzw. in der Umsetzung und wird in der nächsten Version zum festen Bestandteil gehören.
Abb. 13: Geoserver Daten Konfigurations-Fenster
Auch die Nutzung von Styled Layer Descriptor (SLD), zur Visualisierung und zur
Speicherung von Style-Informationen, wird unterstützt. Das System basiert auf Java
GeoTools und ist somit auch vollständig in Java implementiert und dadurch anpassungsfähig.
Es ist, ebenso wie deegree, servlet-basiert und benötigt einen entsprechenden Web-Browser.
Anders als die anderen Server Lösungen bietet der Geoserver einen Windows-Installer an.
Dieser Installer installiert das komplette Software-System am gewünschten Ort mit allen
notwendigen Einstellungen und Zusätzen wie z.B. dem Web-Server. Es müssen keine
komplizierten Konfigurationsdateien ,,von Hand" angepasst und modifiziert werden. Nach der
Installation gibt es die Möglichkeit, die Konfiguration des Servers mit Hilfe eines
komfortablen webbasierten Konfigurations-Tools an die eigene Struktur anzupassen (siehe
Abb. 13: Geoserver Daten Konfigurations-Fenster). Auch eigene Dateien lassen sich
innerhalb einer Web-Oberfläche in den Server bequem einpflegen und in einem integrierten
MapBuilder Client als Vorschau anzeigen (siehe Abb. 14: Luftbild in der Geoserver Vorschau
(MapBuilder)). Ein Client zur Darstellung und Abfrage der Daten, wie z.B. MapBuilder ist
auch für den Geoserver notwendig.
4 -
Marktanalyse: Open Source Software
23
Abb. 14: Luftbild in der Geoserver Vorschau (MapBuilder)
4.2.3 Überblick über den UMN Mapserver (MS4W)
Der UMN Mapserver ermöglicht die Verbreitung und Darstellung von dynamischen
Karteninhalten über das Internet bzw. Intranet. Die Plattform Unabhängigkeit, sowie die
Integration von weiteren Open Source Modulen, wie z.B. die Shapelib-Bibliothek zur
Verwaltung und Bearbeitung von ESRI shp-Dateien oder die Geospatial Data Abstraction
Library (GDAL), eine Übersetzungsbibliothek für Rasterformate, weisen auf eine hohe
Interoperabilität hin. Die große, weltweite Anwendergemeinschaft, mit einer breiten
Beteiligung an der Entwicklung und vielfältige Einsatzgebiete, haben ein stabiles System mit
hoher Geschwindigkeit und Performance zur Konsequenz. Daraus folgt auch eine gute,
vielfältige Dokumentation oft auch schon in deutscher Sprache.
Der UMN Mapserver unterstützt die OGC-Spezifikationen eines WMS und eines WFS. Die
Entwicklung eines WMC und WCS Dienstes ist bereits in der Vorbereitung und Umsetzung
und wird voraussichtlich in die nächste Version integriert werden (Stand: Version 4.10). Auch
die Unterstützung von SLD ist vorhanden. Der UMN Mapserver arbeitet als CGI-Anwendung
(Common Gateway Interface) und ist somit in einen Webserver mit den notwendigen
Fähigkeiten, beispielsweise dem Apache Webserver, integriert. Der Mapserver ist kein
vollständiges GIS, sondern nur die Basiskomponente für die Erzeugung von dynamischen
Karten, zur Visualisierung und grundlegenden Analyse von Geo-Daten. Um komplexe
vielfältige Anwendungen zu schaffen, ermöglicht der Mapserver einen scriptbasierten Zugriff
durch die Programmierschnittstelle Mapscript. Mapscript erlaubt den Zugriff über PHP, Perl,
Python oder auch Java (siehe Kapitel 0 Fachbegriffe zum Thema).
Die einfachste Mapserver-Applikation besteht aus fünf Komponenten. Einer map-Datei, den
Geo-Daten, HTML-Seiten, dem Mapserver-CGI, sowie einem HTTP-Server.
4 -
Marktanalyse: Open Source Software
24
Abb. 15: UMN Mapserver - Startbildschirm
Die map-Datei ist die Grundlage einer Mapserver-Applikation. In der map-Datei werden die
Konfigurationseinstellungen gemacht und es sind alle Informationen ersichtlich, welche zur
Erstellung oder Abfrage einer Kartendarstellung notwendig sind. Das beinhaltet z.B. Angaben
über die Farbe, die Ausdehnung, die Layer oder die Symbolik einer Karte. Zur eigentlichen
Visualisierung der Daten bedient sich der Mapserver so genannter Templates. Dies sind im
einfachsten Fall einfache HTML-Seiten. Diese HTML-Seiten fungieren dann als Client und
stellen oft auch schon Abfrage Möglichkeiten und Zoom oder Pan zur Verfügung. Die
eigentliche Ausführung des Mapservers erfolgt durch die Mapserver-CGI, welche dem
Webserver in dessen cgi-Verzeichnis zugänglich sein muss (siehe Abb. 15: UMN Mapserver -
Startbildschirm). Ein HTTP fähiger Webserver ist für das Ausliefern der Anfragen an den
Mapserver, sowie die Rückgabe des Ergebnisses an das Template zuständig.
4.2.4 Bewertung und Entscheidung für einen Geo-Daten Server
Jeder der hier vorgestellten Geo-Daten-Server bringt die notwendigen Voraussetzungen mit,
um die gestellten Anforderungen der Implementierung eines Auskunftssystems für
verschiedene Geo-Daten zu lösen. Jeder Geo-Daten-Server ermöglicht die flexible
Visualisierung von räumlichen Geo-Daten über einen Webbrowser mit Hilfe eines
entsprechenden Clients. Auch die Möglichkeit der Abfrage von bestimmten Objekten oder die
Suche nach einem Objektattribut kann realisiert werden. Die später noch näher erläuterten
Clients (siehe Kapitel 4.3 Einleitung Web-GIS-Clients) können mit allen Servern
zusammenarbeiten.
Das Deegree-Projekt bietet zurzeit die breiteste Unterstützung an OGC-Spezifikationen.
Neben den WMS und WFS wird z.B. auch XML und XSLT bereits integriert. Für die Zwecke
des geforderten Auskunftssystems sind zu diesem Zeitpunkt viele OGC-Spezifikationen nicht
notwendig. Ein transactional WFS wird z.B. nicht benötigt, da keinerlei Digitalisierungen
oder Ähnliches gemacht werden sollen. Da die Entwicklung der Server laufend weiter
4 -
Marktanalyse: Open Source Software
25
schreitet, wird die Einbindung weiterer OGC-Spezifikationen in den Geoserver und den UMN
Mapserver in naher Zukunft folgen, sodass dieser Punkt nicht unbedingt ausschlaggebend für
eine Entscheidung, auch im Hinblick auf die Zukunft, ist.
Die Installation von deegree setzt einen lauffähigen Webserver, welcher Java Server Pages
und Servlets unterstützt, voraus. Die Software Bausteine können dann entweder ,,von Hand"
durch Anpassen der entsprechenden Konfigurationsdateien in den Server eingebunden oder
durch war-Dateien automatisiert installiert werden. Der Geoserver benötigt keine Software-
Voraussetzungen. Der mitgelieferte Windows-Installer installiert einen sofort lauffähigen
Server ohne Anpassungen machen zu müssen. Für spätere Anpassungen und
Administrationen stellt Geoserver eine Web-Oberfläche zur Verwaltung (siehe Abb. 13:
Geoserver Daten Konfigurations-Fenster). Der UMN Mapserver benötigt einen Apache
HTTP-Server oder ähnlichen CGI und HTTP-fähigen Webserver als Voraussetzung. Die
UMN Mapserver Systemdateien müssen dann in das Web-Verzeichnis des Servers entpackt
werden. Durch Anpassen einiger System-Dateien, wird dem Apache-Server der Mapserver
bekannt gegeben. Bei der Installation hat somit der Geoserver für Laien leichte Vorteile. Das
Mapserver 4 Windows Projekt (MS4W) bietet aber eine komfortable Lösung für den UMN
Mapserver. Das Paket bietet eine komplett vorkonfigurierte Version des UMN Mapservers,
inklusive Webserver, welches dann nur auf ein Laufwerk entpackt werden muss. Das
Ausführen einer mitgelieferten batch-Datei macht das System lauffähig und somit die
Installation auch für Anfänger geeignet (siehe Abb. 15: UMN Mapserver - Startbildschirm).
Das Integrieren eines geeigneten Clients in den Geo-Daten-Server ist für das Auskunftssystem
unerlässlich. Deegree erlaubt das Einbinden des Clients iGeoportal über eine war-Datei,
analog zu den entsprechenden Diensten. Andere Clients müssen angepasst und manuell
integriert werden. Der Geoserver bietet hier die mühsamste und unübersichtlichste Lösung.
Zwar können eigene Daten bequem über die Administrationsoberfläche hinzugefügt werden,
das Nutzen eines Clients muss aber durch Konfigurationsdateien ,,von Hand" gemacht
werden. Viele der vorgefertigten Client-Lösungen basieren auf dem UMN Mapserver, sodass
diese leicht, durch wenige Einstellungen, integriert werden können. Einige sind auch auf
MS4W abgestimmt. Die entsprechenden System-Dateien müssen nur in das MS4W
Verzeichnis entpackt werden und sind sofort, ohne Anpassungen lauffähig.
Open Source Software liefert meist keine Handbücher oder Dokumentationen, sodass ein
Support meist dem Nutzer selbst überlassen bleibt, bzw. nicht vorhanden ist. Deegree und
Geoserver sind relativ junge Projekte und die Anwendergemeinschaft ist noch nicht sehr
verbreitet. Literatur ist nur sehr spärlich und Hilfe bekommt man, meist in Englischer
Sprache, nur über die Suche in Nutzerforen oder Communitys. Der UMN Mapserver hat die
größte Anwendergemeinschaft, wodurch der Support und die Hilfestellung, auch in deutscher
Sprache, besser sind. Für den UMN Mapserver existieren bereits zwei deutschsprachige
Internetpräsenzen mit Tutorials, Mailinglisten und umfangreichen Foren. Die Folge einer
breiten Gemeinschaft ist auch ein relativ ausgereiftes, stabiles System. Viele Funktionen sind
bereits an anderer Stelle realisiert worden, sodass Erweiterungen, mit relativ wenig Aufwand,
kostengünstig umgesetzt werden können. Durch die genannten Vorteile würden dann auch die
Kosten für Wartung und Pflege des Systems sinken.
Die, auch für Anfänger, leichte Installation eines lauffähigen Systems, bestehend aus einem
Apache-Server, einem UMN Mapserver und eines entsprechenden Clients, sowie die sehr
weit verbreitete Anwendergemeinschaft und die daraus resultierenden beschriebenen Vorteile
sind ausschlaggebend für die Nutzung des UMN Mapservers (MS4W) für dieses Projekt.
Quellen: Kapitel 4.2 Einleitung Geo-Daten Server
[WEB.MAP], [FISCHER], [MITCHELL], [UMN], [UMNDeutsch], [UMNCom],
[Geoserver], [deegree], [OGC], [WMS/WFS], [DASLD]
4 -
Marktanalyse: Open Source Software
26
4.3 Einleitung Web-GIS-Clients
Wie bereits erläutert, dienen die entsprechenden Geo-Daten-Server dazu, die gestellten
Anfragen in z.B. Kartenbilder usw. umzusetzen. Diese Ergebnisse werden dann über den
Web-Server ausgeliefert. Um Anfragen stellen zu können und die Ergebnisse zu visualisieren,
wird noch eine weitere Software-Komponente benötigt. Ein Web-GIS-Client. Dieser bietet in
der einfachsten Form eine Oberfläche, um Anfrageergebnisse als Kartenbild darzustellen.
Komplexere Clients bieten auch schon Möglichkeiten der Interaktion, wie z.B. Zoom- oder
Pan-Funktionen. Die höchste Stufe der Clients kann dann mit den Kartendaten komplett
interagieren und diese verwalten, steuern und nutzen. Dazu gehören z.B. Digitalisier-
Möglichkeiten oder Sachdatenabfragen. Im Rahmen dieser Diplomarbeit wurden einige dieser
Clients untersucht und ihre Fähigkeiten analysiert. Jeder dieser Clients kann für jeden der
bereits vorgestellten Geo-Daten-Server konfiguriert werden, sodass hierbei keine
Unterscheidung erfolgen musste. Die Clients sind nicht abhängig von einem bestimmten
Server. Sie können mit jedem hier vorgestellten Geo-Daten-Server in vollem
Funktionsumfang genutzt werden, sodass eine Entscheidung für einen Client unabhängig vom
Geo-Daten-Server getroffen werden konnte.
4.3.1 Überblick über Flexible Internet Spatial Template (Fist)
Die flexible Internet Spatial Template Software (Fist) kann mit jedem beliebigen Mapserver
arbeiten. Zurzeit ist der UMN Mapserver vorkonfiguriert. Es gibt ein Installationspaket für
den Mapserver 4 Windows, sodass die Software ohne große Anpassungen genutzt werden
kann.
Die Software liefert eine Web-Oberfläche zur Konfiguration und Administration der
einzelnen Komponenten, ähnlich dem Mapbender Projekt (siehe Kapitel 4.3.5 Überblick
über Mapbender). Fist arbeitet mit fünf config-Dateien im XML-Format, welche die
unterschiedlichen Bereiche initialisieren.
· map-service-config.xml
· user-config.xml
· session-config.xml
· layer-config.xml
· site-config.xml
Die map-config-Datei erlaubt Einstellungen zu den erreichbaren Mapservices, zu den
Fähigkeiten der Dienste und die notwendigen URLs, usw.. Die Nutzerverwaltung ist in der
user-config geregelt. Es sind Passwörter, Nutzergruppen und deren Zuordnung zu den
einzelnen Mapservices definiert. Die session-config-Datei speichert die Grundlagen für
einzelne Sitzungen eines Users. Die Session-Datei kann dann später von jedem Nutzer wieder
geladen werden. Die user-config-Datei kann als einzige Datei nicht von der Web-Oberfläche
aus bearbeitet werden, weil nach jedem Speichern eine eigene neue Datei angelegt wird.