[ L T Net ] OPEN-EVENTS :: OPEN MUSIC :: MINICONTENT :: KNOPPIX LINUXTAG.org 
Cornerstone
// LinuxTag 2005
Besuchen Sie uns auch nächstes Jahr wieder auf dem LinuxTag 2005 im Karlsruher Messe- und Kongresszentrum. Für nähere Details und den genauen Termin besuchen Sie bitte die LinuxTag Homepage.
EUROPAS GRÖSSTE GNU/LINUX MESSE UND KONFERENZ
KONFERENZ-DVD 2004
 Hauptseite   Vorträge   Bücher   History   Software   Knoppix   Sponsoren   Abspann   Impressum 
Hauptseite // Vorträge // Freiheit für Geodaten-Infrastrukturen - Die Umsetzung der Spezifikationen des Open GIS Consortiums mit Freier Software

Freiheit für Geodaten-Infrastrukturen - Die Umsetzung der Spezifikationen des Open GIS Consortiums mit Freier Software

Silke Reimer

Intevation GmbH
Dieser Beitrag ist lizensiert unter der GNU Free Documentation License.

June 2004

Abstract

Die GIS-Bestände in den öffentlichen Verwaltungen und in Unternehmen sind über viele Jahre hinweg heterogen gewachsen. Unterschiedliche Strukturen und Datenformate in verschiedenen Abteilungen, Kommunen etc. erschweren den Austausch und die Vernetzung der Geodaten.

Die Lösung: Eine Zwischenschicht mit den Schnittstellen-Standards des Open GIS Consortiums (OGC) erlaubt einer Anwendungsschicht einen einheitlichen Zugriff auf heterogene Datenbestände.

Der Vortrag stellt dar, dass unter GNU/Linux mit Freier Software eine elegante Realisierung für standardisierten Datenaustausch möglich und leistungsfähig ist.

Der Vortrag beginnt mit theoretischen Überlegungen zur Klärung des Begriffs der Geodaten-Infrastruktur. Danach werden die wichtigsten Spezifikationen des OGC im Überblick vorgestellt. Ziel dieser Spezifikationen ist es, Schnittstellen zu definieren, die den Austausch von Geodaten, deren Darstellung in Form von Karten und Metadaten unabhängig von den eingesetzten Software-Komponenten ermöglichen. Damit wird der Aufbau von Geodaten-Infrastrukturen auch in heterogenen Umgebungen möglich.

Im zweiten Teil des Vortrages werden zunächst diejenigen Freie Software Komponenten unter GNU/Linux vorgestellt, die einige oder alle OGC-Spezifikationen umsetzen. Ein Schwerpunkt wird dabei auf Software gelegt, die Austausch-Dienste bereit stellt (Server-Seite), während die Anwendungssoftware eher im Überblick dargestellt wird. Dabei erhält die Vorstellung des Deegree-Projektes ein besonderes Gewicht. Ziel dieses Projektes ist es, alle Spezifikationen des OGC zu implementieren. Deegree ist die umfassendste Freie Software für den Einsatz in Geodaten-Infrastrukturen.

Die gewonnenen Erkenntnisse werden anhand von Beispielen aus der Praxis veranschaulicht. Damit soll die Praxistauglichkeit der OGC-Spezifikationen aufgezeigt werden. Gleichzeitig wird damit der Stand und die Leistungsfähigkeit von Freier Software auf GNU/Linux-Basis im professionellen Einsatz demonstriert. Anhand der Beispiele soll aber auch gezeigt werden, wo die Grenzen der Anwendbarkeit von OGC-Spezifikationen unabhängig von der gewählten Software liegen


Geodaten-Infrastrukturen

Problemstellung

Die Anfänge von Geographischen Informationssysteme gehen zurück in die späten 70er und frühen 80er Jahre. Zu diesem Zeitpunkt machte die technologische Entwicklung es möglich, geographische Informationen, die bisher nur in Form von analogen Karten vorhanden waren, digital zu erfassen, zu verarbeiten und zu visualisieren. Dies sind die primären Aufgaben eines geographischen Informationssystems (GIS). Die Arbeit mit einem GIS war lange Jahre die Aufgabe eines Spezialisten mit einem speziell eingerichteten Arbeitsplatz.

Die heutigen System erleichtern außerdem dem Benutzer das Arbeiten mit den Daten, so dass für einfach Aufgaben auch ein gering geschulter Mitarbeiter mit den Geodaten arbeiten kann. Gleichzeitig hat die Bedeutung der Visualisierung und Analyse von digitalen Geodaten zugenommen. Schätzungen zufolge basieren 80 \% aller Entscheidungen im öffentlichen kommunalen Bereich auf Daten mit räumlichen Bezug. Der Bedarf an geographischen Daten ist also hoch, während gleichzeitig immer mehr Geodaten digital vorliegen. Die Anbieter solcher Geoinformationen zusammen zu bringen mit den Nutzern dieser Informationen ist Aufgabe einer Geodaten-Infrastruktur. Schwierigkeiten bereitet dabei die Tatsache das sich im Laufe der Jahre sich eine Vielzahl unterschiedlicher geographischer Informationssysteme entwickelt hat. Die meisten von ihnen verwenden ein eigenes proprietäres Datenformat. Die Strukturen, die aufgebaut werden sollen, müssen also mit oft sehr heterogenen Datenbeständen arbeiten und unterschiedliche Software-Architekturen miteinander in Einklang bringen.

Versuch einer Definition

Eine "Geodaten-Infrastruktur" (GDI) hat wie bereits erwähnt zum Ziel, das Angebot an Geoinformationen und Geodiensten systematisch für die Nutzern zugänglich zu machen. Dabei müssen nicht nur technische Aspekte berücksichtigt werden. Bedeutung erhalten insbesondere auch organisatorische und rechtliche Regelungen, die zum Aufbau einer GDI erforderlich sind. Das "GSDI Cookbook" (GSDI = "Global Spatial Data Infrastructure") beschreibt daher den Begriff "Geodaten-Infrastruktur wie folgt:

 

The term "Spatial Data Infrastructure" (SDI) is often used to denote the relevant base collection of technologies, policies and institutional arrangements that facilitate the availability of and access to spatial data. The SDI provied a basis for spatial data discovery, evaluation, and application for users and providers within all levels of gevernment, the commercial sector, the non-profit sector, academia and by citizens in general.

 
-- GSDI Cookbook, Version 1.1, 15 May 2001, Page8  

Der Begriff "Instrastruktur" wird bewusst verwendet, um Assoziationen zu anderen Infrastrukturen etwa aus dem Bereich der Telekommunikation herzustellen. Das GSDI Cookbook schreibt dazu:

 

The word infrastructure is used to promote the concept of a reliable, supporting environment, analogous to a roador telecommunications network, that, in this case, facilitates the access to geographically-related information using a minimum set of standard practices, protocols, and specifications. [...], like roads and wires, an SDI facilitates the conveyance of virtually unlimited packages of geographic information.

 
-- GSDI Cookbook, Version 1.1, 15 May 2001, Page8  

Eine weitere interessant Definition findet sich im Geoinformatik-Service der Uni Rostock, das online verfügbar ist.

 

[Eine] Geodaten-Infrastruktur ist dem Sinne nach vergleichbar zu anderen Infrastrukturen wie z.B. dem Verkehrsnetz. GDI ist eine aus technischen, organisatorischen und rechtlichen Regelungen bestehende Bündelung von Geoinformationsressourcen, in der Anbieter von Geodatendiensten mit Nachfragern solcher Dienste kooperieren. Sie besteht aus einem raumbezogenen Rahmenwerk, welches grundlegende Geometrien mit fachlichen Thematiken kombiniert, die von allgemeinem Interesse sind. Der Anwender nutzt diese Dateninfrastruktur und fügt seine speziellen Anwenderdaten hinzu. Er integriert und synchronisiert somit seine Datenbestände mit der Dateninfrastruktur. Bestandteile einer Geodateninfrastruktur sind die Geodatenbasis (z.B. Geobasisdaten und Geofachdaten) und deren Metadaten, ein Geoinformationsnetzwerk, Dienste und Standards. Die GDI schafft die Voraussetzung für die Wertschöpfung durch viele Nutzer in Verwaltungen sowie im kommerziellen und nichtkommerziellen Bereich. Auf ihr können sich neue Services entwickeln. Man muss also davon ausgehen, dass sich in GDI komplexe Produktionsketten etablieren werden. Informationsanbieter und Informationsnutzer treten nicht mehr direkt miteinander in Verbindung, sondern bedienen sich möglicherweise gestufter Services zur Identifikation und Aufbereitung der gewünschten Informationsprodukte. Zahlreiche Initiativen zum Aufbau solcher Geodateninfrastrukturen entstehen national und international durch staatliche, aber auch durch private Einrichtungen..

 
-- Geoinformatik-Service der Uni Rostock  

Diese Definition legt den Schwerpunkt auf die Nutzung der GDI durch die verschiedenen Nachfrager von GDI. Damit beschreibt diese Definition einen weiteren wichtigen Aspekt von Geodateninfrastrukturen: Der Aufbau einer GDI ist zu sehen als eine Grundlage für den Aufbau von Wertschöpfungsketten. Eine GDI bildet also die Grundlage für eine Reihe von schon möglichen oder noch zu entwickelnden Anwendungen, die auf den bereitgestellten Diensten aufgebaut werden können. Ich werde im Verlauf dieses Artikels noch einmal auf diesen Aspekt zu sprechen kommen.

Das Open GIS Consortium

Das Open GIS Consortium (OGC) wurde 1994 mit dem Ziel gegründet, Konzepte zu entwickeln, die den Austausch von geographischen Informationen auch in heterogenen Umgebungen ermöglichen. Der Bedarf für eine solche Organisation hatte sich daraus ergeben, dass u.a. in US amerikanischen Regierungsbehörden ein wachsende Anzahl von (vor allem) proprietären Produkten eingesetzt wurde, deren Interoperabilität meist nicht gegeben war. Um trotzdem geographische Daten Behörden übergreifend nutzen zu können, war die Entwicklung von entsprechenden Strategien notwendig.

Heute hat das OGC 256 Mitglieder, darunter Firmen, Regierungsbehörden und Universitäten. Die Hauptaktivitäten des OGC bestehen aus der Entwicklung von Interface Spezifikationen. Jede dieser Spezifikation beschreibt einen Aspekt der Verarbeitung, Bereitstellung oder Anforderung von geographischen Daten. Im nächsten Kapitel werden diese Spezifikationen im Hinblick auf den Aufbau einer GDI etwas genauer behandelt.

Eine wichtige Aufgabe erfüllt das OGC durch das so genannte "Interoperability Programms". Ziel dieses Programms ist es, die OpenGIS Spezifikation in Pilot-Projekten in der Praxis zu erproben und zu demonstrieren. Außerdem werden für einzelne bereits erprobte Spezifikationen Konformitätstests entwickelt. Damit kann eine Implementation einer OpenGIS Spezifikation ein offizielles Label zu erhalten, das seine Standard-Konformität belegt.

Open Source vs. Open GIS

Das OGC spricht auf seinen Seiten in der Regel von "kommerziellen" Produkten, wenn es Produkte meint, die nicht als Freie Software im Sinne der FSF zur Verfügung stehen. In diesem Artikel wird statt dessen der Begriff "proprietär" verwendet. Damit wird der Tatsache Rechnung getragen, dass auch Freie Software bzw. Open Source Software kommerziell verwertet werden können. Statt "offener Software" wird der Begriff "Freie Software" im Sinne der FSF (http://www.fsf.org/philosophy/free-sw.html) verwendet. Eine andere Möglichkeit ist die Verwendung des Bezeichnung "Open Source Software" im Sinne der Definition durch die Open Source Initiative (OSI) (http://www.opensource.org/docs/definition.php).

Neben der Verwendung des Begriffes "kommerziell" statt "proprietär" ist auch die Verwendung des Begriffes "open" mit verschiedenen Assoziationen belegt. Die Verwendung des Begriffs "Open" im Zusammenhang mit so genannter "Open Source Software" durch die Open Source Initiative (OSI) ist entstanden aus dem Versuch eine kommerziell besser verwertbare Bezeichnung für Freie Software zu haben. Auf die Detail in den Unterschieden soll an dieser Stelle nicht eingegangen werden, weil sie für den vorliegenden Artikel nur am Rande interessant sind. Mehr dazu z.B. auf den Seiten der FSF . Wichtig ist in dem vorliegenden Zusammenhang, dass Open Source Software im Sinne der OSI und Freie Software im Sinne der FSF technologisch quasi das selbe Konzept beschreiben.

Das OGC verwendet das Adjektiv "open" in zwei verschiedenen Zusammenhängen. Wenn es von "Offenen Produkten" schreibt, dann sind damit Produkte gemeint, die als Freie Software bzw. Open Source Software zur Verfügung stehen. Nicht zuletzt taucht das Adjektiv aber auch im Namen des Consortiums im Begriff "OpenGIS" auf. Das OGC bezieht sich damit auf sein Ziel, offene (open) Standards zum Austausch von Geoinformationen zu entwickeln. Damit hebt das OGC den Gegensatz zu den proprietären Geodaten-Formaten hervor, die oft nur von einem oder wenigen speziellen Produkten gelesen und geschrieben werden können. Insofern spielt auch hier der Gegensatz proprietär - frei eine gewisse Rolle.

Das Open GIS Consortium und Freie Software

Kritiker der Freie-Software-Bewegung werfen den Entwicklern Freier GIS-Software vor, die Begriffe bewusst zu vermischen.

 

[...]Der GIS-Markt wird durch den an der University of Minnesota (UMN) entwickelten OpenSource UMN MapServer und durch seine Derivate regelrecht aufgemischt. (Web-)GIS auf der Basis offener Programmcodes - eine Wunderwaffe? Man gaukelt uns gedankliche Verquickung mit OpenGIS vor.

Diese - bewusst konstruierte - Verwandtschaft der OpenSource-Welt existiert jedoch nicht - Etikettenschwindel par excellence! OpenGIS und OpenSource haben so wenig gemein wie Tag und Nacht. [...]

 
-- Lisa Kneipp, Kolumne der Geobit, März 2004  

Richtig ist natürlich, dass Open Source GIS Software bzw. Freie GIS Software nicht zwangsläufig eine Implementation der OpenGIS Spezifikationen darstellt. Genauso wenig werden Open GIS Spezifikationen immer als Open Source Software implementiert wird. Dies allerdings den Entwickeln von Freien Implementation der OpenGIS Spezifikationen anzulasten ist falsch. Die Autorin verkennt, dass es sich bei den beiden Konzepten um historisch völlig unterschiedlich gewachsene Begrifflichkeiten handelt, die in einem Spezialbereich - der Implementation von OpenGIS Spezifikationen als Freie Software - aufeinander treffen.

Interessanterweise sind die Begriffe OpenGIS und Open Source doch nicht so weit voneinander entfernt, wie es jetzt den Anschein haben mag. Immerhin ist es das Ziel der OpenGIS Spezifikationen, offene für jeden zugängliche Standards zu schaffen, die für jeden Anbieter eines GIS nutzbar sind. Konsequenterweise setzt daher das OGC bei der Wahl der Referenzimplemenation für spezielle Spezifikationen auf Entwicklungen auf Basis Freier Software. Für die Web Feature Service Spezifikation (Version 1.0) zum Austausch, Ändern und Löschen von Vektordaten ist das der unter der GPL stehende GeoServer. Das unter LGPL stehende Framework deegree stellt die Referenzimplementation der Web Map Service Spezifikation 1.1.1. Weiter Referenzimplementation gibt es zur Zeit nicht. Das OGC hat aber bereits zwei weitere Spezifikationen (Web Coverage Service (1.0) und Web Catalog Service (2.0)) als Implementation innerhalb des deegree Frameworks in Auftrag gegeben.

Die Diskussion soll abgeschlossen werden mit einer kleinen historischen Anekdote: Die Anfänge des OGC gehen nämlich zurück auf die Open GRASS Foundation. Dies Organisation hat ist aus der Community um das Freie-Software GIS GRASS hervorgegangen. Insofern liegen die historischen Wurzeln des OGC in gewissem Sinne tatsächlich in der Freie-Software Bewegung.

Web-basierte OpenGIS Spezifikationen und ihre Umsetzung mit Freier Software

Ein Teil der Spezifikation des OGC beschäftigen sich mit der Beschreibung von Geodaten. Zu ihnen gehört Simple Feature Modell des OGC, das definiert, wie Geometrien wie Punkte, Linien und Polygone aussehen. Daneben gibt die Spezifikation für GML (Geographic Markup Language), ein XML-basiertes Format zur Beschreibung von Vektor-Geodaten, d.h. Geometrien verknüpft mit Sachdaten. Diese Spezifikationen bilden zwar gewissermaßen die Grundlagen zum Austausch der Geodaten zwischen den Diensten einer Geodaten-Infrastruktur. Sie berühren ihren Aufbau jedoch nur am Rande, und werden daher hier nicht weiter behandelt.

Die webbasierten Spezifikationen des OGC haben sowohl in der Anzahl als auch in der Bedeutung ein großes Gewicht unter den Spezifikationen des OGC. Sie definieren eine Schnittstelle zwischen einem Dienst, der einen speziellen Aspekt an geographischen Informationen liefert, und einem Klienten, der auf diesen Dienst zugreift. Dieses Konzept entspricht dem Aufbau einer GDI, bei der zwischen den Anbietern von Diensten und deren Nutzern unterschieden wird.

Die Kommunikation zwischen Client und Server läuft über das HTTP-Protokoll. Die Kodierung der Anfragen geschieht, sofern es sich um POST-Anfragen handelt, in einem XML-kodierten Dokument. Auch die Antworten werden in der Regel in XML formuliert. Jeder Dienst muss auf eine sog. GetCapabilites-Anfrage reagieren können, mit dem die speziellen Eigenschaften des Dienstes abgefragt werden können. Daneben definiert jede Spezifikation weitere Anfragen, die je nach Dienst z.B. Metainformationen, Karten, Informationen zu einzelnen Objekten, Geodaten im Vektorformat, Geodaten im Rasterformat, 3D-Ansichten etc. zurück liefern. Die nachstehende Tabelle gibt einen Überblick über die wichtigsten webbasierten Spezifikationen.

Table 1.  Übersicht über die wichtigsten webbasierten OpenGIS Spezifikationen (aus der deegree Dokumentation )

Name Funktion
Web Map Service (WMS) Internetbasierte Erzeugung von Karten aus Raster- und Vektor-Daten. Die generierten Karten können mit jedem gängigen Web-Browser visualisiert werden.
Web Feature Service (WFS) Internetbasierter Zugriff auf Vektordaten, die als GML- 2.1.1 konform codierte XML Dokumente an einen Client geliefert werden und dort zur Weiterverarbeitung (z.B. in einem DesktopGIS) zur Verfügung stehen.
Web Coverage Service (WCS) Internetbasierter Zugriff auf Rasterdaten, die in einem gängigen Bildformat (TIFF, GIF, JPEG, BMP, PNM) an den Client geliefert werden und dort zur Weiterverarbeitung (z.B. in einem DesktopGIS) zur Verfügung stehen.
Web Catalog Service (WCAS) Internetbasierter Katalogdienst zur Verwaltung und Recherche von Daten- und Service-Metadaten. Ein Katalog ermöglicht das Auffinden von Daten und Diensten unter Verwendung von fachlichen und räumlichen Kriterien.
Web Gazetteer Service (WFS-G) Dienst zur Georeferenzierung von geographischen Entitäten über ihren Namen.
Web Terrain Service (WTS) Erzeugung von Karten aus 3D-Daten wie Stadtmodellen und digitalen Höhenmodellen. Die generierten Karten können wie beim WMS mit jedem gängigen WebBrowser visualisiert werden.
Web Coordinate Transformation Service (WCTS) Ein WCTS ermöglicht die internetbasierte Transformation von geographischen Koordinaten in ein anderes räumliches Referenzsystem.

Beispiele

Die beiden nächsten Beispiele sollen veranschaulichen, wie die Spezifikation des OGC eingesetzt werden können, um eine GDI aufzubauen.

Metadatenportale

Geodaten werden oft dezentral erfasst und verwaltet. Allerdings fehlt in der Regel der Überblick darüber, welche Daten zu welchen Bedingungen über wen zu bekommen sind. Dies galt und gilt auch für die Daten aus den Behörden des Bundes. Daher wird seit dem Jahre 2000 auf Beschluss des IMAGI (Interministerielle Ausschuss für Geoinformationswesen) ein Geodatenportal entwickelt, dass die Suche und Nutzung von Geodaten und Geodiensten aus Behörden des Bundes erleichtern soll.

Grundlage für die Metadatensuche bildet ein Web Catalog Service. Ein Web Map Service liefert die Karten anhand derer die Nutzer auf räumlich durch den Datenbestand navigieren können. Nachfolgende Abbildung zeigt einen Ausschnitt aus dem Suchfenster des Portals. Der Catalog Service und der Kartendienst sowie das Portal wurde unter Einsatz des deegree Frameworks entwickelt.

Darstellung von Karten

Ein Anwendungsbeispiel für den Nutzen von WMS-konformen Diensten für den Aufbau von Anwendungen zur interaktiven Darstellung von Karten im Internet stellt die Zusammenarbeit zwischen der Bezirksregierung Hannover und dem Landkreis Schaumburg dar. Die Bezirksregierung Hannover verwaltet Geobasisdaten (z.B. Topographische Karten) und stellt Geofachdaten (z.B. Naturschutzgebiete) bereit. Ein Teil dieser Daten stellt die Bezirksregierung Hannover dem Landkreis Schaumburg über einen WMS-Dienst zur Verfügung. Der Landkreis Schaumburg braucht damit die Daten nicht selber zu pflegen, sondern kann direkt auf die von der Bezirksregierung Hannover bereit gestellten Karten zugreifen.

Das nachfolgende Bild zeigt einen Ausschnitt aus einer Anwendung, die der Landkreis Schaumburg über seinen Server www.gis-im-weserbergland.de bereit stellt. Die Naturschutzgebiete und die Hintergrundkarte werden als Bildinformation vom der Bezirksregierung Hannover geholt. Darüber kann der Landkreis Schaumburg nun eigene Geodaten (z.B. Naturdenkmäler, die roten Punkte in der Karte) legen. Damit entsteht eine für den Betrachter interessante Verknüpfung von Informationen. Sowohl der WMS-Dienst als auch der Zugriff auf denselben wurden mit dem UMN MapServer umgesetzt.

OpenGIS-konformen Dienste mit Freier Software

Naturgemäß müssen die OpenGIS-konformen Dienste zunächst aufgebaut werden, bevor sie genutzt werden können. Daher werden die Freie-Software-Projekte, die zum Aufbau von solchen Diensten eingesetzt werden können, zuerst vorgestellt. Die nachfolgende soll einen Überblick über solche Projekte geben. Sie erhebt allerdings keinen Anspruch auf Vollständigkeit.

Table 2.  Übersicht über Freie-Software Produkte zum Aufbau von OGC-Diensten

Projekt OpenGIS Spezifikationen
deegree WMS, transaktionaler WFS, WCS, WCAS, WFS-G, WTS, WCTS
GeoServer transaktionaler WFS mit Lock, WMS
UMN MapServer WMS, Basis WFS
GeoTools WMS, andere (?)
basic-wms2.py WMS
seagis WCTS

deegree

Ohne zu übertreiben, kann man behaupten, dass deegree das Projekt ist, das die Spezifikationen des OGC am umfangreichsten implementiert hat. Dies gilt im Übrigen nicht nur im Vergleich zu den Freie-Software-Projekten. Auch im Feld der proprietären Produkte gibt es kaum eine Software, die die Spezifikationen des OGC so umfassend implementiert.

Dass dies so ist, liegt insbesondere an der geschichtlichen Entwicklung von deegree begründet. Im Gegensatz zu vielen anderen Projekten, die sich mit einer bereits bestehenden Implementation an die OpenGIS Spezifikationen angenähert haben, war es bei der Implementation von deegree von Beginn an das Ziel, die OpenGIS Spezifikationen möglichst umfassend zu implementieren. Diese Tatsache wird inzwischen auch vom OGC honoriert, so dass die Firma lat/lon, die hauptsächlich hinter dem deegree-Projekt steht, den Auftrag erhalten hat, die offizielle Referenzimplementation für die WMS-Spezifikation, Version 1.1.1 (schon umgesetzt) und für die WCS-Spezifikation (1.0) und WCAS-Spezifikation (2.0) (in Arbeit) zu erstellen.

GeoServer

Das Projekt GeoServer bildet mit der Implementation der WFS-Spezifikation (1.0) ebenfalls eine Referenzimplementation des OGC. Damit setzt der GeoServer nicht nur den Basis-WFS um (d.h. das Ausliefern von Vektor-Geodaten), sondern auch den optionalen transaktionalen WFS. Der bietet Möglichkeiten zum Eintragen, Ändern und Löschen von Geoobjekten. Darüber hinaus wird auch der ebenfalls optionale Locking-Mechanismus zum Sperren von einzelnen Geoobjekten für einen Verarbeitungsschritt implementiert. Mit diesem Locking-Mechanismus enthält der GeoServer eine Funktionalität, die selbst der deegree-Server zur Zeit (noch) nicht umsetzt.

UMN MapServer

Der UMN MapServer hat eine andere historische Entwicklung als deegree oder der GeoServer. Die Anfänge reichen zurück in die frühen 90er Jahre. Das Ziel des UMN MapServers war es von Beginn an, webbasierte Anwendungen mit räumlichen Bezug entwickeln zu können. Die Server-Komponente des UMN MapServer ist daher darauf optimiert, z.T. sehr große Datenbestände aus unterschiedlichen Formaten performant einzulesen und in Form von Karten an den Klienten zu liefern. Der UMN MapServer ist ein einfaches CGI-Skript, dass entweder direkt oder mit Hilfe von Skript-Sprachen (PHP, Perl, Python, Ruby,...) angesprochen werden kann (mehr dazu im Abschnitt über die webbasierten Klienten).

Im Laufe der letzten Jahre ist der UMN MapServer um die Implementation von einigen OpenGIS Spezifikationen erweitert worden. Gemäß seiner Aufgabe, Karten auszuliefern, wurde der UMN MapServer zunächst um eine WMS-Server-Komponente erweitert sowie der Möglichkeit einige WMS-Dienste als Datenquelle einzubinden. Seit knapp einem Jahr kann der UMN MapServer auch als Basis-WFS-Server eingerichtet werden und WFS-Dienste einbinden. Geplant ist außerdem die Erweiterung um die WCS-Spezifikation. Eine Transaktionale-WFS-Komponente ist in näherer Zukunft jedoch nicht zu erwarten, da diese Erweiterung eine umfassende Änderung der Architektur des UMN MapServer erfordern würde.

OpenGIS-konformen Klienten mit Freier Software

Die im letzten Abschnitt beschriebenen webbasierten Dienste stellen sozusagen die Anbieterseite einer Geodaten-Infrastruktur dar. Das Vorhandensein dieser Infrastruktur ermöglicht den Aufbau von Wertschöpfungsketten auf den Diensten. Dazu werden spezielle Informationen von den Diensten abgefragt und von einer Anwendung entweder direkt verarbeitet oder mit weiteren Informationen verknüpft. Dabei können auch die Informationen von verschiedenen Diensten miteinander kombiniert werden.

Aufgabe eines Klienten für einen OpenGIS-konformen Dienst ist es also, zum einen die Anfragen, mit denen die Informationen des Dienstes geholt werden können, zu formulieren und zum anderen die Antworten des Dienste zu interpretieren und je nach Anwendung darzustellen oder zu bearbeiten. Ein Klient bzw. ein Portal oder eine Anwendung, die auf einem oder mehreren OpenGIS-konformen Diensten beruht, ist nicht so sehr darüber definiert, welche Dienste er anspricht, sondern darüber, welche Funktionen für den Benutzer damit möglich werden. Ein transaktionaler WFS-Service kann z.B. einerseits genutzt werden, um Geodaten an Klienten auszuliefern, aber auch, um komplizierte Digitalisierungsanwendungen darauf aufzubauen. Der Dienst ist in diesem Fall der gleiche, die Anwendungen aber völlig unterschiedlich.

In den nun folgenden Abschnitten wird versucht, einen Überblick darüber zu geben, welche Möglichkeiten es gibt, Anwendungen auf Basis Freier Software zu entwickeln, die auf OpenGIS-konforme Dienste zugreifen können. Dabei erhebt auch diese Auflistung keinen Anspruch auf Vollständigkeit.

deegree

Das deegree-Projekt realisiert nicht nur den Aufbau von Diensten sondern entwickelt zunehmend Portale, die auf diesen Diensten aufbauen. Derzeitig sind innerhalb des deegree Frameworks ein Klient zum Darstellen von Karten (auf WMS aufbauend) ein Portal für einen Metadatendienst (auf WCAS aufbauend), ein Portal zum Ausliefern von Vektordaten (WFS-basiert) sowie ein Portal zur textuellen Suche (WFS-Gazetteer-basiert) realisiert.

Technologisch basieren die Portale auf Java Server Pages. Die Anwendungsschicht wird also als serverseitige Anwendung installiert. Der Nutzer greift mit einem Standard-Web-Browser darauf zu und bekommt HTML-Seiten mit JavaScript als Oberfläche geliefert.

UMN MapServer

Der UMN MapServer kann so konfiguriert werden, dass eine Datenquelle ein WMS- oder ein WFS-Server ist. Zusammen mit den flexiblen Möglichkeiten des UMN MapServers, webbasierte Anwendungen zur Darstellung von interaktiven Karten zu entwickeln, stellt der UMN MapServer damit ein hervorragendes Framework dar, angepasste WMS-Klienten und WFS-Klienten zu entwickeln. Gerade die Möglichkeiten, die sich daraus ergeben, dass die CGI-Komponente des UMN MapServers über Skriptsprachen angesprochen werden kann, hat einige Projekte dazu animiert, Portale zur Nutzung von WMS-konformen Diensten zu entwickeln.

Chameleon und MapBender sind zwei Beispiele für solche Anwendungen. Beide nutzen den UMN MapServer zum Lesen der Karten von WMS-konformen Diensten und nutzen dazu die Skriptsprache PHP. Chameleon bietet nun die Möglichkeit, angepasste Anwendung zur Darstellung von interaktiven Karten darauf aufzubauen. MapBender stellt darüber hinaus eine Oberfläche zum Verwalten der verschiedenen Kartendienste bereit.

Der WMSAdapter ist hervorgegangen aus dem ZMapServer-Projekt . Der ZMapServer setzt ähnlich wie Chameleon und MapBender zum Einlesen der verschiedenen Geodaten auf den UMN MapServer, spricht ihn aber nicht über die Skriptsprache PHP sondern über Python an. Damit wird eine Verknüpfung mit dem in Python implementieren Web-Application-Framework Zope möglich. Der WMSAdapter ist eine Zope-Erweiterung (ein sog. Zope Produkt), die das das Ansprechen von WMS-konformen Kartendiensten ermöglicht. Deren Antworten können dann Zope-basierten Anwendungen weiter verarbeitet werden können.

Wie bereits erwähnt bietet der UMN MapServer auch die Möglichkeit, WFS-konforme Dienste als Datenquelle einzubinden. Diese Fähigkeit wird auch bereits in Projekten eingesetzt. Allerdings wird es wahrscheinlich noch eine Weile dauern, bis sich daraus standardisierte Produkte entwickeln. Das Projekt Chameleon kann diese Fähigkeit ebenfalls nutzen. Wann und ob der MapBender um die Verwaltung von WFS-basierten Ebenen erweitert wird ist nicht bekannt. Durch die Verwendung der Bibliothek PyOGCLib (s. nächster Abschnitt) ist damit zu rechnen, dass ein dem WMSAdapter ähnlicher WFSAdapter früher oder später ebenfalls entwickelt wird.

Bibliotheken

Während die Verarbeitung der Antworten eines auf einer OpenGIS-Spezifikationen basierenden Dienstes abhängig ist vom Anwendungsfall, folgen doch die Abfragen, die an einen solchen Dienst gestellt werden, immer dem gleichen Schema. Das Erzeugen dieser Anfragen lässt sich daher sehr gut in eine Bibliothek auslagern, die dann von einer Anwendung genutzt werden kann.

Bisher ist die Entwicklung von Bibliotheken relativ wenig voran geschritten. Das mag zum einen daran liegen, dass erst allmählich Dienste aufgebaut werden, auf die sinnvollerweise zugegriffen werden kann. Daher entsteht auch erst jetzt zunehmend der Bedarf, Bibliotheken zu entwickeln, die auf diese Dienste zugreifen. Außerdem zeigt der vorangegangen Abschnitt über den UMN MapServer, dass zumindest für Klienten auf WMS-konformen Kartendiensten, die vom UMN MapServer-Projekt bereit gestellten Mittel in der Regel ausreichen, um Klienten zu entwickeln.

Interessanterweise ist trotzdem gerade aus dem UMN MapServer basierten Projekt ZMapServer die Bibliothek PyOGCLib entstanden. Genauso wie das Produkt ZMapServer ist PyOGCLib in Python implementiert. Derzeit kann man mit PyOGCLib auf WMS- und WFS-konforme Dienste zugreifen.

Desktop-Lösungen - Thuban

Wie die voran gegangenen Abschnitte zeigen, realisieren die meisten Projekte eine serverseitige Anwendungsschicht, auf die mit einem normalen Web-Browser zugegriffen werden kann. Die Verwendung eines Desktop-basierten Klienten ermöglicht eine zusätzliche Wertschöpfung. So kann man z.B. zu einer Karte, die über WMS bezogen worden ist, leicht weitere nur lokal vorhandene Geodaten anzeigen lassen. Damit lassen sich visuelle Überlagerungen darstellen, die sich webbasiert nicht umsetzen lassen. Auch die Nutzung von WFS-konformen Diensten kann viel intensiver erfolgen, als es mit webbasierten Klienten der Fall ist, weil dem Nutzer in der Regel mehr Funktionen zur Verfügung stehen.

Thuban ist eine Desktop-basierte Anwendung, die den Zugriff auf WMS-konforme Dienste ermöglicht. Thuban ist entstanden als einfacher Geodatenbetrachter für Raster- und Vektordaten. Dabei ist Thuban so konzipiert worden, dass sich leicht komplexe auf spezielle Workflows angepasste Anwendungen auf Basis von Thuban entwickeln lassen. Die Anbindung von WMS-Diensten als Datenquelle des komplett in Python geschriebenen Thuban basiert auf der Bibliothek PyOGCLib . Die experimentelle Umsetzung ist bereits seit längerem erfolgt. Derzeit wird die WMS-Anbindung im Rahmen eines Studienprojektes auf eine breitere Basis gestellt. Der aktuelle Stand (Anfang Mai 2004) ist, dass die internen Prozesse zur Anbindung an WMS-Dienst komplett umgesetzt sind. Sie werden im nun folgenden Schritt an die GUI angebunden.

Noch ein Beispiel - Standard-konforme Digitalisierung

Im kommunalen Bereich ist oftmals die Erfassung von einfachen Geoobjekten durch eine Reihe von Mitarbeitern erforderlich (z.B. Spielplätze, Baustellen o.ä.). Der Einsatz einer hoch komplexen Digitalisierungsanwendung ist dazu meist nicht nötig und u.U. sogar hinderlich, weil sie auf jedem Arbeitsplatz installiert werden muss und eine intensive Schulung der Mitarbeiter erfordert.

Abhilfe schafft da eine webbasierte Anwendung, die nur die notwendigen Funktionalitäten zum Erfassen der einfachen Objekte enthält und über einen Standard-Web-Browser zugänglich ist. Für die Bezirksregierungen in Niedersachsen wurde eine solche Anwendung im Rahmen eines Pilotprojektes auf Basis eines transaktionalen WFS-Dienstes realisiert. Die Verwendung des WFS-Standards zum Eintragen der Geodaten ermöglichte es, die Anwendungsschicht so zu entwickeln, dass sie unabhängig von der darunter liegenden Datenbasis ist. Damit konnten innerhalb des Projektes zwei verschiedene Geodatenbanken (PostGIS/PostgreSQL und ArcSDE/Microsoft-SQLServer) in die Entwicklung einbezogen werden.

Die nächste Abbildung veranschaulicht die Architektur des Systems. Das deegree Framework wurde eingesetzt um einen transaktionalen WFS-Dienst und einen WMS-Dienst einzurichten. Der UMN MapServer holt sich von diesen Diensten die notwendigen Daten zur Darstellung. Mit Hilfe des Web-Application-Frameworks Zope wurden die Anwendungskomponenten entwickelt, die das Übergeben der Daten an den WFS-Dienst realisieren.

Weiterführende Links zum Thema

  • Das GSDI-Cookbook hat nicht nur eine gute Definition für Geodaten-Infrastrukturen sondern beschreibt vor allem, was beim Aufbau einer GDI beachtet werden muss. Das Dokument richtet sich dabei weniger an die Techniker als an die Entscheider innerhalb einer Organisation.

  • Der Geoinformatik-Service der Universität Rostock ist eine gute Quelle für alle Themen rund um das Thema geographische Informationen, also weit über das Thema GDI hinaus gehend.

  • Auf den Seiten des OpenGIS Consortium kann man sich über alle Aspekte von OpenGIS informieren. Dort befindet sich z.B. ein interessanter Überblick über die geschichtliche Entwicklung des OGC. Außerdem kann man dort die aktuelle Spezifikationen nachlesen und sich über Freie und proprietäre Produkte informieren, die die Spezifikationen implementiert haben.

  • Auf den Seiten der Free Software Foundation und der Open Source Initiative finden sich mehr Informationen über die Begrifflichkeiten rund um Open Source und Freie Software.

  • Weitere Information zum Thema freie Geographische Informationssystem und freie Geodaten findet man auf der Heimatseite des FreeGIS Projektes.

  • Die im Artikel erwähnten Projekte können teilweise im Internet angeschaut werden. Dies gilt für das Metadatenportal des Bundes ebenso wie für die interaktiven Karten des Landkreises Schaumburg. Die webbasierte Digitalisierung ist nur im Intranet der Bezirksregierungen sichtbar. In nächster Zukunft wird die Firma Intevation allerdings einen Demoserver frei schalten, auf dem eine Beispielanwendung installiert ist.

 
Impressum // © 2004 LinuxTag e.V.