Konzept zum Aufbau einer Geodateninfrastruktur bei der Polizei Rheinland-Pfalz

Inhaltsverzeichnis

Eidesstattliche Erklärung

Abstract

Abbildungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Ziele der Diplomarbeit
1.3 Abgrenzung
1.4 Aufbau und Gliederung
1.5 Anmerkungen

2 technische Grundlagen
2.1 Geoinformationssysteme
2.2 Geodaten
2.2.1 Geobasisdaten
2.2.2 Geofachdaten
2.2.3 Metadaten
2.2.4 Geoobjekte
2.2.5 Geometriedaten
2.2.6 Räumliche Bezugssysteme
2.2.7 Modellierung von Geodaten
2.3 GIS-Architekturen
2.3.1 Desktop-GIS
2.3.2 Client / Server-GIS
2.3.3 Web-GIS
2.3.4 mobiles GIS
2.4 Geodateninfrastrukturen
2.4.1 INSPIRE - Eine GDI für Europa
2.4.2 GDI-DE - Eine nationale Geodateninfrastruktur für Deutschland
2.4.3 GDI-RP – Aufbau einer GDI in Rheinland-Pfalz
2.4.4 Verhältnis GIS - GDI

3 Standards, Interoperabilität und OpenSource
3.1 standardisierende Gremien
3.1.1 ISO
3.1.2 OGC
3.1.3 AdV
3.1.4 SAGA
3.2 Interoperabilität durch Standards und Spezifikationen
3.2.1 Allgemeine IT-Standards
3.2.2 OGC Web Services
3.2.3 Semantische Interoperabilität
3.2.4 standardisierte Geobasisdaten
3.3 OpenSource
3.3.1 OpenSource GIS Software
3.3.2 UMN MapServer

4 Geodaten bei der Polizei Rheinland-Pfalz
4.1 Polizei Rheinland-Pfalz
4.1.1 Infrastruktur
4.1.2 Anwendungen
4.1.3 Aufgaben der Polizei Rheinland-Pfalz
4.2 Lösungen für raumbezogene Sachbearbeitung
4.2.1 Raumbezug mit Topic Maps
4.2.2 Landesraumdaten aus POLADIS.net
4.3 Geodateninfrastruktur der Polizei Rheinland-Pfalz
4.3.1 Status quo
4.3.2 Geoinformationssystem der Polizei Rheinland-Pfalz
4.3.3 GDI-PolRP
4.3.4 Handlungsempfehlungen
4.3.5 Rahmenbedingungen
4.4 Realisierung

5 Implementierung
5.1 Entwicklungsumgebung
5.1.1 ms4w – MapServer4Windows
5.1.2 PostgreSQL / PostGIS
5.2 Konvertierung und Aufbereitung der Geodaten
5.2.1 EDBS2PostGIS
5.2.2 Aufbereitung und Import der amtlichen Hauskoordinaten
5.2.3 Dekodierung der DOP
5.2.4 Import der Fachdaten nach PostGIS
5.2.5 Zahlen der Konvertierung und Aufbereitung
5.3 Realisierung der technischen Prototypen
5.3.1 Gemeinsame Eigenschaften der technischen Prototypen
5.3.2 PolGIS
5.3.3 PolGIS-E
5.3.4 PolGIS-K
5.3.5 PolGIS-OGC
5.4 Bewertungen
5.4.1 Bewertung der Entwicklungsumgebung
5.4.2 Bewertung der Geodaten
5.4.3 Bewertung der Prototypen

6 Zusammenfassung und Ausblick
6.1 Zusammenfassung
6.2 Ausblick

A ms4w und PostgreSQL/PostGIS
A.1 ms4w
A.1.1 Installation
A.1.1 Chameleon
A.1.2 MapLab
A.2 PostgreSQL / PostGIS
A.2.1 Anlegen der Datenbank polgis_db
A.2.2 Anlegen und Löschen einer Feature Tabelle
A.2.3 Räumliche PostGIS Funktionen

B Readme
B.1 Installation
B.2 Start
B.2.1 Webserver
B.2.2 Datenbank
B.2.3 PolGIS, PolGIS-E, PolGIS-K und PolGIS-OGC
B.3 Anmerkungen

Literaturverzeichnis

Literaturquellen

Internetquellen

Abkürzungen

Abbildungsverzeichnis

Abbildung 1: Vierkomponenten-Modelle EVAP und HSDA eines GIS

Abbildung 2: Geodaten [ikg]

Abbildung 3: Projektionsarten

Abbildung 4: beteiligte Komponenten und Aufbau des Web-GIS

Abbildung 5: Elemente der GDI-DE

Abbildung 6: Übersicht der im Bereich GIS beteiligten Gremien

Abbildung 7: Technology Development Process und die Arbeit des TOCG

Abbildung 8: Viewpoints des SAGA Architekturmodells

Abbildung 9: Lebenszyklus von SAGA Standards

Abbildung 10: Interoperabilität: Schichten und Standards

Abbildung 11: TCP/IP- versus OSI-Referenzmodell [wiki-de]

Abbildung 12: Architektur einzelner OGC Web Services

Abbildung 13: Aufbau einer Topic Map mit Verknüpfung zur Informationsebene

Abbildung 14: Published Subjects für Menschen und Computer

Abbildung 15: Bestandteile des ISO Standards 13250 Topic Maps

Abbildung 16: hierarchischer Aufbau des ATKIS-Objektartenkatalog

Abbildung 17: AAA-Referenzmodell

Abbildung 18: Zusammenspiel von OpenSource GIS Software

Abbildung 19: Interaktion der in deegree implementierten OWS

Abbildung 20: mapserv_42.exe -v

Abbildung 21: Aufbau eines mapfiles

Abbildung 22: zulässige Projektionsformate im mapfile

Abbildung 23: verwendetes RGB-Farbmodell des UMN MapServers

Abbildung 24: Unterschied zwischen Bitmap- und HTML-Legende

Abbildung 25: Konstruktion von kartographischen Signaturen

Abbildung 26: Intranet / Internet / Extranet

Abbildung 27: Softwarearchitektur RIVAR

Abbildung 28: RIVAR – Portal für zentrale Verfahren

Abbildung 29: Ereigniswürfel

Abbildung 30: Merging von Topic Maps

Abbildung 31: Datenbank Schema für Topic Maps

Abbildung 32: Sequenzdiagramm für verteilten Zugriff auf DOP

Abbildung 33: Grundsätzlicher Aufbau der technischen Prototypen

Abbildung 34: Arbeitsabläufe bei Installation und Aufbereitung Geodaten

Abbildung 35: ATKIS Daten konvertieren in shapefile mit AvAtkis Professional

Abbildung 36: Datei shp2sql.bat

Abbildung 37: VACUUM ANALYSE für die Feature Tabelle hn_mainz

Abbildung 38: Anzeige der Bildkataloge für die DVD 10 – 12 mittels qGIS

Abbildung 39: PolGIS – mittels polgis.html definierter Startbildschirm

Abbildung 40: Schematische Darstellung des GUI

Abbildung 41: Layer Verkehrswege

Abbildung 42: Layer Strassennamen

Abbildung 43: Straßenname ohne und mit collect

Abbildung 44: Zuschalten mehrerer Gruppen – Siedlung und Vegetation, Luftbilder, Verkehr, Beschriftung

Abbildung 45: PolGIS – Navigation – Zoom anhand von Luftbildern

Abbildung 46: PolGIS – Navigation – Anzeige / Suche

Abbildung 47: Textsuche in polgis.html und resultierender URL

Abbildung 48: legend.html

Abbildung 49: PolGIS – Abfrageergebnis zum Haus

Abbildung 50: PolGIS –Geobasisdaten ohne, mit überlagerten und ausschließlich Luftbilder

Abbildung 51. PolGIS-E – Abfrageergebnis / Alarmierungsplan zu Haltestelle

Abbildung 52: Layer GeoPolis

Abbildung 53: PolGIS-K – geopolis.html und resultierende Seite

Abbildung 54: Nutzung von Geodaten über WMS

Abbildung 55: WMS - notwendige Angaben in polgis.map und polgis_ogc.map

Abbildung 56: PolGIS-OGC – Kartenausschnitt nach WMS Request GetMap

Abbildung 57: Auf polgis.map basiertes mit GMapFactory erstelltes Applet

Abbildung 58: Anzeige der Funktionen in pgAdminIII

Abbildung 59: Abfrageergebnis mit length

Abbildung 60: Abfrageergebnis mit distance

Abbildung 61: Abfrageergebnis mit perimeter

Abbildung 62: Abfrageergebnis mit touches

Eidesstattliche Erklärung

Hiermit versichere ich, dass ich die vorliegende Diplomarbeit ohne Hilfe Dritter und nur mit den angegebenen Quellen und Hilfsmitteln angefertigt habe. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.

Darmstadt, 31. Mai 2005

Abstract

Die vorliegende Diplomarbeit hat das Konzept zum Aufbau einer Geodateninfrastruktur für die Polizei Rheinland-Pfalz zum Thema. Einzelne Ausbaustufen werden diskutiert, Handlungsempfehlungen gegeben und Rahmenbedingungen formuliert.

Daneben werden Lösungsansätze für die raumbezogene polizeiliche Sachbearbeitung entwickelt. Durch die bestimmte Verwendung von raumbezogenen Daten in Topic Maps lassen sich neue Anwendungsgebiete der polizeilichen Sachbearbeitung erschließen.

Weiterhin wird die Tauglichkeit des UMN MapServers als Kernkomponente in einem Web-GIS anhand von vier technischen Prototypen nachgewiesen. Diese Prototypen decken einen großen Teil von polizeilichen Aufgabenfeldern ab und zeigen gleichzeitig den breiten Funktionsumfang des UMN MapServers auf.

Zur Hinführung auf die einzelnen Hauptthemen werden technische Grundlagen vermittelt und die Notwendigkeit für die Verwendung von Standards und Spezifikationen beim Einsatz von Geoinformationen aufgezeigt sowie ein Abriss über OpenSource Software gegeben.

1 Einleitung

Zur Erfüllung ihrer Aufgaben erhebt, verarbeitet und speichert die Polizei Rheinland-Pfalz eine Vielzahl von Daten. Diese enthalten neben den Angaben zu Delikten, Personen und Zeit auch Informationen mit Raumbezug. Zusätzlich zur textuellen Nutzung bei der Auswertung und Analyse besteht der Bedarf nach der Visualisierung dieser Daten. Die bestehenden Anwendungen bei der Polizei Rheinland-Pfalz unterstützen diese Anforderung nur unzureichend.

Geodateninfrastrukturen werden auf verschiedenen internationalen und nationalen Ebenen von der öffentlichen Verwaltung als wichtiger Bestandteil des eGovernments konzipiert. Mittels internetbasierter Dienste können in Geodateninfrastrukturen unterschiedliche Informationen mit räumlichem Bezug über System- und Programmgrenzen hinweg Anwendern zeitnah präsentiert werden. Die hierzu notwendige Interoperabilität für den vernetzten Zugang zu verteilten Geodaten wird durch den konsequenten Einsatz von Standards und Spezifikationen erreicht. Das Open Geospatial Consortium entwickelt offene und erweiterbare Schnittstellen für Geoinformationssysteme in Form von Spezifikationen.

Viele dieser Spezifikationen wurden mit OpenSource Software realisiert. Als eine der bedeutendsten Anwendungen ist der UMN MapServer zu nennen. Als Basiskomponente zur Kartenerzeugung in einem internetbasierten Geoinformationssystem nimmt er eine zentrale Rolle ein. Ebenfalls ist sein Einsatz in einer Geodateninfrastruktur auf Grund der nach­gewiesenen Konformität zu den Spezifikationen des Open Geospatial Consortiums möglich.

Diese Diplomarbeit soll einen Beitrag zum Aufbau einer Geodateninfrastruktur bei der Polizei Rheinland-Pfalz leisten. In den nachfolgenden Unterkapiteln werden die bestehende Problem­stellung erläutert und die daraus resultierenden Ziele abgeleitet.

Die Beschreibung des Aufbaus und der Gliederung der Diplomarbeit sowie allgemeine An­merkungen schließen das Kapitel ab.

1.1 Problemstellung

Innerhalb der Polizei Rheinland-Pfalz existiert kein umfassender Überblick über Geodaten, Geoinformationssysteme oder Geodaten­infrastrukturen. Es sind weder die begleitenden Aspekte wie Standards, Spezifikationen und Interoperabilität in Bezug auf Geoinformationen in den Fokus der politischen Entscheidungsträger gerückt, noch ist die Interdependenz der geographisch unterstützten polizeilichen Sachbearbeitung mit den regionalen Anstrengungen zum Aufbau einer Geo­dateninfrastruktur Rheinland-Pfalz erkannt worden. Weiterhin sind innerhalb der Polizei Rheinland-Pfalz kaum Erfahrungen mit der Verwendung von OpenSource Software für den Einsatz in zentralen Verfahren vorhanden. Auch fehlt die übergreifende Koordinierung und Sammlung der unterschiedlichen fachlichen An­forderungen aus den einzelnen polizeilichen Aufgabenfeldern, die zur vollständigen Beschreibung der geo­graphischen Datenverarbeitung bei der Polizei Rheinland-Pfalz notwendig ist.

Wegen der Durchführung höherrangiger Projekte und der damit einher gehenden personellen sowie finanziellen Knappheit konnte das Thema Geodateninfrastruktur bisher nicht vollumfänglich durch die Polizei Rheinland-Pfalz behandelt werden.

1.2 Ziele der Diplomarbeit

Die im vorherigen Unterkapitel identifizierte Problemstellung liefert gleichzeitig einen ersten Ansatz zur Formulierung der mit dieser Diplomarbeit verfolgten Ziele.

Ein primäres Ziel ist das Konzept zum Aufbau einer Geodateninfrastruktur bei der Polizei Rheinland-Pfalz. Um die Ausmaße dieses Ziels richtig einordnen zu können, müssen zunächst die technischen Grundlagen geschaffen, diesbezügliche Standards und Spezifikationen unter­schiedlichen technischen Ebenen zugeordnet und ein Verständnis über polizeiliche Daten­verarbeitung geschaffen werden.

Ein weiteres vorrangiges Ziel liegt in der Entwicklung von Lösungsansätzen zur raum­bezogenen polizeilichen Sachbearbeitung. Durch die Verknüpfung unterschiedlicher Ansätze aus den Bereichen Wissensmanagement und geographische Dienste soll dieses Ziel erreicht werden.

Der Nachweis der Geeignetheit des UMN MapServers für den Einsatz in einem Geo­informationssystem bzw. als Basiskomponente in einer Geodateninfrastruktur zählt ebenso zu den hauptsächlichen Zielen dieser Arbeit. Die Tauglichkeit der OpenSource Software hierfür soll mit der Realisierung von vier technischen Prototypen belegt werden.

1.3 Abgrenzung

Um die vorgenannten Ziele zu erreichen, ist die Konzentration auf wesentlichen Aspekte eine Grundvoraussetzung. Daher wird bei den Ausführungen zu den technischen Grundlagen der gesamte Bereich der Erfassung und Digitalisierung der Geobasisdaten außer Acht gelassen; allein dieses Feld ist für mehrere Abhandlungen ausreichend. Ebenso wenig wird die Kartographie und der eigenständige Bereich des Web-Mapping behandelt.

Gleichfalls wird keine Grundsatzdiskussion zu OpenSource geführt. Es existieren genügend Foren, in denen die Vor- und Nachteile für deren Verwendung ausführlich besprochen werden.

Bei der Konzeption zum Aufbau der Geodateninfrastruktur wird auf die Beschreibung von einzelnen Projektphasen ebenso verzichtet, wie auf ein strenges methodisches Vorgehen. Das Aufzeigen des Umfangs und die damit verbundenen Möglichkeiten durch den Aufbau einer Geodateninfrastruktur stehen im Vordergrund; nicht das frühzeitige Festlegen auf Meilen­steine oder das Erstellen des Pflichtenhefts.

Die Implementierung umfasst die Konvertierung und Aufbereitung von Geodaten sowie die Realisierung von vier technischen Prototypen. Ein voll funktionsfähiges Geoinformations­system würde den Rahmen der Arbeit bei weitem sprengen und die anderen genannten Zielen verdrängen.

1.4 Aufbau und Gliederung

Mit Kapitel 2 werden die grundlegenden Begriffe bezüglich Geoinformationssysteme ein­geführt. Hierin erfolgen Angaben zu dem Aufbau und den Aufgaben eines Geoinformations­systems, zu Geodaten und zu räumlichen Bezugssystemen. Nach den Ausführungen zur Modellierung von Geodaten werden unterschiedliche GIS-Architekturen vorgestellt. Ab­geschlossen wird das Kapitel mit einer Übersicht der internationalen und nationalen Bestrebungen zum Aufbau von Geodateninfrastrukturen.

Kapitel 3 hat Standards, Interoperabilität und OpenSource zum Thema. Die regulierenden Gremien werden mit ihren Aufgaben und ihren Beiträgen zur Erreichung von Interoperabilität vorgestellt. Die Interoperabilität wird aus verschiedenen Perspektiven beleuchtet und anhand von Standards und Spezifikationen der vorgenannten Gremien erläutert. OpenSource als fester Bestandteil der Softwareentwicklung im Bereich von Geoinformationen wird anschließend betrachtet. Nach allgemeinen Ausführungen wird besonders auf den UMN MapServer als zentrale Komponente von internetbasierten Geoinformationssystemen eingegangen.

In Kapitel 4 wird nach den Erläuterungen zur Infrastruktur und den Anwendungen bei der Polizei Rheinland-Pfalz auf deren Aufgaben eingegangen. Darauf aufbauend werden zwei Lösungsansätze zur raumbezogenen Sachbearbeitung entwickelt und detailliert erläutert. Daran schließen sich die Ausführungen zu dem Konzept zum Aufbau einer Geodaten­infrastruktur bei der Polizei Rheinland-Pfalz an. Dieses orientiert sich zunächst am Status quo der geographischen Datenverarbeitung der Polizei Rheinland-Pfalz und schließt mit Handlungsempfehlungen für deren Umsetzung sowie den zu beachtenden Rahmen­bedingungen ab.

Im Kapitel 5 wird die im Rahmen dieser Diplomarbeit erbrachte Implementierung dargelegt. Nach Angaben zur Entwicklungsumgebung wird die Konvertierung und Aufbereitung der verwendeten Geodaten erläutert. Im Anschluss folgt die umfassende Beschreibung von vier technischen Prototypen. Der UMN MapServer nimmt eine bedeutende Rolle bei der Realisierung der Prototypen ein. Ihre Nutzung in verschiedenen Aufgabenfeldern werden ebenso aufgezeigt wie der breite Funktionsumfang des UMN MapServers. Abgeschlossen wird das Kapitel mit Bewertungen zur Entwicklungsumgebung, den Geodaten und den technischen Prototypen.

Kapitel 6 fasst die Ergebnisse der Diplomarbeit zusammen und bietet einen Ausblick auf das weitere Vorgehen beim Aufbau einer Geodateninfrastruktur bei der Polizei Rheinland-Pfalz.

In der Anlage A befinden sich weiterführende Angaben zur Entwicklungsumgebung und zu der im Rahmen der Implementierung verwendeten Datenbank. Anlage B enthält das readme zur beigefügten DVD. Die DVD ihrerseits enthält die vier technischen Prototypen sowie die notwendigen Geodaten.

1.5 Anmerkungen

Bei vielen der nachfolgend verwendeten Hersteller- und Produktnamen handelt es sich um eingetragene Warenzeichen oder in sonstiger Weise geschützte Namen bzw. Bezeichnungen. Diese unterliegen den jeweiligen rechtlichen Bestimmungen.

In allen Bereichen des täglichen Lebens finden sich weibliche und männliche Bezeichnungen für Berufe, Tätigkeiten oder geschlechtsspezifische Eigenschaften. Ausschließlich aus Gründen der Lesbarkeit wird auf diese Unterscheidungen verzichtet. Gemeint sind aber immer beide Bezeichnungen.

2 technische Grundlagen

Mit diesem Kapitel werden die für die Diplomarbeit relevanten Begriffe eingeführt, in Zu­sammenhang gebracht und in ihrem Kontext erläutert.

Zuerst stehen Geoinformationssysteme und Geodaten, Geoobjekte und ihre technische Repräsentanz, Bezugssysteme und Projektionen im Zentrum der Betrachtung. Daran schließen sich Aussagen zu GIS-Architekturen an. Hierauf folgen Ausführungen zu Geodateninfra­strukturen. Über die Motivation und zu Vorteilen ihres Einsatzes, Aspekte der tech­nischen Grundlagen und ein Überblick über internationale, nationale und regionale Bestrebungen zu ihrem Aufbau.

Zunächst gilt es festzuhalten, dass die Begriffswelt im gesamten Bereich der Geo­informations­systeme weder einheitlich ausgeprägt noch verbindlich genormt ist. Dennoch haben sich Arbeits­begriffe und zum Teil mehr oder weniger etablierte Begriffe heraus­gebildet [tum]. Für den übergeordneten Komplex der Geodateninfrastrukturen und die Informationen mit Raumbezug existieren jedoch Standards und Spezifikationen der ISO bzw. des OGC.

2.1 Geoinformationssysteme

Ein Geoinformationssystem (GIS) ist ein rechnergestütztes System, das aus H ardware, S oft­ware, D aten und A nwendungen besteht. Mit ihm können raumbezogene Daten e rfasst und redigiert, gespeichert und reorganisiert (v erwaltet), modelliert und a nalysiert sowie alpha­numerisch und graphisch p räsentiert werden [BF94]. Hieraus lassen sich die Vier­komponenten-Modelle [ikg] bezüglich der

- Aufgaben Erfassung, Verwaltung, Analyse und Präsentation EVAP und des

- Aufbaus Hardware, Software, Daten und Anwendungen HSDA

eines GIS ableiten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Vierkomponenten-Modelle EVAP und HSDA eines GIS

Neben dieser Definition existieren viele weitere Begriffsbestimmungen für Geoinformations­system und seine Ausprägungen [ilr]. Die Nutzung von raumbezogenen Informationen und damit der Ursprung von GIS ist sowohl auf staatliches Handeln bei der Raumplanung, der Bo­denordnung oder im Natur- und Umwelt­schutz als auch wissenschaftlich auf die Fachdisziplin der Geo­graphie zurück­zu­führen. Mittl­erweile las­sen sich sechs Fach­richtungen als Mutter­dis­ziplinen von GIS be­greifen. Dabei hat jede Fach­richtung einen eigenen disziplin­spezi­fischen Zugang zum Themenfeld GIS [akgis].

2.2 Geodaten

