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
- Art: Diplomarbeit
- Autor: Hanno Rahn
- Abgabedatum: August 2007
- Umfang: 125 Seiten
- Dateigröße: 7,6 MB
- Note: 1,7
- Institution / Hochschule: Fachhochschule Oldenburg/Ostfriesland/Wilhelmshaven Deutschland
- Originaltitel: Marktanalyse, Konzeption und Umsetzung eines Intranet-Auskunftsystems für die kommunale Verwaltung auf der Basis von Open Source Software wie UMN Mapserver und Mapbender und unter Berücksichtigung von OGC-Spezifikationen
- Bibliografie: ca. 43
- ISBN (eBook): 978-3-8366-0853-4
- ISBN (CD) :978-3-8366-0853-4 CD
- Sprache: Deutsch
- Prämierung:
- Arbeit zitieren: Rahn, Hanno August 2007: Marktanalyse, Konzeption und Umsetzung eines Intranet-Auskunftsystems für die kommunale Verwaltung, Hamburg: Diplomica Verlag
- Schlagworte: UMN Mapserver, Mapbender, OGC-Spezifikationen, Open Source Software, Intranet
In den Warenkorb
48,00 €
Diplomarbeit von Hanno Rahn
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 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.
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."
Inhaltsverzeichnis:
| 1. | Einleitung zum Thema und Anforderungsprofil | 8 |
| 2. | Umzusetzender Musterdatenbestand (Ausgangsdaten) | 9 |
| 3. | OGC Spezifikationen | 11 |
| 3.1 | Einleitung Geo-Daten Dienste | 11 |
| 3.2 | Überblick über den Web Map Service (WMS) | 12 |
| 3.3 | Überblick über den Web Feature Service (WFS) | 14 |
| 3.4 | Überblick über den Web Coverage Service (WCS) | 15 |
| 3.5 | Überblick über den Coordinate Transformation Service (CTS) | 16 |
| 3.6 | Überblick über das Simple Feature Model (SFM) | 16 |
| 3.7 | Überblick über die Geography Markup Language (GML) | 20 |
| 4. | Marktanalyse: Open Source Software | 20 |
| 4.1 | Open Source Definition | 20 |
| 4.2 | Einleitung Geo-Daten Server | 22 |
| 4.2.1 | Überblick über Deegree | 22 |
| 4.2.2 | Überblick über den Geoserver | 23 |
| 4.2.3 | Überblick über den UMN Mapserver (MS4W) | 24 |
| 4.2.4 | Bewertung und Entscheidung für einen Geo-Daten Server | 25 |
| 4.3 | Einleitung Web-GIS-Clients | 27 |
| 4.3.1 | Überblick über Flexible Internet Spatial Template (Fist) | 27 |
| 4.3.2 | Überblick über MapLab | 29 |
| 4.3.3 | Überblick über Chameleon | 30 |
| 4.3.4 | Überblick über CartoWeb | 31 |
| 4.3.5 | Überblick über Mapbender | 32 |
| 4.3.6 | Bewertung und Entscheidung für einen Web-GIS-Client | 33 |
| 4.4 | Grundlagen über map-Dateien | 35 |
| 4.4.1 | Aufbau einer map-Datei | 35 |
| 4.4.1.1 | Das Map-Objekt (Header) | 35 |
| 4.4.1.2 | Symbole und ihre Definitionen in der map-Datei | 38 |
| 4.4.1.3 | Das Layer-Objekt | 40 |
| 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 | 45 |
| 4.4.2.2 | Überblick über Gix Export Tool für ArcView | 47 |
| 4.4.2.3 | Überblick über MapEdit | 49 |
| 4.4.2.4 | Überblick über Quantum GIS | 51 |
| 4.4.2.5 | Bewertung und Entscheidung für eine Software | 53 |
| 4.5 | Sonstige Software | 54 |
| 4.5.1 | Einleitung Konverter Software | 54 |
| 4.5.1.1 | Überblick über CAD2Shape 3.0 | 54 |
| 4.5.1.2 | Überblick über AutoCAD dxf to Shapefile Converter | 55 |
| 4.5.1.3 | Überblick über Dxf2PostGIS | 56 |
| 4.5.1.4 | Überblick über shp2pgsql | 56 |
| 4.5.2 | Überblick über PostgreSQL/PostGIS | 57 |
| 4.6 | Fachbegriffe zum Thema | 58 |
| 4.6.1 | Kurze Einführung in JavaScript | 58 |
| 4.6.2 | Kurze Einführung in PHP | 58 |
| 4.6.3 | Kurze Einführung in MapScript | 59 |
| 4.7 | Benutzte Softwarekomponenten / Software Architektur | 60 |
| 5. | ibt Geo-Viewer | 61 |
| 5.1 | Umsetzung des Musterdatenbestands (Besonderheiten und Schwierigkeiten) | 61 |
| 5.1.1 | Umsetzung des Themas: Luftbilder | 62 |
| 5.1.2 | Umsetzung des Themas: Übersicht | 62 |
| 5.1.3 | Umsetzung des Themas: Bebauungsplan-Übersicht | 62 |
| 5.1.4 | Umsetzung des Themas: Bebauungspläne | 63 |
| 5.1.5 | Umsetzung des Themas: ALK | 64 |
| 5.1.6 | Umsetzung des Themas: Wasser | 64 |
| 5.1.7 | Umsetzung des Themas: Kanal | 64 |
| 5.1.8 | Umsetzung der Beschriftungen in den einzelnen Themen | 65 |
| 5.1.9 | Alternative Umsetzungsmöglichkeiten am Beispiel der Beschriftungen | 67 |
| 5.2 | Einbinden einer map-Datei in Mapbender | 70 |
| 5.3 | Auskunftssystem Oberfläche und Elemente | 77 |
| 5.4 | Funktionen und Bedienung des Auskunftssystems | 80 |
| 5.4.1 | Erläuterung der geometrischen Grundfunktionen | 80 |
| 5.4.2 | Erläuterung der Abfragefunktionen | 81 |
| 5.4.3 | Erläuterung der Themensteuerungsmöglichkeiten | 83 |
| 5.4.4 | Erläuterung sonstiger Funktionen | 85 |
| 6. | Performance-Überlegungen für bessere Zugriffszeiten | 86 |
| 7. | Bewertung, Schlußfolgerung und Ausblick | 89 |
| Anhang | 90 |
Textprobe:
Kapitel 4.1.4, Verwendbare Datenformate im UMN Mapserver:
Ein wichtiger Aspekt des Auskunftssystems sollte es sein, die unterschiedlichsten Datenformate nutzen zu können und flexibel auf Änderungen im Datenmaterial zu reagieren. Da jeder Software Hersteller mit der Entwicklung seines Systems oft auch sein eigenes Datenformat einführt, gibt es auf dem Markt eine Vielzahl unterschiedlicher Datenformate. Die Daten welche genutzt werden sollen, können aus vielen verschiedenen Quellen bezogen werden und somit auch in vielen Formaten vorliegen. Die Schwierigkeit ist es, diese verschiedenen Datentypen im Mapserver zusammen zu bringen. Mapserver unterstützt bereits eine ganze Reihe von geläufigen Datenformaten aus dem GIS oder CAD Bereich. Zu diesem Zweck sollen an dieser Stelle einmal unterschiedliche Möglichkeiten der Einbindung bestimmter Geo-Daten erläutert werden.
Die Nutzung der verschiedenen Daten unterscheidet sich im Mapserver in drei Möglichkeiten. Zum einen unterstützt der Mapserver ein Standardformat jeweils für Vektordaten (siehe Abb. 25: Beispiel Mapserver interne Mechanismen - Einbindung einer jpg-Datei) und für Rasterdaten (siehe Abb. 26: Beispiel Mapserver interne Mechanismen - Einbindung einer Polygon shp-Datei). Shp-Dateien und georeferenzierte GeoTiffs können mit Mapserver internen Funktionen direkt in die map-Datei eingebunden werden. Zum anderen können Datenformate über eine externe Bibliothek, welche in den Mapserver integriert wird, verfügbar gemacht werden. Außerdem können Daten über eine Geo-Datenbank eingebunden werden.
Über die GDAL/OGR Bibliothek können weitere Raster- bzw. Vektorformate direkt gelesen werden. GDAL (Geospatial Data Abstraction Library) ist eine Übersetzungsbibliothek für Rasterformate in ein einheitliches Datenmodell, für alle unterstützten Formate, welches dann u.a. vom Mapserver gelesen und visualisiert werden kann. Auf diese Weise können z.B. auch das Graphics Interchange Format (gif), Portable Network Graphics (png) oder JPEG-Dateien (jpg) genutzt werden. Der Vorteil von GDAL ist es, dass sehr viele Datenformate unterstützt werden. Außerdem kann die Bibliothek aus anderen Applikationen (z.B. der UMN Mapserver) heraus angesprochen und voll genutzt werden. In dieser Applikation stehen dann ebenfalls alle Rasterformate ohne Einschränkung zur Verfügung. GDAL bietet viele vorgefertigte Tools, um mit den entsprechenden Rasterdateien zu arbeiten. „gdal_translate“ kann z.B. ein Rasterformat in ein anderes transformieren. Mit dem Tool „gdalinfo“ können Informationen über das Bild, wie z.B. die Projektion oder die Ausdehnung abgerufen werden. „gdaltindex“ erlaubt das Indizieren von Rasterbildern mit Hilfe einer shp-Datei (siehe Kapitel 6 – Performance-Überlegungen für bessere Zugriffszeiten).
Analog zu GDAL, gibt es eine Bibliothek für den Zugriff auf Vektorformate. Die OGR-Bibliothek ist Bestandteil von GDAL und erlaubt die Nutzung von vielen weiteren Vektorformaten, neben dem Mapserver Standard shp-Datei. Als Beispiel seien hier Microstation dgn-Dateien (siehe Abb. 27: Beispiel OGR-Bibliothek - Einbindung der Punkt-Daten einer dgn-Datei), TIGER/Line-Files oder GML-Dateien genannt.
OGR bietet ebenso wie GDAL einige Hilfswerkzeuge für die Analyse und Verwaltung von Vektordaten. Mit Hilfe von „ogrinfo“ können Sachdaten des Files, wie z.B. Geometrietyp oder die Ausdehnung, abgefragt werden. „ogr2ogr“ erlaubt, analog zu „gdal_translate“, die Umwandlung eines Vektordatentyps in ein anderes Vektordatenformat. Diese Hilfstools, sowohl von GDAL als auch von der OGR-Bibliothek arbeiten auf der Kommandozeile. Um GDAL/OGR Datenformate nutzen zu können, muss in der map-Datei eine Verbindung (CONNECTION) und ein Verbindungstyp (CONNECTIONTYPE) angegeben werden (siehe Abb. 27: Beispiel OGR-Bibliothek - Einbindung der Punkt-Daten einer dgn-Datei).
Das Hauptziel einer UMN Mapserver Anwendung ist es, OGC konforme Daten nutzen zu können. Das bezieht sich nicht nur auf die Bereitstellung solcher Geo-Daten über ein Netzwerk. Natürlich können auch externe Quellen als Datengrundlage genutzt werden. Externe Web Map Services oder Web Feature Services usw., können zum einen über die Oberfläche mit der entsprechenden Schaltfläche, z.B. über die Angabe einer URL, zur Laufzeit eingebunden werden (siehe Kapitel 5.4 – Funktionen und Bedienung des Auskunftssystems) oder dauerhaft über eine entsprechende map-Datei zugänglich sein. In der map-Datei muss dazu als CONNECTIONTYPE der entsprechende Service angegeben werden. In der CONNECTION wird die URL des Datenanbieters bekannt gemacht. Im Metadaten-Objekt können bestimmte Layer von der Quelle ausgewählt werden (siehe Abb. 28: Beispiel Einbinden des externen Layers TK100 vom LGN). Es muss nicht zwangsläufig jeder Layer des Service benutzt werden. Außerdem müssen in der map-Datei die Server-Version, sowie der Service und die Request-Methode bekannt sein.
Weiterhin können Geo-Daten in eine Datenbank geschrieben werden. UMN Mapserver unterstützt u.a. Oracle spatial oder PostgreSQL/PostGIS (siehe Abb. 29: Beispiel PostGIS Datenbank - Einbindung eines Polygon Layers). Mapserver kann dann auf diese Datenbank zugreifen und die entsprechenden Datensätze darstellen. Für die Verbindung zur Datenbank werden dabei die entsprechenden Datenbank-Parameter, wie z.B. Host, User, Passwort oder Datenbankname, in der map-Datei angegeben. Über SQL-Statements wird die Geometriespalte der Datenbanktabelle bekannt gemacht, sodass der Mapserver weiß, welche Daten zu visualisieren sind. Auf diese Weise können auch eingeschränkte Suchabfragen gestellt werden, um z.B. nur bestimmte Datensätze einer Tabelle auszuwählen.
Über eine PostGIS Datenbank können auch viele Datenformate genutzt werden, welche von der OGR-Bibliothek nicht unterstützt werden. An dieser Stelle sollen nur AutoCAD dxf-Dateien, welche über eine entsprechende Software in die Datenbank geschrieben werden können, als Beispiel erwähnt werden.
Über die hier beschriebenen Methoden sollte es möglich sein, viele gängige Datenformate für den Mapserver zugänglich zu machen. Sollte ein Datentyp trotzdem nicht unterstützt werden, so gibt es außerdem die Möglichkeit der Transformation in ein unterstütztes Format. Es gibt Konverter Tools für sehr viele Datenformate, auch in unterschiedliche Richtungen. Das Kapitel 4.5.1 – Einleitung Konverter Software beschreibt eine kleine Auswahl solcher Werkzeuge. Hierbei ist zu beachten, dass bei der Transformation eines Datenformats in ein anderes Datenformat oft Informationen verloren gehen können und eine Konvertierung somit nicht immer die beste Lösung ist. Microstation dgn-Files beinhalten z.B. manchmal eigene Style-Angaben, diese können aber von vielen Konverter Lösungen nicht umgesetzt werden und gehen verloren. Es sollte also immer klar sein, welche Informationen benötigt werden, und auf welche gegebenenfalls verzichtet werden könnte.
Im Rahmen der Umsetzung des Auskunftssystems, sollte auch immer die Performance berücksichtigt werden. Der UMN Mapserver wurde ursprünglich auf der Basis von ESRI shp-Dateien bzw. GeoTIFFS konzipiert. Diese Datenformate können durch Mapserver interne Mechanismen genutzt werden. Bei anderen Formaten muss zunächst die entsprechende externe Bibliothek bzw. Datenbankverbindung geöffnet werden. Ein Geschwindigkeitsunterschied ist bei der Größenordnung des Auskunftssystems noch nicht signifikant, könnte aber bei größeren Projekten durchaus ins Gewicht fallen. Für genauere Aussagen sind aber weitere Untersuchungen notwendig, auf die im Rahmen dieser Diplomarbeit nicht näher eingegangen werden kann.
In den Warenkorb
48,00 €
Link zur Arbeit:
http://www.diplom.de/ean/9783836608534
Arbeit zitieren:
Rahn, Hanno August 2007: Marktanalyse, Konzeption und Umsetzung eines Intranet-Auskunftsystems für die kommunale Verwaltung, Hamburg: Diplomica Verlag
Schlagworte:
UMN Mapserver, Mapbender, OGC-Spezifikationen, Open Source Software, Intranet



