Marktanalyse, Konzeption und Umsetzung eines Intranet-Auskunftsystems für die kommunale Verwaltung

Rahn, Hanno

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

von Hanno Rahn (Autor:in)

Informatik - Angewandte Informatik

Zusammenfassung

Inhaltsangabe:Einleitung:
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 […]

Leseprobe

Inhaltsverzeichnis

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.

http://www.diplomica.de, Hamburg 2008

Printed in Germany

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

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

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

Performance-Überlegungen für bessere Zugriffszeiten ... 85

Bewertung, Schlußfolgerung und Ausblick... 88

Anhang ...89

A. Installationen ...89

Kurzanleitung (Windows Installer) ...89

b. Installation

PostgreSQL...89

c. Installation

Mapserver

Windows...93

d. Installation

Mapbender...96

B. Pflichtenheft ...105

C. Tabellen OGC Spezifikationen...106

Web Map Service ...106

Web Feature Service...108

Web Coverage Service ...109

Simple Feature Model ...110

e. Sonstige

Spezifikationen ...111

D. Tabelle Zeichenvorschrift...112

E. map-Datei

Beispiele ...115

a. map-Datei

Header...115

jpg-Datei Einbinden eines Raster Layers ...116

shp-Datei Einbinden eines Polygon Layers...116

shp-Datei Einbinden eines Linien Layers...117

shp-Datei Einbinden eines Punkt Layers...118

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

Inneres AI

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

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

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

Geometrie B

3 -

OGC Spezifikationen

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

Geometrie A Geometrie B

Marktanalyse: Open Source Software

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]

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

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

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

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

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

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

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

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.

Details

Seiten
Erscheinungsform: Originalausgabe
Jahr: 2007
ISBN (eBook): 9783836608534
DOI: 10.3239/9783836608534
Dateigröße: 7.7 MB
Sprache: Deutsch
Institution / Hochschule: Fachhochschule Oldenburg/Ostfriesland/Wilhelmshaven; Standort Oldenburg – Bauwesen und Geoinformation
Erscheinungsdatum: 2008 (Januar)
Note: 1,7
Schlagworte: mapserver mapbender ogc-spezifikationen open source software intranet

Autor

Hanno Rahn (Autor:in)