Geodaten sind Daten über Gegenstände, Geländeformen und Infrastrukturen an der Erdober­fläche, wobei als wesentliches Element der Raumbezug vorliegen muss, sie beschreiben die einzelnen Objekte der Landschaft. Über ihren Raumbezug lassen sich Geodaten miteinander verknüpfen, woraus insbesondere unter Nutzung von GIS-Funktionalitäten wiederum neue Informationen abgeleitet werden können. Auf und mit ihnen lassen sich Abfragen, Analysen und Auswertungen für bestimmte Fragestellungen durchführen. Geodaten lassen sich in zwei große Teilkomplexe aufteilen, nämlich die Geobasisdaten und die Geofachdaten (Fachdaten) [BIL99].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Geodaten [ikg]

Geodaten beschreiben Objekte, die direkt durch ihre Position im Raum oder indirekt durch ihre Beziehungen referenzierbar sind. Unterscheiden lassen sich folgende Datenarten:

1. Geometriedaten
2. Topologiedaten
3. Sachdaten

Geometriedaten (1) benennen alle geometrischen Elemente wie Punkte, Linien, Flächen und Raster. Sie sind in einem räumlichen Bezugssystem definiert und beschreiben Form und Lage von Objekten. Sowohl analog als auch digital kommen sie in Raster- und Vektorform vor. Der Punkt ist hierbei Träger der geometrischen Information. Die Topologiedaten (2) benennen topologischen Elemente wie Knoten, Kanten und Maschen. Sie beschreiben koordinatenfreie Geometrie- und Nachbarschaftsbeziehungen und sind dabei invariant gegenüber topologischen Transformationen. Die Kante ist der Träger der topolo­gischen Information. Sachdaten (3) sind der Sammelbegriff für Attribute, beschreibende Daten und Fachdaten. Sie benennen sämtliche nichtgeometrischen Elemente wie z.B. Texte, Zahlensammlungen, Mess­werte oder Tabellen. Im Allgemeinen werden sie in einem spezifischen Zusammen­hang zur Erledigung fachlicher Aufgaben erhoben.

Graphikdaten gehören zur vollständigen Beschreibung dazu. Sie setzen sich aus Geometrie­daten und graphischen Beschreibungselementen wie Symbole, Schraffuren, Linienstärke usw. zusammen. Auch sie kommen in analoger und digitaler Form vor.

2.2.1 Geobasisdaten

Geobasisdaten sind eine Teilmenge der Geodaten, welche die Landschaft und die Liegen­schaften der Erdoberfläche beschreiben. Zu ihnen zählen im Wesentlichen die Daten der Vermessungsverwaltung, die als Grundlage für viele Anwendungen geeignet sind. Speziell umfasst der amtliche Geobasisdatensatz^[1] die vorhandenen Daten aus der Automatisierten Liegenschaftskarte (ALK), dem Automatisierten Liegenschaftsbuch (ALB) und dem Amtlichen Topographisch-Kartographischen Informationssystem (ATKIS) [gur] [tum].

Straßendaten werden beispielsweise von privaten Anbietern erhoben und für Navigations­systeme eingesetzt. Wie bei den amtlichen Geobasisdaten ist die Aktualität und die Genauigkeit der Geobasisdaten ein entscheidendes Qualitätsmerkmal.

2.2.2 Geofachdaten

Geofachdaten, oder Fachdaten, sind die in den jeweiligen Fach­disziplinen erhobenen Daten. Durch den Zusatz Geo soll konkretisiert werden, dass auch diese Daten einen Raumbezug besitzen. Der Raumbezug kann direkt über Koordinaten oder indirekt z.B. durch Post­leitzahlenbezirke sowie administrative Einheiten gegeben sein. In der öffentlichen Verwaltung des Bundes und der Länder werden Geofachdaten (Statistik, Raumordnung, Naturschutz usw.) u.a. auf Grund von Fachgesetzen geführt [gur] [tum].

2.2.3 Metadaten

Geodaten werden durch Metadaten, also Daten über Daten, beschrieben. Idealtypisch wer­den diese in einem Metadaten-Informationssystem^[2] geführt. Metadaten enthalten wichtige Informationen, die Hinweise über die Verwendbarkeit der Geodaten für spezifische technische, rechtliche oder geschäftliche Anforderungen sowie deren Herkunft, Umfang, Aktualität und Qualität geben. Auf diese Weise werden die auf Grund unterschiedlicher fachlicher Zu­ständigkeiten verteilt geführten Geodatenbestände transparent und der Zugriff auf sie er­leichtert [bkg]. Sie stellen eine Ansammlung von zusätzlichen Daten dar, die normaler­weise nicht von den über sie beschriebenen Daten beinhaltet werden.

Allerdings ist in verteilten Strukturen bei umfangreichen Datenbeständen zur Opti­mierung der Datennutzung und des Datenzugriffs die Verwendung von geeigneten Meta­datenkonzepten zwingend erforderlich. Es existieren zwei Normierungsansätze: ein interna­tionaler^[3] ISO/TC211 19115 und ein amerikanischer FGDC-STD-001-1998. Beide Standards verfolgen die Mehrfachnutzung von Geodaten durch ein System von Bewertungs­skalen und Beschreibungsrichtlinien, unterscheiden sich jedoch in ihrer Komplexität und der Berück­sichtigung bestehender Standards.

Angelehnt an den FGDC-Standard sollte ein Metadatenkonzept aus folgenden sieben Infor­mations­gruppen bestehen mit Informationen [tum]:

- zur Identifikation von raumbezogenen Daten
- zur Datenqualität
- zur Datenorganisation
- zum Raumbezug
- zu Entitäten und Attributen
- zur räumlichen Verteilung der Daten
- über Beziehungen zu weiteren Metadaten

Metadaten bilden einen wichtigen Aspekt in der Planung und Realisierung von Geo­informationssystemen. Wegen der zunehmenden Verfügbarkeit von Geodaten und der Erweiterung des Anwendungsspektrums von diesen Systemen ist der Bedarf an strukturierten Zu­satzinformationen zu den Geodaten gewachsen.

2.2.4 Geoobjekte

Abbildung in dieser Leseprobe nicht enthalten

Waren in früheren Systemen die einzelnen Datenarten getrennt voneinander abgelegt, sind in heutigen Systemen die Geodaten als Objekte gespeichert.

Ein Geoobjekt, begriffen als abstraktes Modell eines realen räumlichen Objektes, ist in einem GIS somit die grund­legende Einheit zur Erfassung einer natürlichen Gegebenheit. Zu den identifizierbaren Merkmalen gehört neben den zu er­fassenden Attributen der vorgenannten Datenarten (Geo­metrie-, Topologie- und Sachdaten) ein eindeutiger Objekt­identifikator. Zudem wird je nach An­wendungsgebiet noch die Zeit als dynamisches Merk­mal einem Geo­objekt zugeordnet. Die über die Sachdaten erfassten Informa­tionen finden sich in der Literatur oft unter dem Schlagwort Thematik wieder.

Die geometrische, topologische, thematische und dynamische Bedeutung (Semantik) des Geo­objektes im Hinblick auf eine bestimmte fachspezifische Fragestellung bildet die zugehörige Geoinformation.

Ein Objekt kann einer Objektklasse angehören. Durch diesen Oberbegriff wird definiert, welche Arten von Objekten aus der fachlichen Sicht in der realen Welt vorkommen, durch welche Attribute diese in ihrer Charakteristik beschrieben sind und welche Ausprägungen diese Attribute annehmen können.

Ein Objektartenkatalog ist die katalogisierte Sammlung aller definierten Objektarten. Im Falle des ATKIS-Objektartenkataloges^[4] ist eine hierarchische Gliederung der Objektarten mit ihren Obergruppen und –bereichen sowie den Attributen mit ihren Werten festgelegt.

2.2.5 Geometriedaten

Durch ihre Form und ihre relative Lage wird die Geometrie von Geoobjekten vollständig be­schrieben. Geometriedaten stellen die klassische Datenart von GIS dar. Je nach Art der Ge­winnung der Geometriedaten lassen sich diese in die Geometriedatentypen Vektor und Ras­ter unterteilen; die Unterscheidung hat fachliche, methodische und technische Gründe.

2.2.5.1 Vektordaten

Abbildung in dieser Leseprobe nicht enthalten

Im Vektormodell ist der Punkt die kleinste Einheit. Die Beschreibung aller Vektorelemente beruht auf Punkten als Träger der Koordinateninformationen. Punkte werden als Koordinaten in einem geeigneten Koordinatensystem gespeichert. Linien werden als Verbindung zwischen Punkten repräsentiert und als Reihe von Punktpaaren gespeichert. Als Zusatzmerkmal kann die Form der Verbindung, z.B. Gerade oder Kurve, angegeben sein. Flächen bzw. Polygone werden durch geschlos­sene, sich nicht überschneidende, Linienzüge gebildet. Vektordaten sind für die Ver­arbeitung von Daten mit großem Maßstab oder Genauigkeit geeignet [ilr] [tum].

Geometrische Operationen in einem GIS werden üblicher­weise auf Vektordaten ausgeführt. Ihr großer Vorteil liegt in der Unabhängigkeit der Auf­lösung des Ausgabemediums; d.h. eine Ver­größerung des darzustellenden Ausschnitts zieht keine Vergröberung nach sich.

Die drei Grund­elemente von Vektordaten sind:

- Punkte 0-dimensional | 0-Zelle
- Linien 1-dimensional | 1-Zelle
- Polygone 2-dimensional | 2-Zelle

2.2.5.2 Rasterdaten

Abbildung in dieser Leseprobe nicht enthalten

Rasterdaten entstehen vorwiegend durch das Scannen und die anschließende Georeferenzie­rung von analogen Karten, Plänen oder Bildern. Rasterbilder bestehen aus einer durch die Auflö­sung bestimmten Anzahl von Bildpunkten. Die Repräsentation erfolgt zeilen- und spaltenweise durch eine Matrix, wobei einheitliche Flächen z.B. als Pixel, Quadrate oder Rechtecke entstehen. Zwi­schen den Elementen der Matrix existieren keine logischen Verbindungen. Jedoch können geogra­phische Beziehungen hergestellt werden.

Raster­daten haben folgende Eigenschaften [BF94]:

- die graphische Grundstruktur ist ein Pixel
- es entsteht sofort eine flächenhafte Betrachtungsweise
- es wird nur nach der Position der Pixel geordnet
- die logische Datenstrukturierung ist nur sehr eingeschränkt möglich
- die Datenerfassung ist wenig aufwändig und somit schnell
- es entstehen schnell große Datenmengen und damit ein hoher Rechenaufwand

Quadtrees

Abbildung in dieser Leseprobe nicht enthalten

Ein Sonderfall der rasterorientierten Datenverarbeitung sind Quadtrees. Sie sind geeignet um Speicherplatz und Rechenzeit einzusparen. Es liegt eine Baumstruktur vor, deren Knoten sich in Ab­hängigkeit der Datendichte verzweigen.

Das Prinzip beruht auf einer rekursiven Zerlegung von Bildbereichen und der Zusammenfassung homo­gener Bereiche. Das Gitter wird schrittweise bis zu einer gewählten Auflösung verfeinert, bis jede Zelle eine homogene Fläche repräsentiert. Man kann einen Quadtree auch als Index eines Rasters verstehen [ilr].

2.2.5.3 Hybride Daten

In der Literatur [ilr] [tum] [gur] [GKW04] werden die Vor- und Nachteile der beiden Geo­metrie-Datentypen einander gegenübergestellt und bewertet. Einheitliches Ergebnis aller Be­trachtungen ist die Feststellung, dass beide Datentypen ihre Einsatzbereiche und ihre Be­rech­tigung haben. Es wurden daher hybride Systeme geschaffen, um die jeweiligen Vor­teile zu nutzen. Die hybride Datenverarbeitung gestattet somit die gleichzeitige Verarbeitung von Vektor- und Rasterdaten. Eine digitale Karte setzt sich aus unterschiedlichen Daten zusam­men. Getrennt gespeicherte Raster- und Vektordaten als Punkt, Linie oder Polygon ergeben kombiniert aus einzelnen Layer (Ebenen) ein Gesamtbild.

Zudem bieten hybride Systeme die Möglichkeit, Vektordaten in Rasterdaten zu konver­tieren. Die umgekehrte Konvertierung ist immer noch Gegenstand von Forschung und Murphy´s Law [ilr].

Unter [gismngt] findet sich eine umfangreiche Auflistung von GIS-Datenaustauschformaten. Diese sind u.a. nach Vektor- und Rasterdatenformaten aufgeteilt.

Neben Vektor und Raster als Geometrie-Datentypen existieren zudem Grid und TIN, auf die jedoch im Rahmen dieser Arbeit nicht eingegangen wird.

2.2.5.4 Georeferenzierung

Die Georeferenzierung oder Verortung, bezeichnet den Prozess der Verknüpfung von tat­sächlichen Weltkoordinaten in einem bestimmten Bezugssystem mit den Koordinaten der Raster­datei oder anderen Objekten der Erdabbildung.

2.2.6 Räumliche Bezugssysteme

Abbildung in dieser Leseprobe nicht enthalten

Da die Erde im Sinne der Georeferenzierung keine Kugel sondern ein mathematisch nicht definierbarer Geoid ist, lässt sich dessen Form am Besten durch einen Ellipsoid beschreiben. Um eine genaue Projektion von drei­dimensionalen raumbezogenen Daten in ein zweidimensionales Koordinatensystem zu gewährleisten, wird an den darzustellenden Bereich ein gut passender Bezugsellipsoid ange­legt. Der Bezugsellipsoid ist mathematisch definiert, so dass auf ihn ein Koordinaten­system ab­gebildet werden kann. Das erste in breiterem Umfang eingesetzte Ellipsoid war das von Fried­rich Wilhelm Bessel aus dem Jahre 1841, dem Bessel-Ellipsoid. Als weltweit gültiger Bezugs­ellipsoid hat sich heute das WGS 84 durchgesetzt, welches fast deckungsgleich mit dem euro­päischen Standard ETRS89 ist. Weitere gängige Ellipsoide sind das Clarke-1866-Ellipsoid, GRS80 und das Krassowskij-Ellipsoid 1940.

Bei den Projektionen wird zwischen folgenden Arten [imagi] unterschieden:

- Zylinderprojektion
- stereographische Azimutalprojektion
- Kegelprojektion
- spezielle Zylinderprojektion: Transversale Mercatorprojektion

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Projektionsarten

2.2.6.1 Das Gauss-Krüger System

Bei diesem Bezugssystem handelt es sich um eine universaletransversale Mercator­pro­jektion, benannt nach Carl Friedrich Gauß und Johann Heinrich Louis Krüger. Es ist ein met­risches, ebenes und rechtwinkliges Koordinatensystem mit dem Bessel-Ellipsoid als Bezug. Dabei werden Meridianstreifen von 3° Breite auf einen quer zur Erdachse liegenden Zylin­dermantel abgebildet und zur Vermeidung größerer Verzerrungen jeweils nachgedreht, so dass immer nur Gebiete im Ost-West Ausmaß von drei Längenkreisen in einem Meridian­streifensystem dargestellt werden.

Abbildung in dieser Leseprobe nicht enthalten

Die Maßeinheit im Gauß-Krüger (GK) System beträgt Meter; der Nullpunkt bildet den Schnitt­punkt des Meridianstreifens mit dem Äquator [imagi] [wiki-de]. Der erste Wert der Koordinate im GK System ist der Rechts- oder X-Wert. Während die erste Ziffer der ersten Zahlenfolge die Kennziffer des Bezugs­meridians ist, bezeichnet die folgende sechsstellige Zahl den Ost-West-Abstand der Position vom Bezugsmeridian. Dem Bezugs­meridian wird der Wert 500 zugeordnet. Der zweite Wert der Koordinate besteht aus sieben Ziffern und ist der Hoch- oder Y-Wert. Er beschreibt den nördlichen Abstand der Position vom Äquator.

Beispiel: Staatstheater Mainz, (x,y) 2 662888 5542790

Das Staatstheater Mainz liegt 162,888 km (662,888 km – 500 km) östlich des 2. Haupt­meridians, 6° E, und 5542,790 km nördlich des Äquators.

2.2.6.2 Das UTM-System (WGS84, ETRS89)

Abbildung in dieser Leseprobe nicht enthalten

Dem UTM-System liegt ebenfalls eine winkeltreue universale transversale Mercator­pro­jektion zugrunde. Die Abbildung der Meridiane er­streckt sich zwischen 84° nördlicher Breite und 80° süd­licher Breite; die beiden Polarkappen werden durch die Uni­versal Polar Stereographic Abbildung (UPS) dar­ge­stellt. Im Unterschied zum Gauß-Krüger-System sind die Meridian­streifen in einer Ausdehnung von Δλ = 6° auf einen Zylin­der abgebildet und werden als Zonen be­zeichnet. In Eu­ropa liegen die Mittelmeridiane bei 3°, 9° und 15° und tragen die zugehörigen Zonennummern 31, 32, und 33.

Die waagerechte Unterteilung ergibt 20 Felder von denen 19 jeweils ein Breite von φ= 8° und eines von φ= 12° aufweist. Die Felder werden von Nor­den nach Süden mit Buchstaben C bis X bezeichnet, wobei I und O ausgelassen werden. Analog zum Gauß-Krüger-System wird ebenfalls ein Gitternetz benutzt, wobei in jedem Gitter­netz der Bezugsmeridian und der Äquator als orthogonale Linie dargestellt werden. Um negative Werte zu vermeiden wird in die X-Richtung eine Konstante von 500 km eingeführt [imagi] [wiki-de].

Beispiel: Staatstheater Mainz, (x,y) 32U 447782 5538793

Das Staatstheater Mainz liegt im UTM-System 52,218 km (447,782 km – 500 km) westlich des Haupt­meridians der UTM Zone 32U und 5538,793 km nördlich vom Äquator. Die Differenz zwischen den nördlichen Äquatorabständen bei GK und UTM von 3,997 km (5542,790 km – 5538,793 km) ist auf die unterschiedlichen Projektionen zurückzuführen.

Die Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder (AdV) legte 1991 die Einführung von ETRS89 fest. 1995 wurde als Ablösung des GK Systems die UTM als Abbildungssystem vereinbart. Wegen den damit ver­bundenen Kosten und der Zuständig­keit der Bundesländer für die Erhebung, Fortführung und Bereit­stellung von Geobasisdaten vollzieht sich der Wechsel des Abbildungssystems sukzessiv.

Der Vollständigkeit halber sei erwähnt, dass neben dem Bezugssystem der Lage (ETRS89) die Bezugssysteme der Höhe und der Schwere existieren. Während das DHHN92 die Aufgabe hat, Niveau und Maßstab für die Höhenmessung über große Gebiete vorzugeben und zu sichern, besteht die Aufgabe des DHSN96 darin, das Niveau und den Maß­stab für die Schweremessung über große Gebiete hin vorzugeben und zu sichern [adv].

2.2.7 Modellierung von Geodaten

Ziel der Modellierung von Geodaten ist die Abstraktion eines Ausschnitts der realen Welt nach bestimmten Anforderungen mit festgelegten Beschreibungstechniken und Methoden in ein rechnertaugliches und domänen­abhängiges Datenmodell abzubilden. Die im Rechner gespeicherten Informationen bilden die Basis für Abfragen, Analysen und Präsentationen. Durch die Modellierung der Geo­daten wird die Leistungsfähigkeit eines GIS mitbestimmt.

Mit einem 3-Stufenmodell lassen sich die einzelnen Phasen der Modellierung erläutern.

Abbildung in dieser Leseprobe nicht enthalten

Die Abstraktion (1) ist gekennzeichnet durch Vereinfachungen und Ein­schrän­kungen gegen­über der realen Welt. In dem dabei re­sultierenden konzeptionellen Modell werden sowohl die Objekte der realen Welt mit ihren Be­ziehungen unter­einander als auch ihr Verhalten objekt­strukturiert [tum] festgehalten. Das Mo­dell ist zu diesem Zeitpunkt noch unab­hängig von GIS- oder Datenbank­systemen. Die logische Modellierung (2) basiert zwangs­läufig auf den Ergebnissen der konzeptionellen Modellierung, ist aber ebenso abhängig von der gewählten Systemarchitektur. Hierbei werden die logischen Beziehungen der vorher identifizierten Objekte in hierarchischer, relationaler oder anderer Form in die Daten­strukturen des Datenbanksystems abgelegt. Mit dem physikalischen Modell (3) wird die Organisation der Geoobjekte in Form von sequentiellen Dateien oder Listen im Dateisystem und der Zugriff auf sie festgelegt. Aus Datenbanksicht befindet sich das physikalische Daten­modell im in­ternen Schema [gur].

Die logische Modellierung schlägt die Brücke zwischen den Objekten der realen Welt und ihrer rechnergestützten Speicherung. Es stehen hierfür die Konzepte bzw. Paradigmen der objektorientierten, der relationalen und der objektrelationalen Modellierung zur Auswahl.

2.2.7.1 Objektorientierte Modellierung

Das OO-Paradigma erlaubt die Modellierung der Struktur, über Klassen mit Attributen, und des Verhaltens, über die in den Klassen definierten Methoden, von Systemen. Grundlage des OO-Para­digmas, das sowohl bei objektorientierter Analyse und Design (Modellierung) von Systemen, bei der OO-Programmierung wie auch bei OO-DBMS ein­gesetzt wird, ist die Abstraktion der Realität in Objekte, Klassen und Beziehungen. Die sechs Kernelemente des OO-Paradigmas sind:

1. Klassen
2. Objekte
3. Beziehungen (Assoziationen)
4. Kapselung
5. Vererbung
6. Polymorphismus

Eine Klasse (1) beschreibt die Struktur und das Verhalten der zu ihr gehörenden bzw. von ihr er­zeugten Objekte. Jedes Objekt (2), als konkrete Instanz einer Klasse, besitzt seine eigene Identität, die es von allen anderen Objekten unterscheidet. Beziehungen (3) sind die Grund­lage der Kommunikation zwischen Klassen und deren Objekten. Jedes Objekt ist gegenüber der Umwelt verschlossen (4); sein Zustand kann nur über die Methoden bzw. Operationen des Objektes, die in der Klasse definiert sind, erfragt und geändert werden. Von einer Klasse kön­nen Unterklassen abgeleitet (5) werden. Sie erben die Attribute und Operationen der Ober­klasse; dies ermöglicht die Wiederverwendung einmal definierter Strukturen und Operationen. Methoden bzw. Operationen können sich in verschiedenen Klassen unter­schiedlich verhalten (6); dies wird erst aktuell zur Laufzeit vom ausführenden Objekt entschieden.

Durch die Unified Modelling Language (UML) steht eine standardisierte Beschreibungs­sprache zur Darstellung von Struk­turen und Abläufen in objektorientierten Systemen zur Ver­fügung. Mit verschiedenen Struk­turdiagrammen wie z.B. Klassen-, Objekt-, Komponenten oder Paketdiagrammen und Ver­haltensdiagrammen wie das Anwendungsfall-, das Zustands- oder das Sequenzdiagramm lassen sich einzelne Sichten objektorientiert modellieren.

2.2.7.2 Relationale Modellierung

Vor der Entstehung des OO-Paradigmas mit seinem event driven design wurde die relationale Modellierung eingesetzt. Wichtigstes Werkzeug für solch ein data driven design ist das Entity-Relationship-Diagram, das heute noch in der Praxis vielfach eingesetzt wird. Als wesentliche Begriffe werden unterschieden:

1. Entitätstyp
2. Attribut
3. Beziehungstyp
4. Mengenbeziehung

Abbildung in dieser Leseprobe nicht enthalten

Eine Entität (entity) ist ein individuelles Element bei der konzeptionellen Modellierung der Realität. Eine Menge von Entitäten mit gleichen Merkmalen wird als Entitätstyp (1) be­zeichnet. Die Begriffe Entität und Objekt werden in der Praxis häufig nebeneinander verwendet; es muss aus dem Zusammenhang klar sein, ob man Objekt in einem allgemeinen Sinne (z.B. als Geoobjekt), im Sinne der ER (als Entität) oder speziell im OO-Sinne (als In­stanz einer Klasse) meint. Die Merkmale von Entitätstypen werden als Attribute (2) bezeichnet; die Merkmalswerte einer Entität heißen Attributwerte. Die Menge aller möglichen Werte eines Attributes wird als Domäne dieses Attributes bezeichnet. Beziehungen zwischen Entitäten unterschiedlichen Typs verwenden den Begriff Relationen. Die Menge der Bezie­hungen zwischen zwei Entitätstypen heißt dementsprechend Beziehungstyp (3). Der Rela­tionsbegriff entspricht dem der Mathe­matik: Eine Relation ist eine Teilmenge der Produkt­menge zweier Entitätstypen. Beziehungs­typen werden danach unterschieden, ob sie eine oder mehrere Entitäten miteinander in Beziehung setzen. Für eine grobe Unterscheidung sind drei solche Mengenbeziehungen (4) ausreichend. Seien A und B Entitätstypen und R eine Relation R(a,b) mit a Î A und b Î B:

Abbildung in dieser Leseprobe nicht enthalten

2.2.7.3 Objektrelationale Modellierung

Die objektrelationale Modellierung lässt sich unterschiedlich hergeleiten: ent­weder als Erweiterung einer objektorientierten Datenbank um die Möglichkeit der relatio­nalen Modellierung um SQL oder als Erweiterung des relationalen Modells um Fähigkeiten der Objektorientierung [tum]. Eine formale Definition existiert jedoch nicht.

2.3 GIS-Architekturen

Abbildung in dieser Leseprobe nicht enthalten

In Abhängigkeit der zu erledigenden Aufgaben, den organisatorischen und tech­ni­schen Vor­gaben sowie sonstigen Rahmenbedingungen, wie beispielsweise die zur Ver­fügung stehenden Mittel, ist die Architektur eines GIS zu wählen.

Entsprechend dem Vierkomponentenmodell HSDA von Seite 5 zählen die Hardware, die Software, die Daten und die An­wendungen zu den Komponenten eines GIS. Unabhängig von einer kon­kreten Architektur lassen sich Interdependenzen der be­teiligten Komponenten erkennen. Bedingt durch die schnelle Ent­wicklung und Verbreitung des Internets und der damit ver­bundenen Technologien sind die Architekturen von GIS Änderungen unterworfen.

Obwohl klare Abgrenzungen häufig schwierig zu finden sind, lassen sich dennoch grundlegenden Kategorien von Architekturen unterscheiden [tum] [kgl] [giswiki], die in den nachfolgenden Unterkapiteln dargelegt werden.

Umfassende Aufstellungen über verschiedene freie und kommerzielle GIS-Software finden sich unter [giswiki], [freegis] und [akgis]. Eine klar strukturierte Übersicht getrennt nach GI-Produkten, Anbieter und Dienstleister, Anwendungsgebieten, GI-Systemen sowie einer Ge­genüberstellung von GI-Produkten anhand spezifischer Eigenschaften, unterstützt durch eine Datenbanksuche, ist bei [gur] zu finden.

2.3.1 Desktop-GIS

Ein Desktop-GIS ist meist auf eine spezielle Anwendung zugeschnitten. Als Einzelplatz­rechner integrieren sie monolithisch die graphische Benutzerschnittstelle, als Businessschicht die GIS-Basissoftware und die GIS-Fachanwendungen (Fachschalen) sowie die Datenhaltung. Sie bieten i.d.R. über die GIS-Basissoftware die wichtigsten GIS-Funktionalitäten an, er­reichen aber nicht den funktionalen Umfang von Client / Server-GIS. Die Datener­fassung,
-verwaltung und die -auskunft für kleinere Datenmengen und Projekte sind der Haupt­an­wendungsbereich.

2.3.2 Client / Server-GIS

Bei einem Client / Server-GIS sind die einzelnen Bestandteile der GIS Software in einer n-Tier-Architektur verteilt. Die Geodaten sind in einer Geo Datenbank, die zentralen Anwendungen auf einem Server gespeichert und die Clients greifen mit eigener GIS Software auf diese(n) Server zu. Die Clients können als Bearbeitungs- oder Auskunfts­arbeitsplatz eingerichtet sein. Wesentliches Unterscheidungs­merkmale zwischen einem Client / Server-GIS und einem Desktop-GIS liegen in der Verteilung der GIS Software, der gleich­zeitigen Nutzung von Geodaten durch mehrer Clients und nicht zuletzt dem modularen Auf­bau und der Erweiterbarkeit des Servers. Wegen der Notwendigkeit der Installation von GIS Software auf dem Client-Rechner ist auch der Begriff Fat-Client gebräuchlich.

2.3.3 Web-GIS

Unter dem Begriff Web-GIS, oder synonym Internet-GIS, wird im Allgemeinen ein Geo­informations­system verstanden, dessen Funktionalität zum Teil von Technologie­standards des Internet unterstützt wird; wie beispielsweise Protokolle und Datenformate. Auch hier existieren wieder eine Vielzahl von Ausprägungen und Be­zeichnungen [giswiki]. Die Unterschiede liegen in der Funktionalität des Servers bzw. des Clients. Werden nur Geodaten vom Server geliefert und ist der Client verantwortlich für die Weiterverarbeitung, spricht man von einem Geodaten-Server. Werden nur Karten vom Server geliefert und findet keine weitere Verarbeitung von Client Anfragen statt, finden sich die Bezeichnungen Map-Server^[5] und Map-Client. Hierbei ist es unerheblich, ob die Karten auf dem Server dynamisch erzeugt werden oder als sog. static maps in einem Rasterdaten-Format vorliegen. Eine häufig zitierte Unterteilung der einzelnen Ausprägungen des Web-GIS wurde von [PLE97] getroffen.

Generell ist beim Web-GIS die Funktionalität des Clients auf die Visualisierung der Anfrage­ergebnisse und einfache GIS Funktionen, wie Navigieren reduziert. Somit ist für den Client nur noch ein Webbrowser erforderlich. Die komplexen GIS Funktionen wie die Transfor­mation zwischen verschiedenen Bezugssystemen werden serverseitig ausgeführt.

Die nachfolgende Grafik verdeutlicht den Aufbau mit den beteiligten Komponenten. Die übertragenen Datenformate sind unabhängig von einer konkreten Softwareumgebung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: beteiligte Komponenten und Aufbau des Web-GIS

Als Sonderfall des Web-GIS gelten die OGC-konformen Map-Server. Die Nutzung der vom OGC definierten Schnittstellen und dem damit verbundenen Einsatz von OGC Web Services stellen eine erhebliche Erweiterung der Möglichkeiten des Web-GIS dar. Wesentliches Ziel ist die Schaffung der Interoperabilität der unterschiedlichen beteiligten Systeme auf Grund­lage der Standardisierung der Kommunikation. Klassische Begriffe wie Client und Server verlieren hierbei ihre angestammten starren Bedeutungen. Vielmehr können die beteiligten Systeme gleichzeitig sowohl als Client als auch als Server agieren.

OGC-Konformität und die damit angestrebte Interoperabilität sind Voraussetzungen für den Aufbau und das Betreiben einer Geodaten­infrastruktur (GDI). Eine detaillierte Übersicht sowie weitere Erläuterungen zum OGC und den OGC Web Services findet sich in Kapitel 3 Standards, Interoperabilität und OpenSource.

2.3.4 mobiles GIS

Zu diesem neuen Schlagwort gehört beispielsweise die Kartierung vor Ort oder der Einsatz von mobilen Endgeräten um orts­be­zogene Informationen zu erhalten. Das mobile GIS kann ent­weder über eine Funknetzverbindung mit einem GIS-Server genutzt oder autonom ein­gesetzt werden.

Location Based Services (LBS), standardisiert durch ISO/TC211 19133, bieten nach der Theorie Ortung über GPS-Verfahren als Basisdienste Orts­bestimmungen, Objektsuche, Routing oder Verkehrsinformationen an [htw]. Zu den zahl­reichen Problemen zählen die Verfügbarkeit, die Genauigkeit und die Aktualität der bereitge­stellten Geodaten. Ebenso gehört die Darstellung von relevanten Informationen auf niedrig auflösenden Displays zu den Problemfeldern.

Das OGC hat mit der Open Location Services Initiative (openLS) bereits die Architektur Geo­Mobility Server für ortsbezogene Dienste definiert [BFW-26].

2.4 Geodateninfrastrukturen

Der primäre Nutzen einer Geodateninfrastruktur liegt nach [BFW-01] in dem generellen Zu­gang / Zugriff auf Geoinformationen bzw. dem Ermöglichen eines effizienteren Zugriffs durch immer mehr Anwender.

Laut [gur] ist eine GDI dem Sinne nach vergleichbar mit anderen Infrastrukturen wie beispielsweise dem Verkehrsnetz. Demnach ist die GDI ist eine aus organisatorischen, technischen und rechtlichen Re­gelungen bestehende Bündelung von Geoinformations­ressourcen, in der Anbieter von Geo­datendiensten mit Nachfragern solcher Dienste kooperieren. Bestandteile einer GDI sind die Geodaten mit ihren Metadaten, ein Geo­informations­netzwerk, Dienste und Standards. Besonders im öffentlichen Bereich gehören hierzu poli­tische Rahmen­bedingungen und inter­organisatorische Verein­barungen.

Je nach Definition stehen die Mechanismen, Regelwerke und Standards als Voraussetzung und gleichzeitiger Bestandteil einer GDI im Mittelpunkt. Nimmt die Infrastruktur diesen zentralen Platz ein, sind die oben genannten organisatorischen Komponenten nicht Be­standteil der Definition [BFW-01].

Nach [WRF04] liegen die Vorteile einer GDI für die Anwender und Anbieter im Wesent­lichen in:

- den reduzierten Kosten der Datenproduktion
- der Vermeidung von Mehrfacherhebungen
- den geringen Aufwänden für den Datenzugriff
- dem verbesserten Datenaustausch zwischen unterschiedlichen Institutionen und Anwen­dungsdomänen
- dem Angebot höherwertiger Daten für die Entscheidungsfindung

Auf globaler, europäischer, nationaler und regionaler Ebene sowie auf Instituts- oder Unter­nehmensebene werden derzeit unter Verwendung standardisierter Geoinformations­dienste (GI-Dienste) Geodateninfrastrukturen aufgebaut um über System- und Ver­waltungs­grenzen hinweg die kooperative Nutzung dieser Dienste zu ermöglichen [BFW-01].

Die global agierende Initiative Global Spatial Data Infrastructure (GSDI) hat das Ziel in al­len UN-Staaten den Aufbau von GDIen zu initiieren und die Harmonisierung der nationalen GDI zu fördern. Hierzu wurde ein Cookbook [gsdi] als Referenz für den Aufbau von GDI verfasst.

2.4.1 INSPIRE - Eine GDI für Europa

Mit der Initiative In frastructure for Sp atial I nfo r mation in E urope (INSPIRE) soll eine euro­päische Geodatenbasis mit integrierten raumbezogenen Informationsdiensten realisiert wer­den. Ziel ist eine European Spatial Data Infrastructure (ESDI). Die Motivation hierzu liegt in den innerhalb der europäischen Verwal­tung ver­wendeten Geo­daten begründet. Diese sind oft von schlechter Qualität, weisen Lücken in ihrer Verfügbarkeit auf, zeich­nen sich durch fehlende Harmonisierung zwi­schen den Datenformaten aus und beruhen zum Teil auf unter­schiedlichen Spezifikationen [inspire] [imagi].

Angestrebt wird eine EU-Richtlinie, welche die Mitgliedstaaten verpflichten soll, in einem mehrjährigen Prozess interoperable Geobasisdaten und Geofachdaten sukzessive bereit­zustellen. Folgender Zeitplan ist für die Umsetzung angedacht [BFW-03]:

1. INSPIRE-Vorbereitungsphase (2004-2006)
2. INSPIRE-Umsetzungsphase (2006-2008)
3. INSPIRE-Implementierung (2009-2013)

Konkrete Forderungen als Meilensteine und Orientierungspunkte [BFW-03] wurden formu­liert und finden sich in den INSPIRE Principles [inspire] [BFW-03] [imagi] wieder:

- es sollte möglich sein, nahtlose Raumordnungsinformationen aus unterschiedlichen Quellen in Europa miteinander zu kombinieren und sie von zahlreichen Nutzern und Anwendungen gemeinsam verwenden zu lassen - Interoperabilität
- die Daten sollten dort einmal erfasst und auf dem neuesten Stand gehalten werden, wo dies am wirksamsten möglich ist - Subsidiarität
- auf einer Ebene gesammelte Informationen sollten von allen Ebenen genutzt werden können: detailliert für Einzeluntersuchungen, allgemein für strategische Zwecke
- Skalierbarkeit
- geografische Daten sollten leicht verständlich und interpretierbar sein - Klarheit
- geografische Informationen, die für eine gute Verwaltung auf allen Ebenen benötigt wer­den, sollten reichlich und unter Bedingungen zur Verfügung stehen, die ihre um­fassende Nutzung nicht behindern - Datenpolitik
- es sollte leicht festzustellen sein, welche geografischen Informationen zur Verfügung ste­hen und dem Bedarf im Einzelfall entsprechen sowie unter welchen Bedingungen sie erworben und genutzt werden können - Transparenz

Durch die aktive Mitarbeit sowohl von Vertretern des Bundes als auch der Länder, an der Gestaltung der EU-Rahmenrichtlinie ist gewährleistet, dass einerseits deutsche Interessen in diesem Projekt gewahrt und andererseits Anforderungen aus diesem Projekt frühzeitig erkannt und berücksichtigt werden [imagi].

2.4.2 GDI-DE - Eine nationale Geodateninfrastruktur für Deutschland

1998 hat die Bundesregierung den Interministeriellen Ausschuss für Geoinformationswesen (IMAGI) für die Koordination der Aktivitäten bezüglich dem Aufbau der Geodateninfrastruk­tur Deutschland (GDI-DE) sowie der Entwicklung und dem Einsatz von Geoinformation als modernes Instrument staatlichen Handelns [imagi] eingerichtet. Dieser unter Federführung des Bundesministerium des Innern (BMI) tagende Ausschuss setzt sich aus neun weiteren Ministerien und dem AdV zusammen. Wegen der föderalen Struktur wurden bis 2003 ver­schiedene Initiativen in Bund, Ländern und Kommunen gestartet. Nach einem Beschluss des Chefs des Bundeskanzleramts und den Chefs der Staats- und Senatskanzleien in Deutschland (CdS) vom 27.11.2003 wurde ein konzentriertes Vor­gehen des Bundes und der Länder mit den Kommunalverwaltungen bei der Realisierung der GDI-DE vereinbart [BFW-05] [imagi].

Die GDI-DE ist ein wesentlicher Bestandteil des am 18.12.2003 durch den Bundeskanzler und den Regierungschefs der Länder verabschiedeten Vorhabens Deutschland-Online. Diese zentrale eGovernment Initiative von Bund, Ländern und Gemeinden mit 20 gemeinsamen Projekten basierend auf den fünf Säulen

I. Dienstleistungsportfolio
II. Verbund der eGovernment Portale
III. Infrastrukturen
IV. Standards, Daten- und Prozessmodell
V. eGovernmentkoordinierung und –transfer

flankiert die im September 2000 von Bundeskanzler Gerhard Schröder gestartete Initiative BundOnline 2005, die als Ziel alle onlinefähigen Dienstleistungen der Bundesverwaltung bis 2005 elektronisch verfügbar machen will.

Im Oktober 2001 hat der IMAGI ein dreistufiges strategisches Konzept zur Realisierung der GDI-DE verabschiedet [imagi] [BFW-06]:

1. Herstellung von Transparenz
2. Harmonisierung der Geodaten
3. Herstellung des Zugangs zu Geodaten

Abbildung in dieser Leseprobe nicht enthalten

Die Herstellung der Transparenz (1) soll durch das Vernetzen der Metainformationssysteme des Bundes und der Länder für fach­übergreifende Suchabfragen nach Geo­daten erreicht werden. Seit September 2003 steht als Ergebnis dieser Be­strebungen die Geo­datensuch­maschine GeoMIS.Bund öffent­lich im Internet zur Verfügung [BFW-19]. Die Harmoni­sierung der Geodatenbestände (2) um­fasst zudem die Entwicklung von Schnittstellen und Konvertierungs­modulen unter Berücksichtigung einheitlicher Normen und Standards von Verfahren zur Datenintegration [imagi]. Als gemeinsame Basis für einen ressortübergreifenden Objekt­artenkatalog soll das von der AdV entwickelte, ISO-konforme AAA^[6] -Datenmodell dienen. Der europäische Kontext wird bei der Festlegung der Bezugssysteme mit berücksichtigt. Stufe 3, mit der Herstellung des Zugangs zu Geodaten, sieht die schrittweise Implementierung der Nationalen Geodaten­basis (NGDB) bestehend aus Geobasis-, Geofach- und Metadaten vor. Als Zwischenergebnis ist das GeoPortal.Bund [gpb] zu nennen, in dem die fach­übergreifenden Geodaten zusammenstellt und aufbereitet vorliegen. Dieser Zugang zur GDI-DE soll laut Ankündigung von [imagi] weiter ausgebaut werden. In der nachfolgende Grafik [imagi] sind die Elemente der GDI-DE in ihrem Zusammenhang entsprechend der Definition von [gur] auf Seite 20 dar­gestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Elemente der GDI-DE

Der Aufbau der GDI-DE ist laut [BFW-06] kein zeitlich befristetes Projekt, sondern erfordert über einen mittel- bis langfristigen Zeitraum die konstruktive Zusammenarbeit aller be­tei­ligten Einrichtungen. Als Herausforderung ist neben der Berücksichtigung der euro­päischen Entwicklung auch die Harmonisierung der verteilt bereitgehaltenen Geodaten und die Auf­bringung der damit verbundenen hohen finanziellen und personellen Kosten zu sehen.

Um den Aufbau der GDI zu koordinieren werden in den Bundesländern verschiedene Strategien verfolgt. Unter [gdi-be] findet sich eine Übersicht der Aktivitäten der einzelnen Bundes­länder zum Stand 14.09.2004 und in [BFW-07] wird die GDI-BY aus Bayern und in [BFW-08] die GDI-NRW von Nordrhein-Westfalen vorgestellt.

2.4.3 GDI-RP – Aufbau einer GDI in Rheinland-Pfalz

In Rheinland-Pfalz wurde durch den Beschuss des IT-Ausschusses vom 05.02.2004 der Inter­ministerielle Ausschuss für Geoinformation Rheinland-Pfalz (IMAGI-RLP) eingerichtet. Des­sen Aufgaben bestehen in der

- Abstimmung der Position von Rheinland-Pfalz zu den Beschlüssen des IMAGI
- Entwicklung und Umsetzung eines Konzeptes zum Aufbau einer GDI in Rheinland-Pfalz (GDI-RP)
- Harmonisierung im Bereich Geoinformation
- Förderung des Bewusstseins für Geoinformation

Aktuell^[7] hat der IMAGI-RLP zwei Arbeitsgruppen (AG) eingerichtet:

1. AG Metadaten
2. AG GeoMIS

Die AG Metadaten (1) bearbeitet die Fragestellungen zur Kernkomponente einer GDI-RP und hat einen Erhebungsbogen erstellt. Diesen hat sie mit dem Ziel der Identifizierung der vor­handenen Geo-Metainformationssysteme an alle Ressorts und nachgeordneten Behörden der Landesverwaltung gesendet. Die Erhebungsbögen sind teilweise ausgewertet. Zu den Auf­gaben der AG GeoMIS (2) gehört die Installation eines Brokers zur summarischen Abfrage der unterschiedlichen Metadatenbestände in Rhein­land-Pfalz über eine Sammel­abfrage.

Als Datenbasis sollen die Geobasisdaten von Amtliche Festpunktinformationssystem (AFIS), Amtliche Liegenschaftskatasterinformationssystem (ALKIS) und ATKIS sowie weitere Daten­bestände verwendet werden.

Durch den IMAGI-RLP wurde eine Ministerratsvorlage erarbeitet, welche die Gründung einer Kompetenz- und Geschäftsstelle der GDI-RP zum Thema hat. Ein konkreter Zeit- und Einfüh­rungsplan wurde bisher nicht erarbeitet.

Im Rahmen der GDI-RP ist die Nachnutzung der GeoMIS.Bund Lösung vorgesehen, die be­reits technisch umgesetzt wird.

2.4.4 Verhältnis GIS - GDI

Der Übergang von geschlossenen und monolithischen GIS zu offenen und interoperablen GIS hat nach [BFW-01] einen Paradigmenwechsel in der Entwicklung von GIS-Standards eingeleitet. Die traditionelle Standardisierung von Dateischnittstellen wird durch die Spezifikation von Diensteschnittstellen abgelöst. Eine tragende Rolle wird hierbei vom OGC wahr­genommen, welches zur Schaffung der interoperablen GI-Dienste die Entwicklung der erforderlichen Spezifikationen verantwortlich zeichnet. Die Aufgaben des OGC und die bereits zu­vor erwähnten OGC Web Services als Kernkomponenten einer GDI werden in Kapitel 3 dar­gelegt. Eine GDI ist nach [BFW-01] aber nicht als Ablösung des traditionellen GIS zu ver­stehen. Vielmehr stellt eine GDI eine Ergänzung zu diesen Systemen dar. GIS sind Werk­zeuge für den Aufbau einer GDI. Dies wurde u.a. auf der INTERGEO 2004, einem Kongress für Geoinformation, thematisiert. Dort hat der Runde Tisch GIS e.V. sein Projekt Leitungsauskunft aus verteilten GIS vorgestellt, welches als praxistaugliche, branchen­spezifische GDI Lösung bewertet wurde [intergeo] [rtg].

3 Standards, Interoperabilität und OpenSource

Dieses Kapitel befasst sich mit Standards, Interoperabilität und OpenSource.

Im ersten Teil des Kapitels liegt der Fokus auf standar­disierende nationale und inter­nationale Gremien, ihre jeweiligen Aufgabenfelder und ihre Zusammenarbeit im Bereich der Geo­information. Zudem werden Aussagen zu Standards, Verfahren und Methoden zur Realisierung der deutschen eGovernment Initiativen getroffen.

Interoperabilität als Voraussetzung für den vernetzten Zugang und Zugriff zu / auf Geo­informationen wird nur durch den konsequenten Einsatz von Standards^[8] und Spezifikationen er­reicht. Der zweite Teil des Kapitels stellt die von den vorgenannten Gremien definierte Stan­dards vor, zeigt ihre Einsatzbereiche auf und ordnet sie Interoperabilitätsebenen zu. Es han­delt sich um allgemeine IT- und GIS-Standards sowie Standards die Geo­basisdaten be­treffend. Einige Standards bezüglich der Kommunikation, der Datenpräsentation und der Datenformate werden kurz, andere hingegen die Services, insbesondere die Semantik sowie die Geobasisdaten angehend, ausführlicher vorgestellt.

Der dritte Teil des Kapitels enthält Informationen zu OpenSource. Gerade im Bereich der Realisierung von OGC Spezifikationen existieren eine Vielzahl von Programmen und Be­strebungen, die eine genauere Betrachtung rechtfertigen. U.a. wird auf den UMN Map­Server mit seinen Betriebsmodi, seinen wesentlichen Komponenten und Funktionen eingegangen. Der Ein­satz des UMN MapServers wird in Kapitel 5 Implementierung anhand von vier technischen Prototypen beschrieben.

3.1 standardisierende Gremien

Mit Standards und Spezifikationen werden Grundregeln festgelegt, die für unterschiedliche Anwendungsbereiche gelten. Je nach Anwendungsschicht werden Schnittstellen definiert, Kommunika­tionsprotokolle beschrieben, Austauschformate vorgegeben, Zugriffe auf Daten
(-banken) fest­gelegt oder Dienste spezifiziert. Verschiedene Organisationen tra­gen dafür Ver­antwortung und regeln die diesbezüglichen Handlungsweisen. Der Bedarf nach festen Regeln ergibt sich aus den Anforderungen nach einheitlichen und verlässlichen Vorgehensweisen, die durch die beteiligten Hersteller, Nutzer oder Organisationen erhoben werden.

Für den Bereich der Geodateninfrastruktur und der nationalen Geo(basis)daten existieren im Wesentlichen drei Standardisierungsgremien, die nachfolgend vorgestellt werden. Danach folgt die Vorstellung von technischen Rahmenbedingungen, die für die öffentliche Ver­waltung von Bedeutung sind.

Die nachfolgende Grafik [ikg] gibt einen Überblick der im Bereich GIS beteiligten Gremien.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Übersicht der im Bereich GIS beteiligten Gremien

3.1.1 ISO

Die International Organization for Standardization (ISO) wurde 1946 gegründet und hat ihren Sitz in Genf. Sie hat mehr als 148 Mitglieder, die ihrerseits nationale Normierungs­institute sind; das Deutsche Institut für Normung e.V. ist der nationale Vertreter. In allen technischen Bereichen, mit Ausnahme der Elektronik und Elektrik, erarbeit sie internationale Normen, die sich in technische, klassifikatorische und Verfahrens­standards unterteilen. Durch weltweit einheitliche Normen verfolgt sie zwei Kernziele:

I. den internationalen Austausch von Gütern und Dienstleistungen zu erleichtern

II. durch die Beseitigung technischer Handelshemmnisse sollen internationale Normen den weltweiten Handel vereinfachen und so das Wachstum der Welt­wirtschaft fördern.

Die mehr als 180 Technical Committees (TC), Subkommittees mit den daran angeschlossenen Working Groups (WG) haben bisher [iso] mehr als 13.700 weltweit gültige Normen erlassen. Das Normungsverfahren umfasst sechs Schritte:

1. Vorschlag für eine Norm proposal stage NWIP
2. Vorbereitung der Norm preparatory stage WD
3. Kommiteebearbeitung der Norm comitee stage CD
4. Erkundigungen werden eingeholt enquiry stage DIS
5. Genehmigung der Norm approval stage FDIS
6. Publikation der Norm publication stage IS

Hierbei wechselt jedes Mal der Status: von dem New Work Item Proposal (1), über den Working Darft (2), den Comitee Draft (3), den Draft International Standard (4), dem Final Draft International (5) bis hin zum International Standard (6).

Das Technsiche Komitee ISO/TC 211 mit der Normengruppe ISO 191xx ist verantwortlich für den Bereich Geoinformation und Geomatik. Die Normungsinhalte reichen über Geometrie­grundtypen für ein- bis dreidimensionale Geometrien und Topologien, Modelle zur Beschreibung von Referenzsystemen, die Qualität von Geodaten bis hin zur Auflistung von not­wen­digen und freiwilligen Angaben zu Metadaten [ikg].

Als konzeptionelle Beschreibungssprache der Modelle und Konzepte wird die UML einge­setzt und der Datenaustausch ist mit XML festgelegt.

Die ISO arbeitet neben den nationalen Normierungsinstituten mit dem Europäischen Komitee für Normung, dem Comité Européen de Normalisation (CEN) und das ISO/TC 211 mit dem OGC seit 1998 zusammen. Die Koordinierung der Zusammenarbeit mit dem OGC übernimmt die ISO/TC 211 – OGC coordination group (TOCG)

3.1.2 OGC

Das Open Geospatial Consortium (OGC), bis Oktober 2004 OpenGIS Consortium, ist eine Non-Profit-Organisation (NPO), die sich aus über 270 [ogc] Soft- und Hardware-Herstellern, Behörden, Universitäten, Forschungslabors, Instituten sowie der Industrie zusammensetzt. Sie hat das Ziel, Grundlagen für einheitliche und interoperable Zugriffsmethoden auf raum­bezogene Informationen zu entwickeln und teilt sich hauptsächlich in das Technical, Planning und Strategic Management Advisory Committee auf. Daran angeschlossen existieren weitere Gruppen und Subgruppen.

Der OGC Technology Development Process definiert im Rahmen des Specifications Program (SP) zwei Arten von Spezifikationen:

1. Abstrakte Spezifikationen und
2. Implementierungsspezifikationen

Der Zweck einer abstrakten Spezifikation (1) liegt darin, ein konzeptionelles Modell zu be­schreiben, welches die Erstellung einer Implementierungsspezifikation ermöglicht. Eine abstrakte Spezifikation besteht aus zwei Modellen: a) dem Essential Model, dessen Zweck in der konzeptuellen Beschreibung der Zusammenhänge zwischen dem Software Design und der realen Welt besteht sowie b) dem Abstract Model, welches das zukünftige Softwaresystem imple­mentierungsunabhängig beschreibt. Implementierungsspezifikationen (2) sind ein­deutige Technologiespezifikationen zur Realisierung von Anwendungen oder Programmier­schnitt­stellen [ogc]. Die Implementierungsspezifikationen selbst unterscheiden sich nochmals in Approved bzw. Adopted, Candidate und Planned Implementation Specifactions.

Um die Spezifikationen ineinander zu überführen bzw. um Rückmeldungen einzuarbeiten, werden beim OGC Technology Development Process drei Arten von Requests benötigt:

1. Request for Proposal RFP
2. Request for Comment RFC
3. Request for Information RFI

Das folgende Schaubild [ikg] verdeutlicht einerseits die Einbindung dieser Requests in den Ent­wicklungs­prozess und zeigt gleichzeitig den Prozess der Zusammenarbeit mit der ISO auf.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Technology Development Process und die Arbeit des TOCG

Gegenwärtig existieren 14 Implementierungsspezifikationen [ogc]. Hervorzuheben sind:

- Web Map Service WMS
- Web Feature Service WFS
- Simple Features – SQL SFS
- OpenGIS Location Services openLS
- Coordinate Transformation Services CT
- Geographic Markup Lamguage GML

Der WMS sowie der WFS als OGC Web Services (OWS) bilden die Kern GI-Dienste für den Auf­bau von GDI und werden im Anschluss näher betrachtet. Neben dem SFS existieren zudem APIs für Simple Features - CORBA und Simple Features - OEM/COM.

Das OGC und ISO haben das Feature^[9] als wesentliches Element erkannt und es in den Mittel­punkt ihrer grundlegenden Konzepte gerückt. Für Feature, als Geoobjekt verstanden, wird im General Feature Model (GFM) des ISO ein Regelwerk zur Modellierung von strukturierten Feature Types vorgegeben. Das GFM als Rahmenwerk zur einheitlichen Defi­nition von Anwendungsschemata gewährleistet im Kontext mit anderen ISO/TC 211 Normen die Interoperabilität zwischen Systemen. In [BFW-09] sind diesbezügliche de­taillierte Er­läuterungen und Angaben zu den Simple Features des OGC zu finden.

OGC-Konformität ist erreicht, wenn ein zweistufiger, kostenpflichtiger Test er­folgreich absolviert wurde. Dieser setzt sich zusammen aus einem Konformitätstest und einem Interoperabilitätstest. Erst wenn alle zwingend vorgeschriebenen Kriterien der je­wei­ligen Implementierungsspezifikation erfüllt sind und das zu prüfende Produkt nach­weis­bar mit anderen Produkten in einer interoperablen Umgebung zusammenarbeitet, wird das Zerti­fikat mit dem Prädikat compliant (konform) erteilt. Auch ohne formalen Test kann das Prädi­kat implementing (implementiert) unter bestimmten Voraussetzungen beansprucht werden [ogc] [BFW-02].

Zudem betreibt das OGC weitere Aktivitäten, Initiativen und Programme, welche bei [ogc] aufgeführt sind. Hierzu zählen u.a. die Coordinate Reference System Workgroup (CRS WG) oder die Arbeitsgruppe European Special Interest Group (Europe SIG).

Hervorzuheben ist das Interoperability Programm (IP). Es ist eine Serie von praktischen und technischen Initiativen, um die Entwicklung und die Akzeptanz der OGC Spezifikationen zu beschleunigen. Die Aktivitäten und Funktionen des IP ergänzen und ver­vollständigen die des SP [ogc]. Das IP setzt sich aus folgenden Initiativen zusammen:

- Test Beds (Teststellungen / Testumfeld)
- Pilot Projects
- Interoperability Support Sevices
- Interoperability Experiments

Neben der Zusammenarbeit mit der ISO pflegt das OGC intensive Partnerschaften zu anderen Standardisierungsorganisationen und Industriekonsortien, um die eigenen Ziele in Hinblick auf Interoperabilität verstärkt zu verfolgen [ogc] [BFW-02]. Hierzu zählen beispielsweise:

- World Wide Web Consortium W3C
- Object Management Group OMG
- Organisation for the Advancement of Structured Information Standards OASIS

Die Vielzahl von teilweise konkurrierenden Programmen, Initia­tiven und weiteren internen Organisationsformen innerhalb des OGC, den ver­schiedenen Stati einzelner Dokumente sowie Kooperationen mit anderen Gremien lassen jedoch keine schnelle Erfassung aller Aktivitäten und Spezifikationen des OGC zu.

3.1.3 AdV

Die Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV) ist ein Zusammenschluss von Landesverwaltungen und einzelner Bundes­ministerien zur Regelung von fachlichen Angelegenheiten in Bezug auf Geobasis­informationen von grundsätzlicher und über­regionaler Bedeutung [adv]. Neben dem Plenum, das sich aus den Mitgliedern, dem Beirat, dem Vor­sitzenden und dem Geschäftsführer zusammen­setzt, ist die AdV in vier Arbeits­kreise mit unterschiedlichen Themen organisiert:

1. Arbeitskreis Raumbezug AK RB
2. Arbeitskreis Informations- und Kommunikationstechnik AK IT
3. Arbeitskreis Liegenschaftskataster AK LK
4. Arbeitskreis Geotopographie AK GT

Nach einem Beschluss der Ständigen Konferenz der Innenminister und –senatoren der Länder vom 14.01.2002 wurde die AdV aufgefordert bzw. beauftragt, a) den erforderlichen Ab­stimmungsprozess und die notwendigen Vereinbarungen zum Aufbau einer nationalen Geo­daten­infrastruktur zu initiieren, b) an der Mitgestaltung einer europäischen und globalen GDI teil­zuhaben und c) alle Aktivitäten mit dem Bund abzustimmen. Darüber hinaus wurden die Bundesländer zur verstärkten Mitarbeit an der ISO-Normung und der OGC-Standar­disierung aufgefordert [BFW-05].

Die AdV ist ein fester Organisationbestandteil des IMAGI und hat ihrerseits verschie­dene Aktivitäten zum Aufbau einer nationalen GDI veranlasst. Hierzu zählen sechs Modell­projekte, die nach einem Beschluss vom 07./08.11.2002 gestartet wurden und in die Projekte^[10] der Initiative Deutschland Online überführt werden sollen [BFW-05].

Eine hervorzuhebende Tätigkeit der AdV liegt in der Entwicklung des AAA-Konzepts. Dieses im Bereich Geobasisdaten auf den Spezifikationen der OGC und den ISO-Normen basierende Modell wird im weiteren Verlauf vorgestellt.

3.1.4 SAGA

Für die GDI-DE, als wesent­licher Bestandteil der eGovernment Initiativen BundOnline 2005 und DeutschlandOnline, ist die Konformität zu Standards und Architekturen für E-Government-Anwendungen (SAGA) verbindlich vorgegeben. SAGA, verfasst von der Koordinierungs- und Beratungsstelle der Bundesregierung für Informationstechnik in der Bundesverwaltung (KBSt), stellt in dem gleichnamigen Dokument in gestraffter Form verbreitete Standards, Verfahren, Methoden und Produkte der modernen IT-Entwicklung für eGovernment vor [saga]. Für die Polizei Rheinland-Pfalz hat SAGA den Charakter eines Leitfadens.

Die mit SAGA verfolgten Ziele enthalten [saga]:

- Interoperabilität
- Wiederverwendbarkeit
- Offenheit
- Reduktion von Kosten und Risiken
- Skalierbarkeit

Um diese Ziele zu erreichen, erfolgt mit SAGA die Konzentration auf vier Ent­wicklungs­richtungen bzw. Auf­gaben:

1. Festlegung der technischen Normen, Standards und Architekturen
2. Prozessmodellierung
3. Datenmodellierung
4. Entwicklung von Basiskomponenten

Zur Beschreibung des eGovernment existiert ein Architekturmodell, entsprechend dem Standard ISO 10746 Reference Model for Open Distributed Processing (RM-ODP), welches ver­schiedene Viewpoints enthält. In der nachfolgenden Grafik von [saga] sind die Viewpoints mit ihren je­weiligen Elementen bzw. Handlungsfeldern dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Viewpoints des SAGA Architekturmodells

Standards werden bei [saga] in drei Klassen^[11] eingeordnet und unterliegen einem Lebens­zyklus. Zudem befinden sich auf der Webseite von [saga] drei Listen zur erweiterten Klassifizierung von Standards. Standards können in ihrem Lebenszyklus verschiedene Stadien durchlaufen. Die nachfolgende Grafik [saga] illustriert die Übergänge zwischen den Listen und den Klassen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Lebenszyklus von SAGA Standards

Neue Standards (1) werden zur Klassifikation in die White List eingebracht. Abgewiesene Standards (2) stehen in der Black List. Nach positiver Evaluation (3) werden Standards in der nächsten SAGA-Version aufgenommen und der Klasse unter Beobachtung zugeordnet. Kommende Standards (4) (5) werden in der nächsten SAGA-Version höher klassifiziert. Absteigende Standards werden entweder (6) als empfohlen klassifiziert oder (7) in der Grey List geführt. Veraltete Standards ohne weiteren Bestandsschutz aus der Grey List (8) oder mit dem Status unter Beobachtung (9) werden in die Black List überführt.

In der Black List befindet sich beispielsweise die Vector Markup Language (VML). Scaleable Vector Graphic (SVG) vom W3C als XML-basierte Beschreibungssprache für zweidimensionale Grafikelemente ist in der Grey List als Austauschformat zum Darstellen von Geoinformationen angegeben. Der Web Map Service (WMS) des OGC ist in der White List vertreten. Als Austauschformat für Geoinformationen ist im SAGA Dokument die Geography Markup Language (GML) des OGC empfohlen.

3.2 Interoperabilität durch Standards und Spezifikationen

Das OGC definiert Interoperabilität als gegenseitige Zusammenarbeit von Softwarekompo­nenten zur Überwindung von Konvertierungsproblemen, Hindernissen beim Import und Ex­port sowie Zugangsbarrieren in heterogenen Systemen. Nach ISO 2382-1 ist Interoperabilität die Fähigkeit zu Kommunikation, Programmausführung und Datentransfer zwischen verschie­denen funktionalen Einheiten, in der der Anwender wenig oder keine Kenntnis dieser Einheiten haben muss.

Am 02.04.2003 hat das OGC das OpenGIS Reference Model (ORM) veröffentlicht. Dieses technische Basisdokument beschreibt ein konzeptuelles Rahmenwerk für die interoperable Verarbeitung von geographischen Informationen; vom Einzelplatz­rechner bis hin zum Spatial Web. Aus verschiedenen Sichten (Enter­prise-, Information-, Compu­tational-, Engeneering-, Technology-Viewpoints) wird ebenfalls, wie bei SAGA, auf Basis des Standards RM-OPD die beabsichtigte Interoper­abilität unter Berücksichtigung von Services beschrieben.

Die nachfolgende Grafik des OGC zeigt eine geschichtete Architektur von Technologien und Standards, in der Services entwickelt und eingesetzt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Interoperabilität: Schichten und Standards

Wie unter 3.1.2 erwähnt, arbeitet das OGC eng mit anderen Standardisierungsorganisationen zusammen. Diese tragen ihren Teil zur Sicherstellung der Interoperabilität bei. Nachfolgend werden die bedeutendsten Standards und Spezifikationen der jeweiligen Architekturschicht kurz vorgestellt.

3.2.1 Allgemeine IT-Standards

3.2.1.1 TCP/IP - Transmission Control Protocol / Internet Protocol

Obwohl häufig gemeinsam genannt, handelt es sich bei TCP/IP um zwei eigenständige Proto­kolle. Sie sind Bestandteil der internet protocol suite und bilden den Kern des TCP/IP-Re­ferenzmodell. In den vier Schichten Netzzugang, Netzwerk, Transport und Anwendung sind die Anwenderprotokolle des TCP/IP-Referenzmodells gröber und nicht so detailliert wie in dem siebenschichtigen OSI-Referenzmodell (siehe Abbildung) beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: TCP/IP- versus OSI-Referenzmodell [wiki-de]

IP ist die erste vom Übertragungsmedium unabhängige Schicht des jeweiligen Referenz­modells. Im Gegensatz zur physikalischen Schicht bietet IP eine logische Adressierung einer Netzwerkschnittstelle über eine IP-Adresse. Eine IP-Adresse setzt sich aus einem Netzwerk- und einem Host­adressteil zusammen. Die überwiegend benutzte IPv4 Adresse besteht aus vier Bytes, die durch Punkt voneinander getrennt sind; in der dotted decimal notaion beispiels­weise 130.83.47.128. Damit können maximal 2[32], ca. 4,3 Milliarden eindeutige Adressen ver­geben werden; abzüglich der ersten und der höchsten Hostadresse. Das Domain Name System (DNS) ist ein Dienst, der eine IP-Adresse in einen Namen und umgekehrt umsetzt. Die IP-Adresse 130.83.47.128 mit DNS umgesetzt ergibt www.tu-darmstadt.de. Das IPv4-Protokoll ist im RFC791 definiert und auf das APRANET, der Vorläufer des Internet, zurückzuführen.

TCP ist ein verbindungsorientiertes, zuverlässiges Transportprotokoll in Computer­netz­werken und stellt einen virtuellen Kanal zwischen Endpunkten (Sockets) von zwei An­wen­dungen auf verschiedenen Rechnern her. TCP setzt zumeist auf IP auf und ist in Schicht vier des OSI-Referenzmodells angesiedelt [wiki-de]. Standardisiert ist TCP im RFC793 der Internet Engeneering Task Force (IETF). Die Original Spezifikation stammt ebenfalls aus der Zeit des APRANET.

3.2.1.2 HTTP - Hypertext Transfer Protocol

Das HTTP ist ein zustandsloses Datenaustausch-Protokoll zur Übertragung von Daten. Es wurde 1989 von Tim Berners-Lee auf der Basis von TCP/IP entwickelt. Gemeinsam mit dem Uniform Request Locator (URL) und HTML, ebenfalls von Tim Berners-Lee, stellt es die not­wendigen Bestandteile des WWW bereit. Im TCP/IP-Referenzmodell ist es der Anwendungs­schicht zugeordnet. Durch die Erweiterung der Anfragemethoden, Headerinformationen und Fehlercodes ist HTTP nicht mehr nur auf die Übertragung von Hypertext beschränkt, sondern wird zunehmend zum Austausch beliebiger Daten ver­wendet. Das W3C hat seine Akti­vitäten rund um HTTP eingestellt. Informationen zu Weiterentwicklungen sind in den RFC2774, RFC2964 und RFC2965 enthalten.

[...]

^[1] siehe Kapitel 3.2.4 standardisierte Geobasisdaten

^[2] z.B. GeoMIS.Bund

^[3] siehe Kaitel 3.1.1 ISO

^[4] siehe Kapitel 3 Standards

^[5] nicht zu verwechseln mit der Software UMN MapServer

^[6] AFIS / ALKIS / ATKIS werden in Kapitel 3 erläutert

^[7] Stand: 18.04.2005

^[8] im angelsächsischen Sprachraum existiert keine Unterscheidung zwischen den Begriffen Norm und Standard

^[9] ISO: A fundamental concept of geographic data is the feature.

^[10] siehe Kapitel 2.4.2 GDI-DE – Eine nationale Geodateninfrastruktur für Deutschland

^[11] obligatorisch, empfohlen und unter Beobachtung