Eines der Kernargumente für eine Geodateninfrastruktur ist die Möglichkeit der sogenannten interoperablen Nutzung aller möglichen GDI-Komponenten. Doch was bedeutet der Begriff Interoperabilität eigentlich? Das Geodatenzugangsgesetz des Bundes sowie das Hessische Vermessungs- und Geoinformationsgesetz definieren den Begriff "Interoperabilität" als "die Kombinierbarkeit von Daten" beziehungsweise "die Kombinierbarkeit und Interaktionsfähigkeit verschiedener Systeme und Techniken unter Einhaltung gemeinsamer Standards". Übersetzt bedeutet das: Jede GDI-Komponente muss unabhängig von Server-Standorten, Datengrundlagen oder eingesetzter Software in ausnahmslos allen Fällen genutzt werden können - ähnlich wie bei Legosteinen, bei denen jedes Teil stets auf jedes andere passt.
Um Interoperabilität innerhalb einer GDI zu erreichen, müssen bestimmte Voraussetzungen erfüllt sein. Diese gilt es beim Aufbau einer Geodateninfrastruktur zu berücksichtigen.
So sind vor allem allgemeingültige Standards einzuhalten und eine diensteorientierte Architektur zu verwenden. Der englische Fachbegriff hierfür lautet "Service-oriented Architecture" - kurz: SOA.
Für die optimale Nutzung der Interoperabilität in einer GDI spielen der Einsatz und die Veröffentlichung von Metadaten ebenso eine Rolle wie die Etablierung eines einheitlichen Nutzerzugangs zur Geodateninfrastruktur in Form eines Geoportals.
Schauen wir uns den Fachbegriff "Service-oriented Architecture" einmal genauer an. Die diensteorientierte Architektur spielt bei einer GDI eine wichtige Rolle.
Diese Art des Aufbaus ist eine zentrale Voraussetzung dafür, dass innerhalb einer Geodateninfrastruktur unter anderem Interoperabilität und Skalierbarkeit [2] sowie eine hohe Performance [3] möglich sind.
Die Grafik erklärt die Funktionsweise einer SOA:
Ein Anbieter, auch "Service Provider" genannt, stellt seine webbasierten Dienste plattformübergreifend zur Verfügung und veröffentlicht die dazugehörigen Metadaten in einem Verzeichnis, dem sogenannten "Service Broker". Ein solches Verzeichnis ist ein Metadateninformationssystem in einem Geoportal. Der Nutzer, auch "Service Consumer" genannt, ist so in der Lage, die Dienste öffentlich zu finden und diese selbst zu nutzen - zum Beispiel indem er sie in seine eigene Geodatenanwendung einbindet.
Dieses Prinzip nennt man auch "Publish-Find-Bind-Muster".
Ein wichtiges Merkmal dieses Musters ist, dass hierbei über standardisierte Schnittstellen auf autonome Dienste zugegriffen wird.
Aus der Umsetzung des "Publish-Find-Bind-Musters" im Kontext einer diensteorientierten Architektur ergeben sich zahlreiche Vorteile:
Die darin arbeitenden Dienste sind plattformneutral - das heißt: Die Nutzung der Dienste ist unabhängig vom System, von dem aus der Nutzer auf sie zugreift.
Durch die Einhaltung einheitlicher Standards sind die Dienste interoperabel nutzbar - auch wenn diese von verschiedenen Anbietern kommen.
Außerdem können problemlos weitere Komponenten in eine GDI integriert werden.
So muss keine doppelte Datenerhebung und Datenhaltung vorgenommen werden, was Kosten einspart.
Ein weiterer Vorteil einer diensteorientierten Architektur ist, dass sie die Nutzung von Diensten gänzlich unabhängig davon macht, welche Software ein Datenanbieter zur Datenerhebung oder Datenpflege verwendet - der Austausch von Daten geschieht immer auf die gleiche standardisierte Weise.
Dank dieses autarken Zusammenspiels der einzelnen Komponenten bleiben auch die Dienste an sich voneinander unabhängig.
Die entscheidende Voraussetzung für die effiziente Nutzung einer diensteorientierten Architektur in einer GDI ist freilich das Vorliegen digitaler Geodaten. Diese werden auf einem sicheren Server abgelegt; der Zugriff auf die Daten findet dann über den dazugehörigen Dienst statt.
Der Begriff "Standards" ist uns im Zusammenhang mit einer GDI schon häufiger begegnet. Doch was genau sind eigentlich Standards?
Zunächst sollten wir eine Begriffsklärung vornehmen: Im GDI-Umfeld spricht man häufig von sogenannten "Normen" und "Spezifikationen". Ebenso wie das Wort Standards beschreiben all diese Begriffe die gleiche grundlegende Funktion: Es geht um ein Werkzeug zur Vereinheitlichung oder Regelung bestimmter Sachverhalte auf der Basis einheitlicher Vorgaben.
Diese Vorgaben werden von unterschiedlichen Gremien festgelegt, die dafür jeweils einen der oben genannten Begriffe verwenden.
Wer Komponenten einer GDI bereitstellen will, sollte wissen, welche Dokumente für ihn relevant und wo die verschiedenen Vorgaben niedergeschrieben sind. Sie werden entweder von Normungsgremien wie beispielsweise ISO [6] oder DIN [7] definiert oder kommen von Standardisierungsgremien wie etwa OGC [8] oder W3C [9]. In vielen Fällen arbeiten diese Gremien zusammen.
Ein Profil ...
Das Wort "Standards" wird im Folgenden als Oberbegriff für alle Standards,
Normen, Spezifikationen und Profile verwendet.
Und noch einen weiteren Begriff wollen wir einführen: das Wort "Profil". Ein Profil ist eine Ergänzung zu einem Standard. Diese Ergänzung enthält Präzisierungen oder beschreibt einen höheren Detailgrad eines Standards.
Aus Vereinfachungsgründen sprechen wir in den folgenden Minuten daher überbegrifflich von "Standards".
Werfen wir einen kurzen Blick auf die standard- und profilgebenden Gremien und Organisationen.
Im GDI-Umfeld kommen verschiedene Standards zum Einsatz - beispielsweise stammen sie von der International Organization for Standardization (ISO). Aber auch die GDI-Ebenen selbst sind der Ursprung zahlreicher Anforderungen: So geben beispielsweise INSPIRE, die GDI-Deutschland, die GDI-Hessen und auch die GDI-Südhessen eigene Vorgaben für Geodateninfrastrukturen heraus.
Viele der maßgeblichen Standards beim Umgang mit Geodaten kommen vom Open Geospatial Consortium (OGC).
Das Open Geospatial Consortium (OGC) [8] ist ein internationales Industriekonsortium mit über 400 aktiven Mitgliedern aus den Bereichen Industrie, Verwaltung und Universitäten. Das Konsortium verfasst Standards zur interoperablen Nutzung von Geodaten, die im Internet frei verfügbar und unentgeltlich einsehbar sind. Viele dieser Standards enthalten Vorgaben zu Diensten und deren Schnittstellen.
Das OGC war die erste Initiative ihrer Art, die sich für die Offenlegung von Schnittstellen im Geodaten-Bereich einsetzte.
Die Dienste nach OGC-Standards nennen sich "OGC Web Services", kurz: OWS.
Grundsätzlich können alle OGC Web Services über das aus dem Internet bekannte Hypertext Transfer Protocol (HTTP) angesprochen werden - entweder per GET-Methode, also als Anfrage (im Englischen "Request") per URL, oder mittel POST-Methode, also als Request per XML. Ein Zugriff via GET-Methode erfolgt über eine URL, der sogenannte Keyword Value Pairs (KVP) angehängt werden. Die URL beginnt standardmäßig mit http://. Danach folgen die Angabe des Host-Namens bzw. der IP-Adresse sowie nach einem Doppelpunkt schließlich die Angabe des dazugehörigen Standard-Ports - in unserem Beispiel die 8080. Der Port hängt von der Einstellung ab, die der Server, auf dem der Dienst läuft, vorgibt. Anschließend folgen der Pfad zum Dienst sowie ein vorerst abschließendes Fragezeichen. Daran werden noch die anfragespezifischen Parameter nach dem Schema "Parameterbezeichnung=Wert" angehängt. Aufeinanderfolgende Parameter werden mit einem "&" voneinander getrennt. Diese Parameter werden in den Spezifikationen des OGC beschrieben. Beispielsweise beschreibt der Parameter "SERVICE" die Art des Dienstes, während der Parameter "REQUEST" immer die konkrete Schnittstelle benennt, die angesprochen wird. Auf diese Weise kann jeder Internetbrowser auf einen OGC-Dienst zugreifen und Daten abfragen. Komfortabler ist es für den Nutzer jedoch, wenn beispielsweise ein Kartenviewer in einem Geoportal die Abfrage im Hintergrund erledigt und dann lediglich das Ergebnis präsentiert wird.
Das gängigste Beispiel für einen OGC Web Service ist der Web Map Service - kurz: WMS. Seine Aufgabe ist die Visualisierung von Geodaten. Dieser Kartendienst greift hierbei auf Geodatenbanken, auf Dateien - zum Beispiel Shapefiles - oder auf andere Web Services zu.
Stellt ein Nutzer, also ein Client [10], eine Anfrage an den WMS-Dienst, generiert dieser aus dem Datenbestand eine Antwort.
Die Anfragen, die ein Web Map Service bearbeiten kann, heißen:
Die Anfrage "GetFeatureInfo" ist optional, die meisten Web Map Services unterstützen diese Operation jedoch.
Unsere beispielhafte URL umfasst beim Aufruf des WMS-Dienstes also die übliche Form bis zum Fragezeichen, außerdem die Angabe des gewählten Service, also WMS, sowie die Art der Anfrage - in unserem Beispiel "GetCapabilities".
Bei anderen Operationen, zum Beispiel bei "GetMap"-Anfragen, ist das Anhängen weiterer Parameter in der URL notwendig.
Neben dem Web Map Service gibt es noch weitere Dienste nach OGC-Standards.
Der Web Feature Service (WFS) stellt dem Nutzer Vektordaten im GML-Format (Geography Markup Language) zur Verfügung, das unter anderem GIS-Analysen ermöglicht.
Eine Ausprägung des WFS ist der Geokodierungsdienst, der sogenannte Web Feature Service Gazetteer. Mit diesem können geografische Bezeichnungen wie beispielsweise Adressen in Koordinaten umgewandelt werden.
Ein weiterer Dienst nach OGC ist der Catalogue Service for the Web (CSW). Dieser ermöglicht die Bereitstellung von Metadaten zu Geodiensten, Geodaten sowie Anwendungen, zudem stellt er die Grundlage eines Metadateninformationssystems dar.
Weitere OGC-Standards entnehmen Sie bitte dem ergänzenden PDF-Dokument.
Das Open Geospatial Consortium arbeitet eng mit anderen Standardisierungsgremien zusammen - zum Beispiel mit der International Organization for Standardization, die die weltweit bekannten und rechtlich verbindlichen ISO-Normen herausgibt.
Innerhalb dieser Organisation gibt es zu unterschiedlichen Themenbereichen jeweils ein Technical Committee. Für den Bereich Geoinformation ist dies das Technical Committee 211 (ISO/TC 211). Es wurde im Jahr 1994 mit dem Ziel gegründet, Standards für alle Arten von Informationen, Methoden, Werkzeugen und Diensten mit Raumbezug zu erarbeiten.
Damit sollen die Verfügbarkeit, der Zugriff und der Austausch von Geoinformationen verbessert werden.
Die dazugehörigen ISO-Normen tragen Bezeichnungen, die aus jeweils fünf Ziffern bestehen und immer mit den Ziffern 191 beginnen.
Da sich die Ziele von OGC und ISO überschneiden, haben beide Seiten im Jahr 1999 einen Kooperationsvertrag geschlossen. Daraufhin übernahm das OGC einige ISO-Standards; gleichzeitig wurden manche OGC-Vorgaben zu rechtlich verbindlichen ISO-Normen.
Zwei ISO-Normen wollen wir im Folgenden näher vorstellen:
ISO 19115: Geographic information - Metadata
ISO 19119: Geographic information - Services
Die ISO-Norm 19115 beschäftigt sich mit Metadaten. In ihr werden ein Mindestumfang und die Kategorien für Metadaten definiert. Außerdem nimmt sie eine Unterscheidung zwischen verpflichtenden und optionalen Metadatenelementen vor.
Im Rahmen der erwähnten Kooperationsvereinbarung wurde die ISO-Norm 19115 vom OGC übernommen. Sie ist dort als Teil der abstrakten Spezifikation, als "Topic 11 - Metadata", wiederzufinden.
Die ISO-Norm 19119 definiert, wie Schnittstellen zu standardisieren sind, damit sie interoperabel eingesetzt werden können. Auch dieser Standard wurde vom OGC in die abstrakte Spezifikation übernommen und bildet dort das "Topic 12 - Service Architecture".
In Sachen GDI-Standards spielt auf europäischer Ebene vor allem INSPIRE eine Rolle. Wie wir bereits wissen, gibt es zur INSPIRE-Richtlinie rechtlich verbindliche Durchführungsbestimmungen, auf Englisch: "Implementing Rules".
Die Durchführungsbestimmungen beschäftigen sich jedoch nicht mit der konkreten Umsetzung, sondern beschreiben lediglich die Anforderungen, also was zu tun ist.
Für das Wie, also für die praktische Umsetzung, gibt es gesonderte Umsetzungsanleitungen (Englisch: "Technical Guidance"), die rechtlich allerdings nicht bindend sind.
In den meisten Fällen handelt es sich hierbei um Konkretisierungen vorhandener Standards, also um Profile.
Eine Ausnahme bilden die Datenspezifikationen. Diese wurden von thematischen Arbeitsgruppen ("Thematic Working Groups") innerhalb von INSPIRE eigens für die Geodatenthemen entwickelt und werden in den Anhängen I bis III der INSPIRE-Richtlinie aufgeführt.
Tiefergehende Informationen zu den INSPIRE-Durchführungsbestimmungen und den Umsetzungsanleitungen, auch am Beispiel von INSPIRE-Darstellungsdiensten, haben wir in einem PDF-Dokument für Sie zusammengefasst.
Auch auf den anderen GDI-Ebenen wurden die vorgegebenen Standards weiter ausgearbeitet und verfeinert. So können auf den Ebenen GDI-Deutschland, GDI-Hessen und GDI-Südhessen jeweils eigene weiterführende Standards oder Profile definiert werden.
Darüber hinaus wird in den sogenannten Architekturkonzepten der GDI- Deutschland und der GDI-Hessen auf andere Standards verwiesen.
Ein konkretes Beispiel für eigene ergänzende Standardisierungen sind die Pflichtenhefte der GDI-Südhessen.
Eines der zentralen Elemente in einer Geodateninfrastruktur sind Metadaten – also die beschreibenden Daten über Geodaten, Dienste und Anwendungen. Sie sind der Dreh- und Angelpunkt der gegenseitigen Datenbereitstellung.
Mithilfe von Metadaten beschreibt ein Datenanbieter seine Geodaten und Geodatendienste und macht diese Informationen dem Datennutzer in einem Geoportal zugänglich. Das Geoportal stellt dem Nutzer eine Oberfläche zur Suche zur Verfügung, mit deren Hilfe er die vorliegenden Metadaten finden und abfragen kann. Dieses Metadateninformationssystem (MIS) benötigt hierfür einen für den Nutzer meist verborgenen Katalogdienst.
Für die Veröffentlichung von Metadaten ist der Geodatenanbieter verantwortlich.
Sollen verteilt vorliegende Metadaten gefunden und dem Nutzer zur Verfügung gestellt werden, muss ein Metadateninformationssystem auf andere Katalogdienste zugreifen können. Die Metadatensätze der externen Kataloge werden dazu regelmäßig eingesammelt. Dieses Vorgehen bezeichnet man als "Harvesting". Dies geschieht über Schnittstelle des OGC Catalogue Service for the Web - CSW.
Nach dieser Methode kann beispielsweise ein europäisches Metadateninformationssystem die Kataloge der Mitgliedsstaaten abfragen. Der deutsche Katalog befragt dann die Kataloge der Bundesländer, und die Landeskataloge wiederum können auf weitere angeschlossene regionale Kataloge zugreifen.
Um Metadaten suchen zu können, benötigen diese einen möglichst einheitlichen Aufbau. Die Erfasser der Metadaten müssen sich also auf eine einheitliche Struktur und Semantik verständigen.
Zu diesem Zweck wurden verschiedene Metadaten-Standards entwickelt. Zu nennen sind hier zum Beispiel der internationale Standard ISO 19115 sowie die Metadaten-Verordnung der europäischen INSPIRE-Richtlinie, die zum Teil auf der ISO 19115 basiert.
Allerdings lassen einerseits die Standards selbst bisweilen Interpretationsspielräume offen, und andererseits gibt es leider nicht den einen Standard bzw. den einheitlichen Aufbau, auf den man sich weltweit verständigen könnte. Deshalb kann es passieren, dass scheinbar gleichbedeutende Elemente unterschiedlich interpretiert werden.
Diese Problematik hat ihre Ursache im Übrigen auch in der großen Vielfalt an Daten und Diensten, die in Metadaten beschrieben werden müssen.
Oft ist es daher sinnvoll, einen Erfassungsleitfaden anzubieten, der die einzelnen Elemente näher erläutert und es damit auch dem nichtspezialisierten Anwender ermöglicht, Metadaten aussagekräftig und korrekt zu erfassen.
Metadaten bereitzustellen, stellt eine organisatorische Herausforderung dar. Welche Aspekte zu klären sind, können Sie dem vertiefenden PDF-Dokument entnehmen.
Bei der Erfassung von Metadaten zu INSPIRE-Themen sind immer auch die INSPIRE-Metadatenverordnung, also die diesem Thema entsprechende Durchführungsbestimmung, sowie die dazugehörige technische Umsetzungsanleitung zu beachten.
Darin ist der strukturelle Aufbau von INSPIRE-relevanten Metadaten unter Berücksichtigung von ISO-Standards genau vorgegeben.
Um Metadaten schließlich über eine Anwendung durchsuchen zu können, braucht es Katalogdienste. Auch hierfür benötigt man wieder genaue Standards. Deshalb definiert INSPIRE den sogenannten Suchdienst.
Der darin spezifizierte Dienst unterstützt die Veröffentlichung von und die Suche nach Metadaten sowie die Verlinkung von Suchdiensten untereinander - auch "Kaskadierung" genannt. Es wird die Einhaltung des OGC-Standards für den Catalogue Service for the Web (CSW) vorgeschrieben.
Der Endanwender bekommt von dieser Komplexität glücklicherweise nichts mit. Zur Suche in Metadaten bedient er sich in der Regel eines Geoportals, das ihm hierfür ein Metadateninformationssystem zur Verfügung stellt.
Mehr zum Thema "Suchen von Metadaten in einem Geoportal" erfahren Sie im Info-Modul "Komponenten einer GDI".
Beim softwareseitigen Aufbau einer Geodateninfrastruktur muss man glücklicherweise nicht bei Null anfangen - stehen für die Erzeugung von Diensten doch viele Software-Produkte zur Verfügung. Dies bedingt jedoch, dass man die Qual der Wahl hat. Für welches Produkt man sich letztlich entscheidet, hängt von den individuellen Wünschen und Voraussetzungen ab.
Die folgenden Fragen bilden die wichtigsten Entscheidungskriterien: Über welche Datenquellen verfüge ich? Welches Know-how besitzen die zuständigen Mitarbeiter? Und vor allem: Welche finanziellen Mittel sind vorhanden?
Grundsätzlich kann bei den Software-Angeboten zwischen kommerziellen und Open-Source-Produkten unterschieden werden.
Weitere Informationen hierzu erhalten Sie in einem vertiefenden PDF-Dokument.
Beim Umgang mit sensiblen Daten spielt die Datensicherheit stets eine wichtige Rolle – erst recht, wenn der Zugriff auf diese Daten auf öffentlichem Weg, also über das Internet erfolgt. Neben den üblichen IT-Sicherheitsmaßnahmen - etwa redundante Server mit Lastverteilung, Virenscanner, Firewalls etc. - müssen auch die anwendungsspezifischen Sicherheitsaspekte in Geodateninfrastrukturen berücksichtigt werden. Diese sollen verhindern, dass ein Anwender, der die Daten über die vorgesehenen Schnittstellen nutzt, nicht irrtümlich oder gar mutwillig seine Rechte überschreitet.
Der lesende Zugriff
Drei Zeitpunkte sind sicherheitsrelevant:
vor dem Zugriff, während des Zugriffs und nach dem Zugriff.
Im typischen Anwendungsfall stellt der Nutzer eine Anfrage an einen Geodatendienst. Dabei erhält er einen einzelnen Lese-Zugriff auf die Geodaten. Dies ermöglicht dem Nutzer grundsätzlich das Anzeigen, womöglich sogar das Abspeichern und Ausdrucken von Geodaten.
Sicherheitsaspekte greifen hierbei in drei Phasen: in der Zeit vor dem Zugriff, in der Zeit während des Zugriffs und in der Zeit nach dem Zugriff.
Weitere Informationen sowohl zu den einzelnen Phasen als auch zu den Stichworten Integrität, Autorisierung und Zuordenbarkeit haben wir mitsamt den dazugehörigen Lösungsansätzen in einem separaten PDF-Dokument für Sie zusammengestellt.
Links:
[1] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_interoperabilitaet.pdf
[2] https://gdi-infotour.de/glossar#Skalierbarkeit
[3] https://gdi-infotour.de/glossar#Performance
[4] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_architektur.pdf
[5] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_digitale_geodaten.pdf
[6] https://gdi-infotour.de/glossar#International_Organization_for_Standardization_ISO
[7] https://gdi-infotour.de/glossar/#Deutsche_Institut_fr_Normung_DIN
[8] https://gdi-infotour.de/glossar#Open_Geospatial_Consortium_OGC
[9] https://gdi-infotour.de/glossar#World_Wide_Web_Consortium_W3C
[10] https://gdi-infotour.de/glossar#Client
[11] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_ogc.pdf
[12] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_ogc_0.pdf
[13] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_iso.pdf
[14] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_inspire.pdf
[15] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_metadaten.pdf
[16] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_metadaten_0.pdf
[17] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_software.pdf
[18] https://gdi-infotour.de/sites/default/files/pdf/vertiefende_info_sicherheit.pdf