Das Ziel dieser Arbeit ist die Lösungsfindung zur konformen Bereitstellung von Geodaten über Web Coverage Services innerhalb der GDI-MV. Es werden dabei verschiedene Softwarelösungen vorgestellt und mit den Anforderungen der GDI-MV verglichen. Des Weiteren gehört die Validierung sowie die anschließende Überwachung des Dienstes zu den Anforderungen als Geodaten-Dienstleister und ist folglich wichtiger Bestandteil der Qualitätssicherung.
Zunächst werden die für das Verständnis dieser Arbeit notwendigen rechtlichen Rahmenbedingungen und technischen Grundlagen zu Web Coverage Services, sowie weitere zum Einsatz kommenden Technologien vorgestellt. Die Vorgaben und Richtlinien von AdV, INSPIRE und OGC in Bezug auf die Bereitstellung werden vermittelt. Darüber hinaus wird das Konzept eines Web-GIS-Servers erläutert und die dazugehörigen Anforderungen formuliert. Anschließt lässt sich auf Grundlage dieser Anforderungen die Auswahl eines geeigneten Servers treffen. Der gewählte Server wird darauffolgend weiter erläutert. Es wird eingegangen auf Themen wie die Funktionen, die Installation, sowie auf die Konfiguration eines Web Coverage Services.
Nachfolgend werden verschiedene Verfahren zum Überprüfen bzw. zur Überwachung des bereitgestellten Dienstes vorgestellt und verglichen. Schließlich wird der Funktionsumfang der vorhandenen Softwarelösung durch eine individuelle Erweiterung weiter ausgebaut. Abschluss der Arbeit bildet ein zusammenfassendes Fazit und Ausblick auf zukünftiges bzw. weiteres Vorgehen im Rahmen des Einsatzes von WCS innerhalb des Unternehmens.
Inhaltsverzeichnis
1 Einleitung
1.1 Zielsetzung und Motivation
1.2 Aufbau der Arbeit
2 Technische Grundlagen
2.1 Web Coverage Service
2.1.1 WCS Core und Erweiterungen
2.1.2 Abfrageoperationen
2.2 Technische Standards und Normen
2.2.1 Geodateninfrastruktur
2.2.2 AdV Handlungsempfehlung
2.2.3 Open Geospatial Consortium
2.2.4 INSPIRE Richtlinien
2.2.5 Inkonsistenzen und Harmonierungsansätze
3 Bereitstellung
3.1 Geoinformationssysteme
3.2 Vergleich WebGIS-Server
3.2.1 Geoserver
3.2.2 MapServer
3.2.3 Rasdaman
3.2.4 QGIS-Server
3.3 Entscheidung
3.4 MapServer
3.4.1 Portabilität
3.4.2 Datenzugriff
3.4.3 Installation
3.4.4 Map-Datei
4 Validierung & Test
4.1 QGIS
4.2 GDI-DE-Testsuite
4.3 INSPIRE-Validator
5 Überwachung - Quality of Service
5.1 GDI-DE Testsuite
5.2 GeoHealthCheck
5.2.1 Architektur
5.2.2 Kernkonzept
5.2.3 Installation
5.2.4 Plugins
6 Verbesserungsmöglichkeiten
7 Zusammenfassung und Ausblick
7.1 Auswertung der Bereitstellung, Validierung & Überwachung
7.2 Ausblick
7.3 Fazit
8 Abbildungs- und Tabellenverzeichnis
9 Abkürzungsverzeichnis
10 Quellen- und Literaturverzeichnis
11 Anhang
1 Einleitung
1.1 Zielsetzung und Motivation
Der Einfluss von Geodaten auf Entscheidungen und Handlungen erstreckt sich über alle Ebenen der öffentlichen Verwaltung, der Wirtschaft, der Gesellschaft und der Wissenschaft.
Durch Handlungsempfehlungen der Arbeitsgemeinschaft der Vermessungsverwaltung (AdV) und des Rates zur „Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft” (INSPIRE) ist es für die Geodateninfrastrukturen gerade im Rahmen von Bund, Ländern und Kommunen notwendig geworden, Rasterdaten über standardisierte Downloaddienste interoperabel bereitzustellen. Die Bereitstellung kann über verschiedene Dienste erfolgen, wie Web Feature Services (WFS), Pre-defined Atom Feeds oder Web Coverage Services (WCS). WCS nehmen bzgl. ihrer umfangreichen Anwendbarkeit und Genauigkeit einen immer höheren Stellenwert ein. Beispielsweise wird bei der National Aeronautical and Space Administration (NASA) WCS genutzt, um Satellitenbilder zu analysieren.
Die „Handlungsempfehlung für INSPIRE WCS“ der Geodateninfrastruktur Deutschland (GDI-DE), die „Technical Guidance for the implementation of INSPIRE Download Services“ und die Vorgaben des Open Geospatial Consortium (OGC) dienen dabei als Orientierung zur Umsetzung des geforderten Dienstes. Für das Unternehmen ist es daher als Betreiber der Geodateninfrastruktur Mecklenburg-Vorpommern (GDI-MV) auch zur Aufgabe geworden, die Geodaten AdV und INSPIRE konform bereitzustellen.
Das Ziel dieser Arbeit ist die Lösungsfindung zur konformen Bereitstellung von Geodaten über Web Coverage Services innerhalb der GDI-MV. Es werden dabei verschiedene Softwarelösungen vorgestellt und mit den Anforderungen der GDI-MV verglichen. Des Weiteren gehört die Validierung sowie die anschließende Überwachung des Dienstes zu den Anforderungen als Geodaten-Dienstleister und ist folglich wichtiger Bestandteil der Qualitätssicherung.
1.2 Aufbau der Arbeit
Zunächst werden die für das Verständnis dieser Arbeit notwendigen rechtlichen Rahmenbedingungen und technischen Grundlagen zu Web Coverage Services, sowie weitere zum Einsatz kommenden Technologien vorgestellt. Die Vorgaben und Richtlinien von AdV, INSPIRE und OGC in Bezug auf die Bereitstellung werden vermittelt. Darüber hinaus wird das Konzept eines Web-GIS-Servers erläutert und die dazugehörigen Anforderungen formuliert. Anschließt lässt sich auf Grundlage dieser Anforderungen die Auswahl eines geeigneten Servers treffen. Der gewählte Server wird darauffolgend weiter erläutert. Es wird eingegangen auf Themen wie die Funktionen, die Installation, sowie auf die Konfiguration eines Web Coverage Services. Nachfolgend werden verschiedene Verfahren zum Überprüfen bzw. zur Überwachung des bereitgestellten Dienstes vorgestellt und verglichen. Schließlich wird der Funktionsumfang der vorhandenen Softwarelösung durch eine individuelle Erweiterung weiter ausgebaut. Abschluss der Arbeit bildet ein zusammenfassendes Fazit und Ausblick auf zukünftiges bzw. weiteres Vorgehen im Rahmen des Einsatzes von WCS innerhalb des Unternehmens.
2 Technische Grundlagen
In diesem Kapitel wird der Web Coverage Service sowie dessen technische Standards und Normen der verschiedenen Organisationen vorgestellt. Da das Ziel dieser Arbeit die Bereitstellung, Validierung und Überwachung eines WCS verfolgt, ist ein grundlegendes Verständnis zwingend erforderlich, um die Arbeitsweise und Funktionalitäten, sowie die Einsatzmöglichkeiten nachvollziehen zu können.
2.1 Web Coverage Service
Ein Web Coverage Service definiert eine durch das OGC standardisierte Schnittstelle, die den interoperablen Zugriff auf räumliche „Coverages“ ermöglicht. Rasterdaten, also Geodaten die flächig über ein Raster definiert sind, wobei an jedem Raster Informationen wie Farbe oder Höhe gespeichert werden können. In der Regel handelt es sich dabei um Geodaten wie Satellitenbilder, Luftbilder, Höhendaten oder andere Phänomene, die räumlich und/oder zeitlich variieren (multidimensionale Daten). Ein WCS liefert diese Daten mit ihrer vollen Semantik zurück, so dass diese optimal maschinell weiterverarbeitet werden können. [1]
Gerade Rasterdaten nehmen in ihrer Wichtigkeit immer mehr zu, indem sie für Gesellschaft und Wirtschaft unabdingbar werden. Coverages werden von der OGC und der internationalen Organisation für Normung (ISO) in den jeweiligen Standards als vereinheitlichendes Paradigma für räumlich-zeitliche, regelmäßige und unregelmäßige Gitter, Punktwolken, und allgemeine Netzte verwendet. Beide sind harmonisiert im Coverage Implementation Schema (CIS) und verwirklicht im Coverage-Dienstmodell. Der Hauptvorteil von Coveragedaten und Dienstleistungen ist es, dass die Durchführung von räumlich-zeitlichen Analysen in Kombination mit anderen Datenschichten (anderen Coverages) möglich ist. CIS mit WCS implementiert ist stark verbreitet und in der Praxis durchaus positiv bewertet. [2]
Die Daten können dabei sehr detailliert und reichhaltig sein. Neben der Visualisierung können mit dem WCS thematische Daten bereitgestellt werden, beispielsweise zur Verwendung in komplexen Klima- oder Überflutungssimulationen. [3]
Der WCS bietet dem Nutzer oder zur maschinellen Weiterverarbeitung verschiedene Operationen an, um die gewünschten Daten zurückzuliefern (siehe Abbildung 1).
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 - Grundlagen des Web Coverage Service
Per Hypertext Transfer Protocol (HTTP) kann über GET- und POST-Anfragen mit dem Dienstserver kommuniziert werden. Wenn Kartendienste in einem Geoinformationssystem (GIS) oder einem Onlineportal/Onlineviewer genutzt werden, so übernehmen diese Komponenten die Kommunikation mit dem Server. Steht kein GIS oder Viewer zur Verfügung, so kann der WCS auch über einen üblichen Web-Browser mit den in Kapitel 2.1.2 folgenden Abfrageoperationen angesprochen werden.
Coverages selbst werden wie eine Funktion modelliert. Sie beinhalten einen „domainSet“ und einen zugehörigen „rangeSet“. Um die volle Semantik der Werte erfassen zu können, wird ein „rangeType“ hinzugefügt, damit diverse Daten ohne Informationsverlust umwandelt und nahtlos analysiert werden können. Dieser basiert auf einem Sensor Web Enablement (SWE) Konzept. Anschließender gekürzter Codeauszug aus einer GetCoverage-Antwort zeigt wie die einzelnen Bestandteile beispielsweise eingesetzt werden.
<gmlcov:RectifiedGridCoverage gml:id= "mv_dgm" >
<gml:domainSet>
(Zuordnung von Dimensionen wie X, Y, Z oder T)
</gml:domainSet>
<gml:rangeSet>
(Beschreibung der Coverages, innerhalb der „domain“)
</gml:rangeSet>
<gmlcov:rangeType>
(Zuordnung von Variablen wie Farbe oder Temperatur)
</gmlcov:rangeType>
</gmlcov:RectifiedGridCoverage>
Außerdem kann ein optionaler Metadaten Teil in dem Coverage enthalten sein. Solche Coverages können in einer Vielzahl von Formen dargestellt werden, einschließlich Kacheln, Koordinaten/Wert-Paarlisten in Formaten wie GML (Geography Markup Language) oder JSON (JavaScript Object Notation), sowie einer Vielzahl von Binärdateien.
2.1.1 WCS Core und Erweiterungen
Der Web Coverage Service Core gibt einen Kernsatz von Anforderungen an, die eine WCS-Implementierung erfüllen muss, plus eine Reihe von Erweiterungen („Extensions“) mit zusätzlichen Dienst-Facetten. Bei der Implementierung kann gewählt werden, welche Erweiterung unterstützt werden soll. Nur einige grundlegende Regeln sind zu erfüllen: Jede WCS-Implementierung muss zumindest ein Kommunikationsprotokoll und ein Datenabgabe-Format unterstützen. Um den Überblick zu erleichtern, sind die Erweiterungen in fünf Kategorien gruppiert: Datenmodell (Data Model), Codierungen (Format Encoding), Servicemodell (Service), Protokolle (Protocol Binding) und Bedienbarkeit (siehe Abbildung 2). [4]
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2 - WCS Suite: Logical View [4]
Der WCS Core bietet grundlegende räumliche und zeitliche Datenextraktion. Dabei gibt es zwei Arten der Extraktion, die auch kombiniert werden können (siehe Abbildung 3):
- „Trimming“ extrahiert einen Ausschnitt einer Coverage, definiert durch einen Koordinatenbereich („Bounding Box“ bzw „BBOX“). Das Ergebnis hat die gleiche Dimension (d.h. die Anzahl der Achsen), wie der ursprüngliche Coverage.
- „Slicing“ führt einen Schnitt an der angegebenen Position durch und reduziert dadurch die Dimension der Ergebnis-Coverage.
Für WCS-Anfragen und Antworten können die folgenden Protokolle benutzen werden:
- GET / KVP : Benutzt HTTP GET für das Senden von Anfragen in Form von Schlüssel-Wert-Paaren (Key-Value pair) und empfängt XML-Metadaten und binäre Coverage-Daten.
- POST / XML : Benutzt HTTP POST für die Übertragung von XML-Daten und binärer Coverage-Daten.
- SOAP / XML : Benutzt SOAP für die Übertragung von XML-Daten und binärer Coverage-Daten.
- RESTful : Diese Protokoll-Variante ist derzeit in Entwicklung. [5]
2.1.2 Abfrageoperationen
Dieses Kapitel beschreibt die verschiedenen Abfrageoptionen des WCS, bzw. die entsprechenden Anfragen, die an den Server gestellt werden müssen. Die Funktionsweise des WCS wird so weiter verdeutlicht. Dieses Wissen ist wichtig um sowohl die Funktionsweise eines WCS zu verstehen, als auch erfolgreiche Anfragen an einen WCS über einen Web-Browser stellen zu können. Ebenfalls soll die Möglichkeit diese als Überwachungswerkzeug einzusetzen, sichtbar gemacht werden.
2.1.2.1 GetCapabilities
Mit Hilfe der GetCapabilities-Operation, welche von allen OGC-Web Services unterstützt wird, können die Fähigkeiten und Metadaten des Dienstes abgefragt werden. Der Aufruf setzt sich aus folgenden Parametern zusammen:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1 - WCS GetCapbilities-Aufruf Parameter
Der später bereitgestellte WCS „inspire_el_dgm_wcs“ hat folgende Web-Adresse:
https://www.geodaten-mv.de/dienste/inspire_el_dgm_wcs
Diese Adresse wird um die entsprechenden Parameter ergänzt. Dabei werden die einzelnen URL-Parameter (Uniform Resource Locator) durch ein „&“ miteinander verbunden und mit einem „?“ von der restlichen URL getrennt.
Ein gültiger GetCapabilties-Aufruf sieht dann wie folgt aus:
https://www.geodaten-mv.de/dienste/inspire_el_dgm_wcs?VERSION=2.0.1&SERVICE=WCS&REQUEST=GetCapabilities
Die Capabilities werden in Form eines XML-Dokumentes (Extensible Markup Language) zurückgeliefert, welches entweder direkt im Browser oder in einem Text-Bearbeitungsprogramm angezeigt oder von einem GIS oder Überwachungssystem ausgewertet werden kann. Die Capabilities enthalten alle relevanten Informationen, um einen Dienst anzufragen. Neben allgemeinen Angaben zum Dienst, wie Kurzbeschreibung, Ansprechpartner und Nutzungsbedingungen, befinden sich hier auch technische Details des Dienstes.
Die Capabilities geben einen Überblick über die unterstützten Abfrageformate, Interpolationsmethoden und verfügbare Coverages. Diese Informationen sind später notwendig, um eine gültige DescribeCoverage- oder GetCoverage-Anfrage zu stellen.
2.1.2.2 DescribeCoverage
Die Operation „DescribeCoverage“ ermöglicht die Abfrage zusätzlicher Informationen zu bestimmten Coverages. Ähnlich wie bei der Capabilities-Abfrage wird die Adresse des Dienstes um einige Parameter erweitert:
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2 - WCS DescribeCoverage-Aufruf Parameter
Ein gültiger DescribeCoverage-Aufruf sieht wie folgt aus:
https://www.geodaten-mv.de/dienste/inspire_el_dgm_wcs?VERSION=2.0.1&SERVICE=WCS&REQUEST=DescribeCoverage&COVERAGEID=mv_dgm
Die Antwort der DescribeCoverage-Anfrage wird, wie die Capabilities, als XML-Dokument zurückgeliefert. Sie enthält unter anderem Angaben zum Originalformat der Coverage-Daten, der raum-/ zeitlichen Ausdehnung und des zugrundeliegenden Koordinatenreferenzsystems. Bei mehrdimensionalen Daten werden Informationen zu den verfügbaren Bändern bzw. Kanälen bereitgestellt. Diese Angaben können wiederum helfen, thematisch genauere GetCoverage-Anfragen zu stellen.
2.1.2.3 GetCoverage
Die Operation „GetCoverage“ erlaubt den Aufruf von Coverage-Daten in einem bestimmten Format, wofür eine Vielzahl von Möglichkeiten und Parametern zur Verfügung stehen. Je nach angefragter Version unterscheiden sich diese Parameter. Im Folgenden werden die Paramater eines Aufrufs in der Version 2.0.1 vorgestellt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3 - WCS GetCoverage-Aufruf Parameter
Ein gültiger GetCoverage-Aufruf kann wie folgt aussehen:
https://www.geodaten-mv.de/dienste/inspire_el_dgm_wcs?VERSION=2.0.1&SERVICE=WCS&REQUEST=GetCoverage&COVERAGEID=mv_dgm&FORMAT=image/png&SUBSET=x(205999,207999)&SUBSET=y(5919999,5920999)
Der Parameter SCALEFACTOR ermöglicht eine Reduzierung der zurückgelieferten Bildgröße in Pixeln. Je nach gewünschtem Ausgabeformat kann das Ergebnis unterschiedliche Bildformate, Größen und Kompressionen aufweisen. Standardmäßig unterstützt der WCS die Formate TIFF (Tagged Image File Format), PNG (Portable Network Graphic), PNG (mode=8bit) und JPEG (Joint Photographic Experts Group). Lediglich das Format TIFF (GeoTiff oder image/tiff) liefert ein georeferenziertes Coverage zurück. Die Datengrundlage des Dienstes basiert in diesem Fall auf dem Koordinatenreferenzsystem EPSG:25833 kann aber variabel reprojiziert werden.
Das zugrundeliegende Datenformat kann den Angaben der DescribeCoverage-Anfrage entnommen werden. Zusätzliche Operationen zur Filterung und Verarbeitung von mehrdimensionalen Rasterdaten würde der Web Coverage Processing Service (WCPS) bieten.
2.2 Technische Standards und Normen
Für Web Coverage Services gibt es mehrere fachliche Standards und Normen. International gelten einzelne ISO-Normen, Spezifikationen der OGC und europäische Richtlinien von INSPIRE. Darüber hinaus spielt auch die Geodateninfrastruktur (GDI) eine entsprechende Rolle bei der allumfassenden konformen Bereitstellung des Dienstes. Der bereitgestellte Dienst muss zusätzlich zu diesen Richtlinien und Standards ebenfalls den Vorgaben der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland entsprechen. Daher wird zunächst auf nationale Regelungen von GDI und AdV eingegangen, danach auf geltende internationale Standards wie von dem OGC und erst im Anschluss auf aufbauende Standards bzw. Richtlinien von INSPIRE.
2.2.1 Geodateninfrastruktur
Der Geodateninfrastruktur obliegt die Koordinierung bzw. Strukturierung von Geodatendiensten und kann Auskunft über vielschichtige wirtschaftliche, soziale und ökologische Aspekte wie Katastrophenvorsorge, Wasserressourcen und Biodiversität geben. Eine Vereinheitlichung im Rahmen von Big-Data (komplexe große Datenbestände) und die vielseitige Nutzbarkeit ist somit erstrebenswert in der Erfassung geologisch bezogener Daten. [6]
Ziel der GDI ist es die Bereitstellung von Geodaten in einer webbasierten und auf Standards und Normen basierenden Infrastruktur. Die Verwendung von offenen Standards und genormten Schnittstellen ist folglich eine Grundvoraussetzung für die standardisierte Integration von Geodaten in allerlei Verwaltungsstrukturen, Prozessen und Diensten. Dabei besteht die GDI aus den Ebenen Bund (GDI-DE), Ländern (hier GDI-MV) und Kommunen (GDI-Kommune). Die Anforderungen und Empfehlungen der GDI bauen auf den Standards und Normen des OGC, sowie den ISO-Normen auf und finden Anlehung an die Umsetzung mit INSPIRE. Um Synergien bei der Entwicklung von Standards und technischen Komponenten zu nutzen und Mehrfachentwicklungen zu vermeiden, kooperiert die GDI-DE überdies mit anderen Normungs- und Standardisierungsgremien wie ISO, OGC, INSPIRE und mehr. [7]
Eine GDI besteht grundlegend aus Geodaten, einschließlich Metadaten zu deren Beschreibung, Geodatendiensten und Netzen (siehe Abbildung 5). Zu den Rahmenbedinungen gehören Rechtsnormen, Nutzungsreglungen, Koordinierungs- und Überwachungsmechanismen und Spezifikationen zur Interoperabilität.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5 - Komponenten und Rahmenbedingungen Geodateninfrastruktur [8]
Die grundlegende Architektur der GDI stellt folgende Grundsätze an Vorhaben und Dienste. Beim Entwurf und der Realisierung sollte auf die Wirtschaftlichkeit, die Interoperabilität, die Agilität, die Offenheit, die Sicherheit und die Wiederverwendbarkeit geachtet werden. [8]
Fachspezifische Umsetzungs- und Handlungsempfelungen werden im Rahmen von den jeweilig zuständigen Gremien, wie der AdV erarbeitet, um eine deutschlandweite einheitliche Umsetzung sicherzustellen. Der Umgang und die zugehörige GDI-DE Testsuite werden im weitern Verlauf der Arbeit bzw. im Rahmen der Vailidierung und Überwachung detailierter betrachtet.
2.2.2 AdV Handlungsempfehlung
In der Bundesrepublik Deutschland obliegt nach dem Grundgesetz in den Artikeln 30, 70 und 73 den Ländern die Verantwortung für das amtliche Landes- und Liegenschaftsvermessungswesen. [9]
Deshalb sind besondere Herausforderungen an die Zusammenarbeit von Bund und Ländern adressiert. Die AdV wurde gegründet, um fachliche Angelegenheiten von grundsätzlicher und überregionaler Bedeutung einheitlich für alle Bundesländer zu definieren. Zu den Aufgaben gehören u. a. die Erarbeitung von Empfehlungen und verbindlichen Regelungen für ein einheitliches Vorgehen bei der Schaffung, Erhaltung und Weiterentwicklung von Geobasisdaten. [10]
Um bundesweit einheitliche Produkte anzubieten, unterliegen die Dienste der AdV gewissen Standards. Diese sind in den AdV-Profilen und den AdV-Produkt-Spezifikationen zusammengefasst und bilden die technische Grundlage der Bereitstellung von Geobasisdaten über Geodatendienste und dienen Großteils dafür, den technischen Rahmen für die Dienste festzulegen. [11]
Die AdV hat allgemeine Anforderungen für die Bereitstellungen der Rasterdatenthemen aufgestellt. Darunter fallen u.a. die Verwendung eines WCS für die Umsetzung, der mindestens eine Implementierung von WCS 2.0.1, die CIS 1.1 unterstützt. Diese Relevanz wird im späteren Verlauf des Kapitels erneut deutlich. Weiter sind Anforderungen hinsichtlich Sprache, erweiterten Capabilities-Metadaten und Anforderungen bezüglich Quality of Service (QOS) und des AdV-WCS Profils einzuhalten.
Durch die INSPIRE konforme Bereitstellung von Rasterdaten über Pre-defined Atom-Feeds wurde es für Anbieter als einfache Lösung der Bereitstellung gesehen. Nach Empfehlung der AdV, ist aber gerade die Bereitstellung von hochauflösenden Rasterdaten über solche Atom-Feeds nicht vorteilbehaftet. Um dies zu untermauern wurde ebenfalls ein Vergleich der beiden alternativen Bereitstellungsarten durchgeführt unter den Kriterien der Wirtschaftlichkeit, der Einsatzmöglichkeit von Standardsoftware, die Abfragemöglichkeiten für Nutzer, der Konformität, der Eignung für hochauflösende Rasterdaten und die Eignung für die Bereitstellung mittels Datenmodell. Als Vorteile der Bereitstellung mit einem WCS werden beispielsweise die einmalige Einführung der Daten mit mehrfacher Nutzung und die Kompatibilität mit zahlreichen Implementierungen angesehen. Die vollständige Gegenüberstellung ist Tabelle 4 zu entnehmen. [12]
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 4 - AdV-Empfehlung für Bereitstellung von Rasterdaten (gekürzt) [12]
Bei der Anwendung in der Vergangenheit kann es folglich oftmals zu Problemen bei der Bereitstellung in Folge der Standardisierung, welche auf Fehlinterpretationen und mangelnde Erfahrung mit den gegebenen Standards zurückzuführen sind. Diese sind auch bei entsprechenden Gremien, wie der INSPIRE Maintenance and Implementation Group bekannt. Nachfolgend werden die jeweiligen Richtlinien kurz vorgestellt und anschließend mögliche Umsetzungen der Re-Harmonisierung, auch nach AdV-Handlungsempfehlung behandelt. Darüber hinaus wird jedoch von der AdV die Bereitstellung von Rasterdaten über die standardisierte OGC-WCS 2.0.1 empfohlen.
2.2.3 Open Geospatial Consortium
Das 1994 gegründete Open Geospatial Consortim, kurz OGC ist ein freiwilliger, weltweiter Zusammenschluss von Verwaltungen, Industrie und Wissenschaft zur Entwicklung offener Standards im Geoinformationswesen. [13]
Mittlerweile gehört das OGC zu einer der wichtigsten Institutionen, wenn es um die Schaffung und Definition von Schnittstellen geht. Im Gegensatz zur internationalen Organisation für Standardisierung gehören zu den Mitgliedern der OGC auch Unternehmen und Behörden, so zum Beispiel die European Space Agency (ESA), das Bundesamt für Kartographie und Geodäsie (BKG), AutoCAD, Google und IBM. Von diesen Mitgliedern werden die OGC Standards entwickelt. Die verfügbaren Spezifikationen für die Implementierung von Diensten sind weltweit öffentlich kostenlos zugänglich. Die Spezifikationen aufgebaut auf ISO-Normen, beschreiben ganz detailliert die Schnittstellen und Encodings. [2]
Das Coverage Implementation Schema 1.0 unterscheidet in drei Coveragetypen:
- Das „GridCoverage“ ist der historisch erste Ansatz für ein gerastertes Coverage, welcher jedoch eingeschränkt ist in der Art und Weise, wie die Koordinaten beschrieben werden können.
- „RectifiedGridCoverage“, welcher auf regelmäßige Raster wie Orthophotos abzielt.
- Der dritte Typ, der „ReferenceableGridCoverage“ war ursprünglich gedacht um alle anderen Arten von Gittern zu erfassen und wurde in einer Erweiterungsspezifikation zu CIS 1.0 mit der entsprechenden Definition bereitgestellt.
In der erweiterten, umfassenden CIS 1.1 sind standardisierte „GeneralGridCoverages“ enthalten und darüber hinaus Handhabungen für Fälle, die nicht unter die drei vorherigen Coveragetypen fallen. Bei der eigentlichen Anwendung beliebiger mehrdimensionaler Gitter wird zudem in Achsentypen unterschieden, um eine willkürliche Unterteilung zu vermeiden. [14]
Letztlich müssen Achsen, die Gitter bilden, die Abbildung zwischen projizierten Koordinaten und den Indexkoordinaten des zugrunde liegenden Arrays beschreiben, das das Rastergitter darstellt. In CIS 1.1 wird in folgende Achstypen unterschieden, die auch miteinander kombiniert werden können (verdeutlicht an Abbildung 6):
- „ Indexachse “, welche sich nicht auf eine reale Situation bezieht, sondern einer einfachen kartesischen Rasterachse mit ganzzahligen Koordinaten ähnelt.
- „ Regelmäßige Achse “, mit einfacher linearer Abhängigkeit zwischen projizierten Koordinaten und den zugrundeliegenden Array-Koordinaten. Hier reicht es aus Start und Distanz, d. h. die Auflösung zu speichern (Daten-Mapping).
- „ Unregelmäßige Achse “, bei der alle relevanten Gitterkoordinaten, die nicht mehr der Äquidistanz entsprechen, in einer Liste gesammelt werden müssen.
- „ Verzogene Achse “, welche die individuellen direkten Positionen explizit ausweist und diese folglich einzeln gespeichert werden müssen.
- „ Algorithmischen Transformationsachse “, die in dem Fall angewendet werden, wenn die Koordinaten der Punkte auf einem projizierten Gitter nicht mehr durch Daten angegeben werden können, sondern durch einen Algorithmus.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6 – Achsentypen und Kombinationen in OGC [14]
Über Coverages können eine Vielzahl von Schnittstellen bedient werden - einschließlich WFS, WMS (Web Map Service) und WPS (Web Processing Service). Jedoch garantiert nur der Web Coverage Service umfassende Funktionalitäten bei der räumlich-zeitlichen Ordnung und Analyse. OGC selbst bietet eine kostenfreie, freizugängliche Testsuite die WCS-Implementierungen und die Coverages untersucht und dadurch die Interoperabilität zwischen den großen und zunehmend quelloffenen und proprietären Servern und Clients sicherstellt.
Sowohl die Coveragedaten als auch das Servicemodell sind modular aufgebaut. Ziel ist es also, dass Werkzeuge (Tools) den Kern und beliebige Erweiterungen wie in Kapitel 2.1 beschrieben, implementieren zu können, dabei aber interoperabel zu bleiben. Jede WCS-Implementierung muss exemplarisch die grundlegenden Untereinstellungsmechanismen des Kerns unabhängig von der Wahl der Erweiterungen unterstützen. Daraus folgt, dass Erweiterungen streng reglementiert sein müssen, damit vorgegebene Strukturen erhalten bleiben. [14]
Die Codierung der Coverages ist darauf ausgelegt, die verschiedenen Anforderungen verschiedener Anwendungsszenarien zu unterstützen (unter Beibehaltung der Interoperabilität). Codierungen mit XML oder JSON sind zwar in der Lage, die gesamte Coverage abzubilden, aber führen oft zu voluminösen Darstellungen, da sie nicht für große Systeme bzw. Coverages skalieren. In solchen Fällen sind binäre Codierungen mit TIFF, NetCDF (Network Common Data Form) oder JPEG2000 eine Alternative, wenn auch nicht alle Informationen gespeichert werden können.
Die Kombination der beiden Ansätze, Informationsvollständigkeit und Volumeneffizienz, bieten Containerformate wie MIME oder ZIP usw. Diese ermöglichen eine Aufteilung der Coverages und der damit einzeln codierten Teile. Idealerweise können so „domainSet“, „rangeType“ und Metadaten in XML oder JSON codiert werden, während der “Pixel-Nutzlast“ („rangeSet“) -Teil in NetCDF kodiert werden kann. [14]
Grundlegend bieten die OGC CIS- und WCS-Standards folglich eindeutig definierte weitverbreitete Erweiterungsmechanismen, die Flexibilität geben, aber unter Beibehaltung der Interoperabilität, weshalb ihre Einsetzbarkeit sehr vielseitig sein kann.
2.2.4 INSPIRE Richtlinien
Die “Infrastructure of Spatial Information in Europe” wurde eingeführt um auf europäischer Ebene, über Bundesgrenzen hinweg, eine einfachere Nutzung von Geodaten zu ermöglichen. Etabliert von der Europäischen Union (EU) sollen jene Richtlinien Verwaltungsprozesse und Verfahren beschleunigen, sowie gemeinschaftliche umweltpolitische Entscheidungen unterstützen. [3]
INSPIRE übernimmt die grundlegende Arbeit von OGC und ISO und greift auf diese Ressource zurück, indem das Deckungskonzept weiterverwendet wird. Allerdings mit Änderungen im Datenmodell, die zwar hilfreich sind, aber zur Inkompatibilität mit OGC und CIS und darauf basierenden Implementierungen führen. Es entsteht somit eine unnötige Komplexität für alle INSPIRE-Anwender.
Rasterdaten und somit Coverages werden innerhalb des Geltungsbereiches von INSPIRE in den verschiedensten Themenbereichen eingesetzt. Dazu gehört die Bereitstellung von Metadaten, Vektordaten, Rasterdaten und Diensten. INSPIRE umfasst drei Themenbereiche, auch Annexes (I, II, III) genannt. Diese beinhalten technische, als auch thematische Gruppierungen von den jeweiligen Datenstrukturen, zu denen u. a. Geologie, Meteorologie, Geodäsie, Landabdeckung, Landnutzung, Atmosphäre, Energie und Biotope gehören. [15]
Die INSPIRE-Richtlinien sind abstrakt und konzeptionell gehalten, um die verschiedensten Themen abbilden zu können. Daher ist eine konkrete Regelung der Datenentnahme und -verschlüsselung notwendig, innerhalb der eigentlichen Spezifikation oder in separaten Richtlinien, wie zum Beispiel die INSPIRE D2.7-Richtlinie für die Codierung von Geodaten. Darüber hinaus sind einige Richtlinien nicht konkret genug formuliert, um die Interoperabilität der Daten gewährleisten zu können. Bei damit verbundenen Services und Dienstleistungen kommt es folglich in der Praxis bei der Implementierung zu Fehlinterpretationen. Eine Veranschaulichung der heterogenen Herangehensweise zeigt Abbildung 7. Um unterschiedliche Modellierungen vermeiden zu können, empfiehlt INSPIRE die Verwendung des Basismodells für Coverages veröffentlicht im INSPIRE “Data Specifications – Base Models – Coverage Types 1.0 (D2.10.2 guidance)” Richtlinien-Dokument. [16]
Dieses Modell harmonisiert Themen übergreifend und ist ISO-Norm entsprechend gestaltet worden. Es besteht aus gemeinsamen Klassen und Anwendungsschemata für Coveragetypen. Weiter lässt sich in die abstrakten Klassen „RectifiedGridCoverage” und „ReferenceableGridCoverage“ unterteilen. Wird erneut ein Blick auf Abbildung 7 geworfen, ist zu erkennen, dass
- für die Themen Höhen (EL), Landabdeckung (LC), Orthofotos (OI), Bodenbeschaffenheit (SO) und Landnutzung (LU) reguläre Raster verwendet werden, mittels Nutzung bzw. Spezialisierung der Coverage-Klasse „ReferenceableGridCoverage“ vom Basis Modell.
- für das Thema Geologie (GE) und die Beschreibung von hydrogeologischen Oberflächen, sowohl regelmäßige und unregelmäßige Gitter verwendet werden können, mittels Nutzung beider abstrakten Klassen des Basis Modells.
- das Thema der natürlichen Risikozonen (NZ) durch regelmäßige und unregelmäßige Gitter mittels spezieller Coverageklassen der „CoverageByDomainAndRange“ Klasse abgebildet werden kann und die dazugehörige Domäne („domain“) durch die Klassen „CV_RectifiedGrid“ oder „CV_ReferenceableGrid“ nach der ISO-Norm 19123 definiert ist.
- die Themen Energieressourcen (ER) und Artendiversität (SD) mit regelmäßigen Gittern und durch eine Spezialisierung der „CoverageByDomainAndRange“ Klasse dargestellt werden können. Ihre Domäne findet sich auf der „CV_RectifiedGrid“ Klasse. Weiter ist es hier möglich „Multi-Point“ und -„Surface Coverages“ zu verwenden.
- im Fall von Umweltüberwachungseinrichtungen (EF), atmosphärischen Bedingungen (AC), meteorologisch geografischen Merkmalen (MF) und ozeanisch geografischen Merkmalen (OF) regelmäßige und unregelmäßige Gitter, als diskrete „ObservationCoverages“ bereitgestellt werden, die den ISO- und INSPIRE-Standards zu Beobachtungen und Messungen entsprechen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 7 - INSPIRE thematische Abdeckungsdaten [14]
Die in der Praxis erarbeiteten weiteren Eigenschaften im Kontext der europäischen GDI wurden an die themenspezifischen Coverage-Feature-Typen annektiert. Das Hinzufügen von Inhalten in den OGC CIS 1.0 Implementierungsstandard ist dabei nicht vorgesehen. Die Erweiterungen bei INSPIRE sind vielzählig und kommen so nicht in den OGC Standards vor, wurden aber als hilfreich erachtet und für Folgeversionen der Standards vorgeschlagen. Da CIS 1.1 auch verschachtelte Coverages unterstützt, werden jedoch gleichzeitig Einschränkungen der Homogenität vorgenommen. Additiv zu den allgemeinen Attributen der INSPIRE Themen gibt es noch themenspezifische Attribute, wie zum Beispiel Suchen, Filtern und Abrufen von bestimmten Coveragedaten. Diese Attribute sind keiner vorhandenen CIS-Eigenschaft zugeordnet, weshalb sie als Erweiterung angesehen werden. [14]
[...]
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.