Fachbereich Vermessungswesen/Kartographie
Lehrgebiet Geoinformationssysteme
Untersuchungen zur Interoperabilität von Web Map Services
1 Einführung
Die zentralen Aufgaben eines Geoinformationssystems sind die Verwaltung, Erfassung, Analyse und Präsentation von Geodaten. Um dies zu realisieren werden an ein GIS verschiedene Anforderungen, wie die Vermeidung von redundanter Datenhaltung gestellt.
Die Entwicklung des Internets ermöglicht es auf Datenquellen zuzugreifen, die weltweit verteilt liegen. Da die Daten dort bereitgestellt werden, wo sie originär erzeugt werden, müssen diese nicht mehr selbst gehalten und gepflegt werden, was Zeit, Kosten sowie redundante Datenhaltung reduziert. Durch die verteilte Bereitstellung von Daten wird allerdings die Vielzahl der Datenformate nicht reduziert, wodurch beispielsweise die Verknüpfung von Daten aus unterschiedlichen Datenquellen erschwert wird. Die Lösung für das Problem ist die Interoperabilität, welche dazu dient Daten zu normen, um diese von einem in ein anderes Programm zu übertragen.
|
Interoperabilität: „bezeichnet auch die Möglichkeit, verschiedenartige Daten in einen einzelnen Arbeitsablauf zu integrieren. Dies setzt voraus, dass Syntax und Semantik der Daten dem Anwender in einheitlicher Form zur Verfügung gestellt wird. Interoperabilität erlaubt den transparenten Zugang zu mehreren raumbezogenen Daten- und Verarbeitungsressourcen innerhalb eines einzigen Arbeitsablaufes, ohne sie in einen Datenbestand zu überführen.“ [1] Die Idee der Interoperabilität in Verbindung mit getrennter Datenhaltung ist, dass Daten über eine Schnittstelle in ein einheitliches Format gebracht werden. Der Fokus des Anwenders liegt somit nicht auf der Datenkonvertierung, sondern auf der direkten Verwertung. Damit wird eine Optimierung des Produktionsablaufs gewährleistet. Durch die getrennte Datenhaltung werden Daten dort gepflegt, wo sie entstehen und bei Anfrage über die definierte Schnittstelle gesendet. Dies ermöglicht weiterhin die Nutzung unterschiedlicher interoperabler Softwarelösungen. Damit erhöht sich für den Anwender die Auswahl von Produkten, wodurch dieser nicht mehr auf ein bestimmtes Softwareprodukt angewiesen ist. |
2 Ziele
Diese Arbeit beschäftigte sich mit dem Begriff „Interoperabilität“ und deren Umsetzung. Dafür war es erforderlich zu prüfen, wie die Komponenten einer WMS Struktur die an sie gestellten Anforderungen umsetzen, um miteinander kommunizieren zu können. Die Anforderungen wurden vom Open Geospatial Consortium entwickelt und in Spezifikationen definiert.
Im Ergebnis der Arbeit wurde eine DV-Infrastruktur erstellt, innerhalb der verschiedene OGC-konforme Web Map Services (WMS) überlagernd im Client präsentiert werden. Vorbereitend zu den praktischen Arbeiten wurden die bisherigen OGC-WMS Spezifikationen, existierende WMS-Profile sowie ausgewählte Produkte betrachtet. Zusätzlich wurde die Anwendung der SLD-Spezifikation und der WMC-Spezifikation geprüft.
Im praktischen Teil dieser Arbeit wurde ein Vorschlag für ein „WMS-Profil Sachsen“ unterbreitet und durch ein entsprechendes Testszenario komplettiert.
3 Grundlagen
3.1 OGC
Das Open Geospatial Consortium besteht momentan aus über 260 Mitgliedern, in über 30 Staaten weltweit, die unterschiedliche Interessen, was die Geodatenverarbeitung betrifft verfolgen. Das OGC entwickelt Spezifikationen, damit Geoinformationssysteme miteinander interoperabel kommunizieren können, was durch die Vision „A world in which everyone benefits from the use of geospatial information and supporting technology.“ [2] ausgedrückt wird.
Zur Realisierung dieser Vision wurde ein Ziel definiert, das mit Hilfe von Programmen umgesetzt wird. Diese Programme werden genutzt, um interoperable Spezifikationen zur Definition von Gremien, bestehend aus Mitgliedern des OGC zu entwickeln. Durch Testen und Anpassen werden iterative Schritte bis zur Fertigstellung durchlaufen. Dabei existieren verschiedene Zustände, die den Entwicklungsstand eines Dokumentes definieren. Diese Entwicklung verläuft eng in der Zusammenarbeit von Konsortien wie W3C und ISO.
| Ziel: | „To lead the global development, promotion and harmonization of open standards and architectures that enable the integration of geospatial data and services into user applications and advance the formation of related market opportunities.“ [2] |
Programme: |
„The OGC Interoperability Program is a series of hands-on engineering initiatives to accelerate the development and acceptance of OpenGIS R Specifications.“ [3] „In the OGC Specification Program the Technical Committee and Planning Committee work in a formal consensus process to arrive at approved (or ”adopted”) OpenGIS R Specifications.“ [3] |
Im Ergebnis dieser Zielstellung entstanden bisher elf Spezifikationen, die das OGC für Standards empfiehlt. Diese befassen sich zum Teil mit verschiedenen Komponenten von Web Services und dem Datenaustausch zwischen ihnen.
3.2 Web Services
Ein Web Service soll Daten einer Informationsquelle auf möglichst vielen Systemen, weltweit über das Internet und in gewünschter Form zur Verfügung stellen. Die Realisierung erfolgt über Komponenten (siehe Abbildung), die Prozesse von der Anfrage bis hin zum Erhalt der Informationen steuern.
![Quelle [4, Seite 4]](graphic/systemarchitektur.gif)
Der wichtigste Baustein in dieser Struktur ist der Web Service. In diesem sind Geodaten eingebunden, die als Endprodukt visualisiert werden. Wie die Daten in den Service eingebunden sind, ist für die Interoperabilität nicht relevant. Wichtig ist, dass diese in genormter Form präsentiert werden. Dabei müssen die Daten dem Wesen des Services entsprechen. So muss ein Kartenservice im Stande sein, die Daten in mindestens einem Graphikformat anzubieten.
Die Visualisierung erfolgt je nach Datenart in einem dafür vorgesehenen Client. Dabei ist es notwendig, dass dieser in der Lage ist, vor der Visualisierung der Daten eine Anfrage an den Service zu senden. Hierbei wird der Vorgang der Datenanforderung als Request und die Antwort vom Service als Response bezeichnet.
Der Datenaustausch zwischen Client und Service findet über das Internet/ Intranet statt, wobei ein Webserver für die Verteilung der Daten verantwortlich ist. Um die Kommunikation zwischen diesen Komponenten über Produktgrenzen hinweg sicherzustellen, wurden von dem OGC Spezifikationen verabschiedet. Die WMS Spezifikationen, als Hauptbestandteil dieser Arbeit, wurden daher an erster Stelle betrachtet. Dazu kommt die Beschreibung von SLD, wobei hierzu die Web Feature Service, Web Coverage Service und Filterencoding Spezifikationen mit betrachtet wurden. WFS und WCS dienen einerseits als Datengrundlage für einen WMS, andererseits ist es zum näheren Verständnis von SLD nötig, die Funktionsweise eines WFS und WCS zu erläutern, da Styled Layer Descriptor direkt mit den Daten dieser Dienste arbeitet. Filterencoding ist insofern wichtig, da mit dessen Methoden Daten selektiert werden können. Web Map Context wurde auch betrachtet, da sie Funktionalitäten von Client-Anwendungen erweitert.
3.2.1 Web Map Service
Web Map Services rendern Geodaten verschiedener Datenquellen (siehe Abbildung) die auf Clients in unterschiedlichen Graphikformaten präsentiert werden. Um einen sicheren und interoperablen Arbeitsablauf zwischen den Komponenten zu gewährleisten, sind zur Standardisierung Spezifikationen erforderlich. Die WMS Spezifikationen standardisieren die Art und Weise, in der Karten angefordert und geliefert werden. Dazu wurde am 19.04.2004 die Spezifikation mit dem Namen „OpenGIS R Web Map Server Interface Implementation Specification Revision 1.0.0“ kurz WMT 1.0.0 OGC veröffentlicht, mit der ein Grundbaustein für WMS Dienste festgelegt wurde. Dem folgten durch Weiterentwicklung bis heute drei weitere Spezifikationen, die mit WMS 1.1.0, WMS 1.1.1 und WMS 1.3.0 [5] gekennzeichnet sind.
Arbeitsweise
Damit ein WMS Daten visualisieren und diese zum Client senden kann, ist es notwendig, dass der Dateninhalt und die Eigenschaften eines WMS dem Nutzer bekannt sind. Aus diesem Grund müssen Daten, die zwischen WMS und Client ausgetauscht werden, folgende Schwerpunkte darstellen:
Client - WMS
WMS - Client
Operationen
Nachrichten zur Abfrage von WMS Services werden durch Requests realisiert, die in Operationen (Interface) unterteilbar sind. Dies sind bei einem Web Map Service Get- Capabilities , GetMap und optional GetFeatureInfo. Die Antwort oder der Response wird als XML oder Graphik gesendet. Requests werden aus der Kombination der URL zum Dienst und Parametern gebildet. Das folgende Beispiel soll dies verdeutlichen:
URL: http://www.WMS-Seite.de/wms?
und
Parameter wie: Version=1.1.1&Request=GetCapabilities&. . .
ergeben den Request
http://www.WMS-Seite.de/wms?Version=1.1.0&Request=GetCapabilities&. . . .
3.2.2 Styled Layer Descriptor
Mit der SLD Spezifikation erhält der Nutzer am Client die Möglichkeit, das Aussehen
der gerenderten Geodaten durch Styles zu beeinflussen. Die untere Abbildung ist hierfür ein Beispiel. Darüber hinaus werden in ihr zusätzlich optionale Requests definiert.
Web Map Service, die SLD unterstützen, sind unter dem Namen SLD - WMS
bekannt.
4 Ergebnisse
4.1 Profile
Die Spezifikationen, die durch das OGC verabschiedet werden, lassen dem Nutzer in bestimmten Fällen einen gewissen Spielraum in ihrer Anwendung. Daher hat ein Teil der Bundesländer Profile definiert, die auf die jeweiligen Bedürfnisse abgestimmt sind. Diese setzen die OGC Spezifikation damit nicht außer Kraft, sondern legen fest, welche Rahmenbedingungen der WMS mindestens erfüllen soll.
Der Entwurf des Sachsen WMS Profils wurde von der GeoBAK erstellt.
- „Der WMS ist als hochverfügbares Bereitstellungssystem im Internet zugänglich.
Der WMS ist als Bereitstellungssystem mit einer durchschnittlichen Verfügbarkeit
von mindestens 96% in den Netzwerken InfoHighway und/oder KDN
und/oder Internet zugänglich.“
- „Der WMS unterstützt die Versionen 1.1.0 und 1.1.1 der OGC Spezifikation. Zukünftige
Implementierungen, die auf höheren Versionen basieren, müssen eine
Abwärtskompatibilität von zwei bei der OGC veröffentlichen Versionsnummern
gewährleisten.“
- „Der WMS unterstützt das Format PNG.“
- „Der WMS unterstützt Transparenz. Der WMS unterstützt Transparenz, wenn
dies nach Art der Datenquelle sinnvoll ist.“
- „Der WMS muss ohne die Angabe von VENDOR SPECIFIC TAGS aufrufbar
sein.“
- „Der WMS unterstützt die in seinen Zuständigkeitsbereich fallenden Gauß -
Krüger Streifen. Die Identifikation erfolgt über die EPSG Codes 31466 bis
31470.“
- „Der WMS unterstützt die in seinen Zuständigkeitsbereich fallenden ETRS89
Zonen. Die Identifikation erfolgt über die EPSG Codes 25832 (Zone 32) und
25833 (Zone 33).“
- „Der WMS gibt Layer nur in definierten, sinnvollen und in den Capabilities
veröffentlichten Maßstabsbereichen (SCALE HINTS) ab. Der WMS liefert beim
überschreiten dieser Skalierungsbereiche leere Bilder.“
- „Der WMS liefert in den Capabilities Angaben zu dem Dienstanbieter (Kontaktdaten)
und zu den Nutzungsbedingungen des Dienstes. Alle Angaben müssen
vollständig und korrekt sein.“
- „Die Parameterinhalte werden in den Capabilities in deutscher Sprache veröffentlicht.“
- „Bei Angabe des Parameters TIME erfolgt die Werteangabe nach ISO8601 Extended
Format (Stand 2000) mit der lokalen Zeitangabe.“
- „Geobasisdaten und Geofachdaten werden in getrennten Layern bereitgestellt.“
Empfohlene Eigenschaften:
- „Der WMS sollte das Koordinatenreferenzsystem WGS84 (geographische Koordinaten,
Platte Carée unterstützen. Die Identifizierung muss über den EPSG
Code 4326 erfolgen.“
- „Der WMS sollte die Operation GetFeatureInfo unterstützen und dabei sowohl
GML als auch ein HTML-Dokument zurückliefern können.“
- „Der WMS sollte das Format JPG/JPEG unterstützen.“
- „Zur individuellen Gestaltung von Vektoren durch den Nutzer des Dienstes sollte
die OGC Spezifikation Styled Layer Descriptor Version 1.0 verwendet werden.“
- „Exceptions sollen im Format XML bereitgestellt werden werden.“
Der Entwurf des Sachsen WMS Profils wurde von der GeoBAK erstellt. Beim Überprüfen der Punkte wurde festgestellt, dass sich dieses stark an den Vorgaben der AdV orientiert. In der Diplomarbeit werden dazu eigene Vorschläge bereitgestellt und auf Fehler im Profil hingewiesen.
4.2 Testszenario
Ein Testszenario soll die korrekte Umsetzung der OGC-Spezifikationen und der Profile, die durch Produkte und Dienste umgesetzt werden, überprüfen. Zur Erstellung eines Testszenarios, um die Umsetzung des Sachsenprofils zu testen, wurden bestehende Szenarios analysiert. Aus den damit gewonnen Ergebnissen und dem vorhandenen Sachsen WMS Profil wurde zu dessen Überprüfung ein Testszenario entwickelt.
Mit diesem Szenario, wurde der ALK Dienst des Landesvermessungsamtes Sachsens überprüft. Die Durchführung des Szenarios zeigte, dass das Testszenario Schwachstellen eines Dienstes aufdecken kann, wobei festgestellt wurde, dass der Dienst in seiner jetzigen Form nicht dem Sachsen Profil entspricht. Die Abweichungen betrafen die falsch angewendete Groß- und Kleinschreibung der Parameternamen, Probleme mit der Hintergrundfarbe und falsch dargestellte Daten(siehe Abbildungen).
|
In nebenstehender Graphik ist die Verwendung von unterschieldichen Transformationsparametersätzen bei der Überlagerung zweier Dienste, zu erkennen. |
4.3 Clientanwendung
Ziel der Arbeit war es eine DV-Infrastruktur zu erstellen, in der verschiedene OGC konforme Web Map Services kaskadierend und überlagernd in einem Client präsentiert werden. Hierbei wurde zuerst ein Architekturvorschlag erarbeitet, indem die Voraussetzungen und Inhalte dieser Kaskade definiert werden. Im Anschluss folgte die Realisierung dieser Aufgabenstellung, sowie die Beschreibung der enthaltenen Daten und des verwendeten Web Map Services. Den Abschluss bildete die Konfiguration des verwendeten Clients (siehe Abbildung)
5 Impressum
| Diplomanden: | ||
| Roberto Riemer | riemer.roberto@freenet.de | |
| Tobias Schneider | tobischneider@web.de | |
| Diplomthema: |
Untersuchungen zur Interoperabilität von Web Map Services |
|
| Gutachter: | ||
| 1.Gutachter: | Prof. Dr.-Ing. F. Schwarzbach | |
| 2.Gutachter: | Prof. Dr.-Ing. M. Müller | |
| Institution: |
Hochschule für Technik und Wirtschaft Dresden (FH) |
Quellen: