Open Geospatial Consortium Web Services: Standards (nicht nur) für Karten im Web

Mapping-Anwendungen, Geosysteme und Positionsdaten sind allgegenwärtig und aus dem Alltag nicht mehr wegzudenken. Wie aber haben Geoinformationssysteme den Sprung aus der Nische in die massenhafte Verbreitung geschafft? Offene Standards und Interoperabilität heißen die Antworten.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 16 Min.
Von
  • Tobias Lütticke
Inhaltsverzeichnis

Mapping-Anwendungen, Geosysteme und Positionsdaten sind allgegenwärtig und aus dem Alltag nicht mehr wegzudenken. Google Maps und seine Integration in andere Anwendungen ist dabei nur ein Beispiel von vielen. Wie aber haben Geoinformationssysteme den Sprung aus der Nische in die massenhafte Verbreitung geschafft? Offene Standards und Interoperabilität heißen die Antworten.

Traditionelle Geoinformationssysteme (GIS) sind Desktop-Systeme, die Spezialisten bedienen. Google Maps hat die Navigation ins Web gebracht und sie so einem breiten Publikum erschlossen. Berührungsängste mit Landkarten sind ein Problem von gestern. So richtig abgehoben haben die Geoinformationssysteme für jedermann aber erst durch eine Kombination von Faktoren: der Boom mobiler Geräte, frei verfügbare Datensätze (Open Data), Zugang zu vormals internen GIS und das Web als Schnittstelle zwischen all diesen Bausteinen. Der Geo-Fortschrittsbericht (*.PDF) der Bundesregierung sagt sogar: "Geodateninfrastrukturen, und damit die Bereitstellung von Geoinformationen über standardisierte Internetdienste, sind somit ein Motor der Wissensgesellschaft im 21. Jahrhundert". Wie funktioniert aber die Kombination so verschiedener Werkzeuge und Techniken?

Die Schlüssel sind offene Standards und offene Schnittstellen. Nur sie ermöglichen die Verbindung von Web, Desktop und Mobile. Neue Angebote schießen wie Pilze aus dem Boden, weil sich existierende Bausteine flexibel zusammenfügen lassen.

Glücklicherweise gibt es das Open Geospatial Consortium (OGC), das als Standardisierungsgremium offene Schnittstellen und Standards definiert, um eine nahtlose Interaktion verschiedener Systeme zu ermöglichen. Eine Schlüsselkomponente sind die OGC Web Services (OWS). Auf Basis einer OGC- Referenzarchitektur bilden sie den gemeinsamen Nenner aller beteiligten Mitspieler im Geosegment und stellen Interoperabilität zwischen ihnen sicher. OWS nutzen SOAP (Simple Object Access Protocol) und REST (Representational State Transfer) zur Kommunikation und XML-Standardformate wie GML (Geography Markup Language) und KML (Keyhole Markup Language) zum Austausch von Daten. Das klassische GIS ist ein monolithisches Client-Server-System, manchmal sogar nur ein einzelner Client. Es besteht aus einer Desktop-Anwendung und einem Server, der sich um die Verwaltung der Geodaten kümmert und sie den verschiedenen Clients zur Verfügung stellt. Räumliche Berechnungs- und Analysevorgänge finden auf dem Client oder dem Server statt, wobei beide derselben Produktfamilie angehören. Mit etwas Glück sind die Geodaten unabhängig und liegen in einer separaten Geodatenbank. Daten zur Anzeige oder Analyse müssen importiert werden.

Ein GIS auf Basis von OWS hingegen ist durchweg modular aufgebaut. Alle Bausteine sind voneinander entkoppelt und unabhängig. Sie können durchaus von verschiedenen Herstellern stammen und Daten von externen Systemen beziehen, die sie dynamisch einbinden.

Im Vergleich zu einem traditionellen monolithischen GIS besteht ein modernes aus lose gekoppelten Komponenten, die über offene Schnittstellen kommunizieren (Abb. 1).


Solch ein modulares System hat eine Reihe von Vorteilen, manche allgemeiner Natur, manche GIS-spezifisch:

  • Einzelne Komponenten eines GIS lassen sich ohne große Brüche gegen andere austauschen, da sie Standardschnittstellen garantieren. Das wiederum vermeidet ein dauerhaftes Festlegen auf einen einzigen Hersteller oder ein bestimmtes Produkt.
  • Der modulare Aufbau unterstützt die Nutzung des jeweils besten Werkzeugs für eine bestimmte Aufgabe. Nicht alle Komponenten müssen aus einer Hand kommen. Häufig lässt sich so auf monolithische Desktop-Anwendungen verzichten, die Lizenzen erfordern und nur von Spezialisten bedienbar sind.
  • Standardformate für Daten machen den Austausch und die Wiederverwendung von Datensätzen einfach. Sie vermeiden komplexe Transformationen in andere Formate und das damit verbundene redundante Speichern oder häufige Umrechnen.
  • Daten lassen sich in ihrem Quellsystem pflegen. Ein Konsument bezieht die jeweils aktuellen Daten bei Bedarf dynamisch, ohne sie importieren und dauerhaft speichern zu müssen (auch wenn das in gewissen Fällen immer noch sinnvoll ist).
  • Offene Anwendungen können Dienste proprietärer Systeme konsumieren und umgekehrt, ohne dass sie sich um die jeweilige Technik kümmern müssen.

Die OGC Web Services, zusammen mit den Austauschformaten GML und KML, stellen Interoperabilität zwischen Systemen sicher. Proprietäre Produkte können so freie Dienste konsumieren oder ihrerseits Funktionen als Teil eines größeren Ganzen anbieten. Das öffnet GIS für Wiederverwendung.

Neben einem Referenzmodell definiert OGC auch eine Servicearchitektur für Geodienste. Sie gilt über Plattform- und Technikgrenzen hinweg und bildet den Rahmen für verteilte Geosysteme. Die so genannte Open Service Architecture hat die folgenden Ziele:

  • Alle Standards sollen auf einem allgemein anerkannten Konzept für zusammenarbeitende Geodienste basieren.
  • Die Abfrage von entfernten Geodaten und deren Verarbeitung soll über Geodienste erfolgen.
  • Daten sollen in unterschiedlichen Formaten und unterschiedlichen Quellen zur Verfügung stehen und zugreifbar sein.
  • Die Geodienste sollen unabhängig von speziellen Techniken funktionieren und Systeme auf verschiedenen Plattformen integrieren können.
  • Alle Dienstschnittstellen sollen offen sein, sodass die Verarbeitung von Geodaten flexibel über Systemgrenzen hinweg möglich und nicht auf einzelne Systeme beschränkt ist.

Das OGC verwaltet zwar eine Fülle von Standards, mit einigen ausgewählten OGC Web Services (OWS) lässt sich allerdings schon viel erreichen. Eine Schlüsselrolle kommt dem Geodatenserver zu, der räumliche Informationen aus einer Geodatenbank oder Bilddatenarchiven liest und sie Konsumenten durch OWS in einer verständlichen und weiterverwendbaren Form anbietet.

Im Überblick erfüllen die OWS die folgenden Funktionen:

Web Map Service (WMS): Ein WMS produziert statische Karten in Bildformaten wie GIF oder PNG. Dabei handelt es sich um georeferenzierte Bilder, die sich auch als Ebenen überblenden lassen. Die erste Ebene liefert etwa das Straßennetz und die zweite fügt Raststätten hinzu. Die Umsetzung von Daten im Format Längen-/Breitengrad in Bildern übernimmt ein Geodatenserver. Die am häufigsten benutzten WMS-Methoden sind GetCapabilities (befragt den Dienst nach seinen Fähigkeiten), GetMap (fordert eine Karte oder einen Kartenausschnitt an) und GetFeatureInfo (liefert Details zu einem bestimmten Kartenelement).

Web Feature Service (WFS): Ein WFS liefert einzelne räumliche Features in Form von Vektordaten, zum Beispiel Straßen, Seen, Grundstücksumrisse oder einzelne Punkte wie Sehenswürdigkeiten. Das Standardtransportformat ist der XML-Dialekt GML, andere Formate sind allerdings möglich. Während WMS Bilder ausschließlich zur Anzeige liefert, erlaubt das GML-Format die Weiterverarbeitung der Vektordaten. Eine WFS-Anfrage kann außerdem ein bestimmtes Feature erfragen, etwa das Polygon für einen See, während WMS alle Daten einer Ebene in ein Bild umwandelt. WFS kennt eine Variante mit Unterstützung für Transaktionen, WFS-T. Sie erlaubt Schreibzugriffe auf den Geodatenserver, um Features zu aktualisieren, zu löschen oder neue zu erzeugen. Die anderen typischen Methoden sind GetCapabilities, DescribeFeatureType (fragt nach Details eines bestimmten Feature Typs) und GetFeature (liefert ein bestimmtes Feature).

Web Coverage Service (WCS): Ein WCS greift auf Bilddatenarchive, auch Rasterdaten genannt, zu. Der WCS ist damit das Raster-Pendant zum WFS. Ein Client kann solche Daten entweder schlicht anzeigen oder weiterverarbeiten. Um die Verarbeitung zu unterstützen liefert eine WCS-Abfrage zusätzlich zu dem eigentlichen binären Ergebnis noch XML-Metainformationen. Außerdem erlaubt die flexible Anfragesyntax maßgeschneiderte Suchen.

Ein WCS unterscheidet sich von WMS dadurch, dass die Bilddaten zusammen mit Metadaten und in ihrer ursprünglichen Semantik zurückkommen, wohingegen ein WMS-Bild nur zur Anzeige gut ist. Im Gegensatz zu WFS, das sich auf bestimmte Features beschränkt, behandelt WCS eine breite Abdeckung räumlicher Daten. WCS kennt noch eine Reihe von Erweiterungen, von denen zwei wichtige WCS-T und Web Coverage Processing Service (WCPS) sind. WCS-T unterstützt Transaktionen und ermöglicht so Schreibzugriffe auf Rasterdatenarchive. WCPS wiederum integriert dynamisches Verarbeiten und Filtern in eine WCS-Abfrage. Die wichtigen WCS-Operationen sind GetCapabilities, DescribeCoverage (erfragt einen Satz an Rasterdaten, die den Suchparametern entsprechen) und GetCoverage (liefert einen bestimmten Rasterdatenbereich).

Web Processing Service (WPS): WPS ist ein Geodienst für geographische Berechnungen und räumliche Analyse von Geodaten. Clienten delegieren Aufgaben an ihn und erhalten Ergebnisse zurück. Ein WPS nimmt entweder Daten zur Verarbeitung vom Aufrufenden entgegen oder bezieht sie per URL aus einer Quelle. Dasselbe gilt für Berechnungsergebnisse: Der WPS gibt sie entweder direkt als Ergebnis des Serviceaufrufs zurück oder liefert als Rückgabewert eine URL, an die sich der Client zum Abholen wenden muss. Typische WPS-Methoden sind GetCapabilities, DescribeProcess (beschreibt die Funktion des Dienstes inkl. Eingabe- und Ausgabeparametern) und Execute (führt den Dienst aus und liefert Berechnungsergebnisse zurück).

Catalog Service for the Web (CSW): Als Katalogdienst hält ein CSW Metadaten für Geoanwendungen, Geodienste und Geodaten vor. Clients befragen ihn zum Beispiel, um herauszufinden, welche WMS/WFS-Dienste existieren und was ihr Fähigkeiten sind. Ein CSW liefert Abfrageergebnisse als XML.

Schaut man sich die Schnittstellen der OWS an, so stellt man eine wesentliche Gemeinsamkeit fest. Alle Dienste besitzen eine Operation namens GetCapabilities. Wenn aufgerufen, liefert sie eine Beschreibung des Dienstes zurück. Diese Metadaten beschreiben, welche Operationen der Dienst anbietet und geben Diensttyp, unterstützte Protokollversion, Namen des Dienstanbieters und einige weitere Details an.

Auf die eine oder andere Art und Weise arbeiten alle vorgestellten Geodienste mit Geodaten. Es sind zwar diverse Datenformate im Umlauf, die Geography Markup Language und die Keyhole Markup Language sind aber vorherrschend. GML ist ein offenes XML-Format zum Austausch geografischer Features und ihrer Eigenschaften. KML ist eine weitere XML-Notation, zielt aber im Unterschied zu GML auf die Visualisierung geografischer Daten. KML wurde ursprünglich von Google für Google Earth definiert, ist aber mittlerweile vom OGC als offener Standard übernommen worden.

Die standardisierten und ähnlichen Schnittstellen der OWS haben einen weiteren Vorteil: OWS-konforme Dienste lassen sich leicht verketten. Gibt es für einen bestimmten Anwendungsfall keinen geeigneten Web Processing Service, lassen sich zum Beispiel zwei oder drei existierende Dienste so verketten, dass sie das gewünschte Ergebnis liefern. Auch Geodienste unterschiedlichen Typs zu verbinden ist möglich. Ein Web Map Service muss seine Daten keineswegs direkt vom Geodatenserver beziehen, er kann auch einen Web Coverage Service anfragen. Serviceketten oder Servicekaskaden sind ein mächtiges Werkzeug, um aus verteilten Diensten eine leistungsfähige Gesamtlösung zu bilden.