Web Processing Service Schnittstelle für GIS Funktionalitäten

Transkript

1 Westfälische Wilhelms-Universität Münster Fachbereich 14 - Geowissenschaften Fachbereich 10 - Mathematik/Informatik Institut für Geoinformatik Diplomarbeit Web Processing Service Schnittstelle für GIS Funktionalitäten vorgelegt von Johannes Brauner 16. Juni 2008 Betreuung: Erstgutachten: Zweitgutachten: Martin May 52 North Initiative for Geospatial Open Source Software GmbH & con terra GmbH Ulrich Streit Institut für Geoinformatik, Universität Münster Lars Bernard Professur für Geoinformationssysteme, Technische Universität Dresden

2 Zusammenfassung Durch die Einführung des abstrakten Web Processing Service (WPS) Standards des Open Geospatial Consortiums (OGC) ist eine der großen Hürden bei der Umsetzung von Geoinformationsssytemen (GIS) in Geodateninfrastrukturen (GDI) überwunden worden. Nun ist es möglich, neben den schon existierenden Visualisierungs- und Datenverwaltungsdiensten, auch Geoprozessierungsfunktionalitäten über standardisierte Schnittstellen dienstebasiert anzubieten. Zu diesen zählen alle Funktionalitäten, die ein GIS im klassischen Sinne zum GIS machen, wie u. a. räumliche Verschneidungen, Generalisierung oder Verfahren der komplexen Bildverarbeitung in der Satellitenbildauswertung. Es sind verschiedene WPS Implementierungen erhältlich, die die abstrakten Schnittstellen bereitstellen. Ein wichtiger Baustein fehlt allerdings weiterhin: Geoprozessierungsfunktionalitäten, die an diese Schnittstellen angebunden sind. Diese Funktionalitäten sind aber in klassischen GIS Paketen durchaus enthalten. Um die Weiterverwendung dieser existierenden Lösungen zu ermöglichen und eigene Reimplementierungen zu vermeiden, wird auf eine Idee aus der Mainstream IT aus dem Bereich der serviceorientierten Architekturen (SOA) zurückgegriffen: Die Anbindung von existierenden Lösungen über einen Wrapperdienst. Für die GDI bedeutet dies, dass Funktionalitäten klassischer GIS über einen WPS Wrapper im Netz angeboten werden. In dieser Arbeit wird eine Konzeption für den Wrapperdienst aufgestellt und untersucht, welche mandatorischen und optionalen Eigenschaften das GIS für eine Anbindung benötigt. Anhand einer proof-of-concept Implementierung mit dem 52 North WPS und GRASS (Geographical Resources Analysis Support System) als klassischem GIS wird gezeigt, dass ein Wrapping möglich ist. Eine wichtige Rolle spielen die maschinenlesbaren Prozessbeschreibungen, die für jede einzelne Funktionalität erzeugt werden müssen. Wenn ganze GIS Pakete angebunden werden sollen, ist diese Aufgabe aufgrund der hohen Anzahl von Funktionalitäten sehr zeitaufwändig. Es wird untersucht und gezeigt, dass sich dieser Vorgang mit semantikbedingten Einschränkungen automatisieren lässt. ii

3 Abstract The process of bringing GIS (Geographical Information System) functionality into a SOA (Service-oriented Architecture) based environment is at present undergoing its completion. Data maintenance and visualisation functionalities are readily available and commonly used in Spatial Data Infrastructures (SDI). Nevertheless, one problem remains: SDIs do not offer real geoprocessing capabilities (as offered in classic desktop GIS) such as generalisation or complex raster based operations. Therefore, the OGC (Open Geospatial Consortium) released the Web Processing Service (WPS) specification, which describes standardised abstract interfaces to bring complex processing power to SOA-based GIS. Despite this existing specification, hardly any concrete implementations of these abstract concepts can be found. Thus, it stands to reason to enhance a classic (desktop) GIS by a WPS interface to enable a full set of existing GIS functionalities. A concept and an architecture are developed to solve this issue by using a wrapper service. It is shown, that a semi-automatic approach to generate appropriate WPS interface descriptions for each GIS functionality is possible. Mandatory and optional properties of stand alone GIS for successful wrapping are outlined. As proof of concept a wrapping service is developed wich offers GRASS (Geographical Resources Analysis Support System) GIS functionalities through 52 North s WPS implementation. iii

4 Inhaltsverzeichnis Zusammenfassung Abstract Verzeichnis der Abbildungen, Listings und Tabellen Abkürzungsverzeichnis ii iii vi vii 1 Motivation und Einführung 1 2 Grundlagen Serviceorientierte Architektur Geodateninfrastruktur Funktionalitäten eines Geoinformationssystems Web Processing Service Schnittstelle Prozess Historie des Web Processing Spezifikation Operationen der Web Processing Service Schnittstelle Das DescribeProcess Dokument Konzeption der Anbindung klassischer GIS an einen WPS Benachbarte Arbeiten Erforderliche Eigenschaften des Geoinformationssystems Programmierbare Prozesse ohne menschliche Interaktion Fähigkeit zum Multitasking Maschinenlesbare Schnittstellenbeschreibung / Automatische Interpretation von Eingabe- und Ausgabeparametern Bestimmung des räumlichen Bezugssystems Probleme bei der Anbindung Zustandslos vs. zustandsbehaftet Benötigte und nicht benötigte Funktionalitäten eines Geoinformationssystems in einer Geodateninfrastruktur Softwaretest Zusammenschau und Schlussfolgerung Mandatorische und optionale Eigenschaften des Geoinformationssystems Referenzarchitektur GRASS als anzubindendes Geoinformationssystem Implementierung Verwendete Software iv

5 Inhaltsverzeichnis v Geographic Resources Analysis Support System - GRASS North Web Processing Service Systemanforderungen System-Use-Case I System-Use-Case II Einbindung in Web Processing Service Workflows Architektur Automatische Erzeugung der DescribeProcess Dokumente Skriptgenerierung Bestimmung des räumlichen Bezugssystems Nachweis der Machbarkeit Geschäfts-Use-Case - Amerikaner ermittelt bereiste Bundesstaaten Ergebnisse und weiterer Forschungsbedarf Diskussion der Ergebnisse Schlussfolgerungen Literatur 67 Anhänge 75 A DescribeProcess Dokument für v.generalize 75 B Shellskript für v.generalize 77 C CD mit Quellcode 78

6 Abbildungsverzeichnis 1 Zyklus der WPS Operationen Referenzarchitektur für die Anbindung von GIS Funktionalitäten an eine WPS Schnittstelle Referenzarchitektur für die Anbindung von GRASS an eine WPS Schnittstelle Ergebnis einer WPS GetCapabilities Anfrage im udig WPS Plugin v.generalize über das udig WPS Plugin ausführen v.select über das udig WPS Plugin ausführen Geschäfts-Use-Case Ergebnis: Bereiste US Bundesstaaten Tabellenverzeichnis 1 Erhältliche Geoprozessierungsdienste und ihre Eigenschaften Eigenschaften von GIS und WPS Eigenschaften von GRASS und Problemlösungen bzgl. WPS Listings 1 Beispielaufrufe für GIS über die Kommandozeile Beispiel eines Unix Shell Skripts Inputparameterbeschreibung in einem DescribeProcess Dokument Inputparameter in einer Desktop GIS XML Schnittstellenbeschreibung Verzeichnisstruktur eines GRASS Workspace Inhalt der GRASS Konfigurationsdatei Auszug aus einem Shellskript für v.generalize vi

7 Abkürzungsverzeichnis 52n API BPEL DTD EPSG ESRI FGDC FIFO GDI GDI NRW GDI-DE GIS GML GNU GPL GPS GRASS GSDI HLA HTTP INSPIRE ISO IT JTS KVP LGPL MIME NASA O&M OASIS OGC OSGeo OWS RBS SDI SOA SOAP SQL SWE North Application Programming Interface Business Process Execution Language Document Type Definition European Petroleum Survey Group Geodesy Environmental Systems Research Institute Federal Geographic Data Committee First In - First Out Geodateninfrastruktur Geodateninfrastruktur Nordrhein-Westfalen Geodateninfrastruktur Deutschland Geographisches Informationssystem, kurz Geoinformationssystem Geography Markup Language Rekursives Akronym für GNU s Not Unix GNU General Public License Global Positioning System Geographical Resources Analysis Support System Global Spatial Data Infrastructure High Level Architecture Hypertext Transfer Protocol Infrastructure for Spatial Information in Europe International Organization for Standardization Information Technology JTS Topology Suite, auch Java Topology Suite Key Value Pair GNU Lesser General Public License Multipurpose Internet Mail Extensions National Aeronautics and Space Administration Observations and Measurements Organization for the Advancement of Structured Information Standards Open Geospatial Consortium, früher OpenGIS Consortium Open Source Geospatial Foundation OGC Web Service Räumliches Bezugssystem Spatial Data Infrastructure Serviceorientierte Architektur, engl. Service-oriented Architecture Keine Abkürzung. Früher: Simple Object Access Protocol. Structured Query Language Sensor Web Enablement vii

8 Listings viii UDDI udig URL WCS WCTS WFS WMS WPS WPS-T WSDL WSRF XML XSLT Universal Description, Discovery and Integration User-friendly Desktop Internet GIS Uniform Resource Locator Web Coverage Service Web Coordinate Transformation Service Web Feature Service Web Mapping Service Web Processing Service Web Processing Service Transactional Web Service Description Language Web Service Resource Framework Extensible Markup Language Extensible Stylesheet Language Transformation

9 1 Motivation und Einführung 1 1 Motivation und Einführung Applikationen in eine serviceorientierte Architektur (SOA) zu integrieren spiegelt einen aktuellen Trend in der Mainstream IT (Information Technology) wider (Blake et al., 2006). Viele Applikationen werden nun als Web Service angeboten, anstatt wie bisher als Desktop Anwendung. Auch die Geoinformationsgemeinschaft wird von diesem Trend stark beeinflusst. Sie strebt eine [...] full integration of geospatial data and geoprocessing resources into mainstream computing [...] (Reed, 2004, u. a.) an. Um dieses Ziel zu erreichen wurde von aktiven Mitgliedern der Gemeinschaft 1994 das Open Geospatial Consortium (OGC) gegründet. Dieses hat eine Fülle von abstrakten Schnittstellenbeschreibungen, Implementierungsspezifikationen und Standards für die Repräsentation und Verarbeitung von raumbezogenen Daten veröffentlicht, um die von Reed beschriebene Vision des OGC Wirklichkeit werden zu lassen. Die Arbeiten des OGC beschränken sich nicht nur auf den Bereich der Geodateninfrastrukturen (GDI), deren technische Ebenen im Wesentlichen durch SOA Konzepte definiert sind, sie zielen aber hauptsächlich auf die oben genannte Vision ab. Wheate beschreibt Ende der 1980er Jahre GIS (Geographisches Informationssystem) als einen aktuellen Trend: GIS represents the current buzzword in the field of geography. (Wheate, 1989). Ein gegenwärtiges buzzword ist SOA (Schäffer, 2007, S. 15). Der Trend SOA als technische Komponente einer GDI steht somit auch in der Geoinformationsgemeinschaft aktuell im Mittelpunkt des Interesses. Trotzdem will man auf die bisherigen Erkenntnisse und die in langen Jahren erworbene Erfahrung im Umgang mit Desktop GIS nicht verzichten und sie mit in die Zukunft nehmen. Nach Burrough und McDonnell (1998, S. 11 ff.) erfüllt ein klassisches GIS folgende Aufgaben: Geodatenerzeugung, -speicherung und ihr beliebiges Abrufen, Geodatentransformation (einschließlich Geodatenanalyse), Visualierung von Geodaten und -information. Bisher sind GIS eher als klassische Desktop Anwendungen bekannt. Um diese vollständig in eine SOA bzw. GDI zu überführen, muss die Funktionsfähigkeit aller drei Aufgabenbereiche gewährleistet sein. Werden die Aufgaben eines GIS auf OGC Standards und Spezifikationen abgebildet, wird sehr schnell deutlich, dass für den Bereich der Geodatenerzeugung und - verwaltung schon Standards existieren, u. a. Simple Features for SQL (Open Geospati-

10 1 Motivation und Einführung 2 al Consortium Inc., 2006a) und die Geography Markup Language (GML) (Open Geospatial Consortium Inc., 2007c). Für aktive Datengewinnung aus Sensoren können Standards aus dem Bereich der Sensor Web Enablement (SWE) Initiative herangezogen werden, beispielsweise die Beschreibungssprache Observations and Measurements (O&M) (Open Geospatial Consortium Inc., 2007a). Der Bereich der Visualisierung wird ebenfalls von OGC Bemühungen abgedeckt. Es wurden diverse Spezifikationen für Internetkartendienste beschrieben, u. a. die Web Mapping Service (WMS) Spezifikation (Open Geospatial Consortium Inc., 2006b). Sogar die Kombination und Orchestrierung verschiedener OGC Dienste (Service Chaining) ist möglich (Open Geospatial Consortium Inc., 2002, S. 8). Ein Kartendienst kann in GML beschriebene Vektordaten von einem Web Feature Service (WFS) (Open Geospatial Consortium Inc., 2005) abfragen und diese mit einem Luftbild eines weiteren Kartendienstes verschneiden. Der Benutzer kann das Ergebnis online betrachten oder auch ausdrucken. Für einen kompletten Übergang der Funktionalitäten eines klassischen GIS in eine GDI fehlt nur noch ein wichtiger und zentraler Aspekt: die Möglichkeit Geodaten zu analysieren und somit zu wirklicher Geoinformation zu erweitern (Kiehle et al., 2007). Geoinformationen sind in einen bestimmten fachlichen Kontext eingebettete und analysierte Geodaten. Details liefern u. a. Worboys und Duckham (2004, S. 5). Darüberhinaus sehen die GDI Referenzarchitekturen der NASA (National Aeronautics and Space Administration) bzw. des FGDC (Federal Geographic Data Committee) auf amerikanischer und der INSPIRE (Infrastructure for Spatial Information in Europe) Richtlinie auf europäischer Seite Geoprozessierung als wichtigen Bestandteil einer GDI an (Bernard et al., 2005a). Zusätzlich steigt die allgemeine Nachfrage nach webbasierter Geoprozessierung auf dem Mainstream Markt. Beispielsweise halten im Bereich der Web mapping Dienste immer mehr erweiterte Geoprozessierungsfunktionalitäten Einzug, siehe z. B. die Routingfunktion auf Google Maps ( Gelegentliche GIS Nutzer können auf den Kauf und die lokale Installation eines umfangreichen GIS Pakets verzichten und entsprechende Dienste im Internet nutzen. Aus technologischer Sicht bietet sich die Prozessierung auf einem Server auch für mobile und daher eher leistungsschwache Endgeräte an. Beispielsweise können bei einem Großschadensfall Einsatzkräfte vor Ort umfangreiche Analysen über Evakuierungsgebiete durchführen, ohne Zugriff auf einen leistungsstarken Rechner zu haben. Eine Netzverbindung ist zwar notwen-

11 1 Motivation und Einführung 3 dig, kann aber durch neue Mobil- und Digitalfunktechnologien zunehmend stabiler und flächendeckender zur Verfügung gestellt werden. Völlig neue Einsatzgebiete können erschlossen werden, über die man bisher aufgrund fehlender Prozessierungsfunktionalitäten noch gar nicht nachgedacht hat. Ein entsprechendes Angebot wird Nachfrage erzeugen. Aufgrund von schnelleren Prozessoren und gestiegenen Netzwerkbandbreiten können heute auch größere Geodatensätze effizient verarbeitet werden, und es kann über eine Geoprozessierung im Netz nachgedacht werden (Foerster und Schäffer, 2007). Um die Lücke der fehlenden Geoprozessierung auf Standardisierungsebene zu schließen hat das OGC 2007 die Web Processing Service (WPS) Spezifikation (Open Geospatial Consortium Inc., 2007d) veröffentlicht. Die Spezifikation stellt Schnittstellen für die Bereitstellung beliebiger Prozessierungsfunktionalitäten in einer GDI zur Verfügung. Damit sind vor allem Geoprozessierungsfunktionalitäten gemeint. Algorithmen für die Generalisierung von Vektordaten (Longley et al., 2005, S. 80 ff.), komplexe Bildanalysen mit Operationen der Map Algebra (Tomlin, 1983) im Rasterdatenbereich oder auch Implementierungen der Egenhofer Operatoren (Egenhofer und Franzosa, 1991) - nur um prominente Beispiele zu nennen - können damit im Netz verfügbar gemacht werden. Obwohl Schäffer (2007) Möglichkeiten der Komposition von komplexen Arbeitsabläufen aus atomaren Geoprozessierungsfunktionalitäten beschreibt, gibt es keine umfassende Sammlung von nutzbaren Prozessen in einem WPS. Schäffer (2007, S. 83) musste WPS Prozesse selbst implementieren, da nur wenige und nur sehr spezielle Implementierungen des WPS, z. B. Foerster und Stoter (2006), existieren. Dieses Problem hatten auch Stollberg und Zipf (2008) in Bezug auf fundamentale GIS Funktionalitäten, wie Buffer und Intersection. Sie kommen zu dem Schluss, dass sie weiterhin traditionelle Desktop GIS verwenden müssen, solange noch keine größere Vielfalt an WPS existiert (Stollberg und Zipf, 2008). Dieses Problem besteht trotz WPS Spezifikation weiterhin: Wie kann man Geodateninfrastrukturen möglichst umfassend mit Geoprozessierungsfunktionalitäten ausstatten, wie sie klassischerweise durch arbeitsplatzrechnergebundene GIS Pakete bereitgestellt werden? In SOA ist der Ansatz verbreitet, bestehende eigenständige Desktop Anwendungen oder Teile daraus für die Nutzung im Web zu adaptieren und mit entsprechenden Schnittstellen zu wrappen (Papazoglou und Heuvel, 2007). Erl schreibt über den Wrapper service: A type of integration service that encapsulates and exposes logic residing within a legacy system. (Erl, 2005, S. 720). Angewandt auf das GDI Konzept bedeu-

12 1 Motivation und Einführung 4 tet dies, ein schon existierendes GIS mit einer WPS Schnittstelle auszustatten, anstatt benötigte GIS Funktionalitäten von Grund auf erneut selbst zu implementieren. So können schon gewachsene und zuverlässige Algorithmen und Funktionalitäten wiederverwendet bzw. in einer GDI weiterverwendet werden. Der Implementierungsaufwand beschränkt sich dann auf das Wrapping. Diese Idee (rudimentär auch von Michaelis und Ames, 2008, vorgeschlagen) wird in der vorliegenden Arbeit diskutiert und führt zu folgenden Forschungsfragen: Wie können (Desktop) GIS Funktionalitäten in einer GDI angeboten werden? Viele GIS Pakete haben eine lange Geschichte. Ihre Wurzeln reichen zum Teil bis in die 1980er Jahre und weiter zurück. Die zugrundeliegende Systemarchitektur ist deshalb für eine Verwendung in einem verteilten System ursprünglich nicht ausgelegt gewesen. Die daraus entstehenden Unterschiede und Probleme mit ihren entsprechenden Lösungen bilden zentrale Punkte dieser Arbeit. Der Aufwand für das Wrapping und die benötigten Eigenschaften, um die Funktionalitäten bestehender GIS mit einer WPS Schnittstelle auszustatten, werden beschrieben. Auf Basis der Konzeption und der 52 North WPS Implementierung wird ein Wrapperservice für GRASS (Geographical Resources Analysis Support System) GIS Vektor Funktionalitäten entwickelt. Dieser leitet an den WPS gestellte Anfragen zur Prozessierung an das GRASS GIS weiter und formt das dort produzierte Ergebnis in eine WPS Antwort um, die zurück zum Client geschickt wird. Können automatisch Beschreibungen von GIS Funktionalitäten erzeugt werden? Für jede in einem WPS bereitgestellte GIS Funktionalität muss ein Describe- Process Dokument erzeugt werden. Dies besteht aus Angaben zu den Ein- und Ausgabeparametern, Kodierungen, Datentypen und weiteren Metadaten. Das DescribeProcess Dokument ist eine durch ein entsprechendes Schema spezifizierte Extensible Markup Language (XML) Datei. Valide XML Dokumente zu erzeugen kann ein sehr aufwändiger Vorgang sein. Hochgerechnet auf die hohe Anzahl von Funktionalitäten, die ein klassisches GIS Paket bereitstellt, ist das Erstellen der DescribeProcess Dokumente deshalb eine sehr langwierige Arbeit. In welchem Ausmaß kann dieser Vorgang automatisiert werden? Es wird ein XSLT

13 1 Motivation und Einführung 5 (Extensible Stylesheet Language Transformation) Filter implementiert, der bei der Erzeugung von DescribeProcess Dokumenten aus GRASS XML Schnittstellenbeschreibungen die Automatisierung unterstützt. Welche Eigenschaften muss ein GIS haben, damit ein Wrapping mit einer WPS Schnittstelle möglich ist? Die vorhergehenden Fragen beschäftigen sich mit den atomaren GIS Funktionalitäten und nicht mit dem GIS Paket als solchem. Hier wird das GIS als Ganzes daraufhin untersucht, ob es mandatorische Eigenschaften gibt, die ein GIS für eine WPS Schnittstelle qualifizieren. Weiterhin werden optionale Eigenschaften ermittelt, die für einen Betrieb in einem verteilten System wünschenswert sind, aber im Falle des Fehlens einen Einsatz nicht blockieren. Es bleibt festzuhalten, dass es sich bei der vorliegenden Arbeit um keine umfassende und abschließende Analyse oder gar ein Rahmenwerk handelt, um sämtliche Funktionalitäten beliebiger bestehender GIS Pakete anzubinden. Konzeption und Systemarchitektur sind flexibel angelegt und stehen vielen Nutzungsmöglichkeiten offen. Auf eine konkrete Szenariobeschreibung, aus der sich klassischerweise dann eine Konzeption ableitet, wird daher verzichtet. Aufbau der Arbeit Anhand der Grundlagen aus den Bereichen SOA, GDI und WPS (Kapitel 2) und der Forschungsfragen werden benachbarte Arbeiten kurz diskutiert und eine Konzeption und eine Systemarchitektur entwickelt (Kapitel 3). In einer proof of concept Implementierung mit GRASS als GIS und dem 52 North WPS als WPS wird gezeigt, dass die konzeptionellen Überlegungen aus den Forschungsfragen zu einem lauffähigen System führen (Kapitel 4). Anhand eines konstruierten Anwendungsfalls wird die Implementierung auf Nutzbarkeit überprüft (Kapitel 5). In Kapitel 6 werden die gewonnenen Erkenntnisse diskutiert und weiterer Forschungsbedarf ermittelt.

14 2 Grundlagen 6 2 Grundlagen In dieser Arbeit geht es im Wesentlichen um serviceorientierte Architekturen, Geodateninfrastrukturen, GIS Funktionalitäten und die Web Processing Service Spezifikation. Hier werden die Grundlagen und Konzepte dieser Begriffe erläutert. 2.1 Serviceorientierte Architektur Obgleich mittlerweile ein von der Organization for the Advancement of Structured Information Standards (OASIS) standardisiertes Referenzmodell für serviceorientierte Architekturen (Organization for the Advancement of Structured Information Standards, 2006a) existiert, finden sich in der Literatur unterschiedliche Ergänzungen und Interpretationen (Heutschi, 2007, S 30 f.). Laut OASIS Referenzmodell wird eine SOA wie folgt definiert: Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. Erl (2005, S. 41) ergänzt den Begriff Web Service: Contemporary SOA represents an architecture that promotes service-orientation through the use of Web services. Dostal et al. (2005, S. 11) definieren so: Unter einer SOA versteht man eine Systemarchitektur, die vielfältige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste repräsentiert und dadurch eine plattform- und sprachenunabhängige Nutzung und Wiederverwendung ermöglicht. Weitere Definitionen aus der Literatur hat Heutschi (2007, S. 193 ff.) gesammelt. Er definiert zusammenfassend: Eine SOA ist eine mehrschichtige, verteilte Informationssystem (IS)- Architektur, die Teile von Applikationen für eine vereinfachte Prozessintegration als geschäftsorientierte Services kapselt und dabei bestimmte Designprinzipien berücksichtigt. (Heutschi, 2007, S. 22) Im weiteren Verlauf der Arbeit wird der Begriff Dienst synonym mit Web Service verwendet. Je nach Blickwinkel wird SOA unterschiedlich interpretiert. Softwareentwickler sehen die technischen Herausforderungen, die auch in dieser Arbeit primär beachtet werden. Geschäftsleute legen den Schwerpunkt auf die Modellierung von Geschäftsprozes-

15 2 Grundlagen 7 sen. Anwendern geht es hauptsächlich um möglichst intuitive Verwendbarkeit. (Kontogiannis et al., 2007) Zusammengefasst, erhöht die Verwendung einer SOA also die Interoperabilität und Wiederverwendbarkeit von lose gekoppelten und in sich gekapselten Softwarefunktionalitäten in einem verteilten System. Interoperabiltität von Diensten bezeichnet ihre Fähigkeit, Informationen untereinander auszutauschen und die ausgetauschten Informationen zu interpretieren (Heutschi, 2007, S. 36). Mit gesteigerter Interoperabilität steigt auch das Wiederverwendungspotential. Lose gekoppelte Dienste können interagieren, ohne dass im Voraus festgelegt werden muss, wer mit wem wie kommunizieren kann (Papazoglou und Heuvel, 2007; Erl, 2005, S. 297 f.). Das vermeidet unauflösbare Abhängigkeiten, die zur Laufzeit auftreten, und die Interoperabilität wird erhöht. Durch die Veröffentlichung von Dienstebeschreibungen in entsprechenden Katalogdiensten im Netz (Dostal et al., 2005, S. 14 f.) steigt der Kreis der möglichen Nutzer und damit auch die Zahl der Wiederverwendungsmöglichkeiten. Aufgrund der losen Kopplung der Komponenten und Dienste in einem verteilten System müssen nur abstrakte Schnittstellen einheitlich beschrieben werden. Weder Implementierungsdetails noch die Programmiersprache und die Plattform, auf der der Dienst läuft, sind relevant für die Benutzer des Systems (Chen et al., 2006). Auch die Verwendung von Standards erhöht die Interoperabilität (Heutschi, 2007, S. 30). Nach Papazoglou und Heuvel (2007) sind die verbreitetsten Beispiele aus der Mainstream IT die Standards SOAP für die Kommunikation, WSDL (Web Service Description Language) für die Schnittstellenbeschreibung und UDDI (Universal Description, Discovery and Integration) für die Katalogdienste. Da aber auch Protokollunabhängigkeit ein wichtiger Aspekt in SOA ist (Papazoglou und Heuvel, 2007; Dostal et al., 2005, S. 20), kann auch auf andere Standards gesetzt werden, beispielsweise HTTP/GET bzw. HTTP/POST mit durch XML Schema spezifizierten Schnittstellenbeschreibungen, wie bisher im OGC Kontext üblich. Im Folgenden werden Eigenschaften von Diensten näher untersucht, die für diese Arbeit von Bedeutung sind: Autonomität Jeder Dienst ist eine eigene funktionale Einheit mit keinerlei Abhängigkeit zu anderen Diensten. Innerhalb dieser Einheit hat der Dienst die volle Kontrolle über seine Funktionalität. Erl unterscheidet zusätzlich in Autonomität auf Diensteebene und pure Autonomität. Der zu entwickelnde Wrapperdienst ist auf

16 2 Grundlagen 8 Diensteebene autonom, da er die funktionale Einheit - in diesem Fall das anzubindende GIS - auch noch mit anderen potentiellen Anwendern, beispielsweise über die Konsole eingeloggten Benutzern, teilen kann. Auf die Funktionalität eines pur autonomen Dienstes kann nur über die definierten Diensteschnittstellen zugegriffen werden. Nur duch Autonomität ist beliebige Wiederverwendung möglich (gerade wenn Dienste orchestriert werden sollen, s. u.). (Papazoglou und Heuvel, 2007; Erl, 2005, S. 303 ff.) Zustandslosigkeit Dienste sollen zustandslos modelliert werden. Das bedeutet, dass nur für die Zeit zwischen Anfrage und Rücksendung der generierten Antwort Zustände auf dem Server bleiben dürfen. Jede Anfrage muss hinreichende Informationen mitliefern, damit eine Anfrage ausreichend bearbeitet werden kann. Nach Abarbeitung einer Anfrage sollen sämtliche Spuren gelöscht sein. Dadurch erhöht sich die Wiederverwendbarkeit, da keine Abhängigkeiten von beispielsweise Zwischenergebnissen entstehen können. (Papazoglou und Heuvel, 2007; Erl, 2005, S. 307 ff.) Dies kann im Falle von Geodatenprozessierung unter Umständen zu Performanzeinbußen führen (s. Abschnitt 3.3.1). Maschinenlesbare und standardisierte Schnittstellenbeschreibung Jeder Dienst hat eine maschinenlesbare und standardisierte Schnittstellenbeschreibung (Papazoglou und Heuvel, 2007; Curbera et al., 2003; Dostal et al., 2005, S. 9). In ihr wird definiert, wie der Dienst zu erreichen ist, welche Operationen er zur Verfügung stellt und welche Eingabe- und Ausgabeparameter für diese Operationen benötigt werden (Erl, 2005, S. 295). Maschinenlesbarkeit ist für das Austauschen von Informationen zwischen einzelnen Diensten wichtig. Nur selten ist ein menschlicher Benutzer direkt an der Interaktion beteiligt. Ohne die Verwendung von Standards bei der Schnittstellenbeschreibung sinkt die Interoperabilität, und eine Wiederverwendung ist eingeschränkt. Black-Box-Prinzip Dienste bieten keinen direkten Zugriff auf die darunterliegende Funktionalität, von dieser wird komplett abstrahiert. Ausschließlich die Schnittstellenbeschreibung zeigt an, welche Funktionalitäten ein Dienst anbietet und wie sie verwendbar sind. (Papazoglou und Heuvel, 2007; Erl, 2005, S. 298 ff.)

17 2 Grundlagen 9 Orchestrierbarkeit Mehrere feingranulare Dienste können zu einem abstrahierteren Dienst zusammengefasst werden. Entsprechende Workflows können modelliert werden. (Papazoglou und Heuvel, 2007; Erl, 2005, S. 301 ff.) Friis-Christensen et al. (2007) beschreiben zwei Nachteile serviceorientierter Architekturen: Neue Technologien müssen erlernt werden. Um Interoperabilität zu gewährleisten, muss man sich auf eine gemeinsame Architektur und eine standardisierte Entwicklungsstrategie einigen. Für ersteres gibt es keine Lösung. Zweiteres wird im Geoinformatikumfeld durch Standards, Spezifikationen und sonstige Bemühungen von OGC und ISO erreicht (siehe nächster Abschnitt). 2.2 Geodateninfrastruktur The SDI concept enhances mainstream Information Technology s (IT) widely accepted principle of Service Oriented Architectures (SOA) to include spatial features. (Kiehle et al., 2007) Dass Spatial Data Infrastructures (SDI), also GDI noch weit mehr sind, als im Zitat von Kiehle beschrieben, wird in diesem Abschnitt erläutert. Im oft zitierten GSDI Cookbook (Global Spatial Data Infrastructure) wird GDI wie folgt definiert: 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 provides a basis for spatial data discovery, evaluation, and application for users and providers within all levels of government, the commercial sector, the non-profit sector, academia and by citizens in general. (Nebert, 2004, S. 8) Es geht also nicht nur um die technische Grundlagenschaffung für die Bereitstellung von räumlichen Daten in verteilten Systemen und entsprechenden Funktionalitäten für den Zugriff darauf. Zusätzlich existieren institutionelle und politische Probleme, die für die Schaffung von GDI von Bedeutung sind. Groot und McLaughlin (2000b) gehen mit ihrer Definition weiter ins Detail:

18 2 Grundlagen 10 Geospatial Data Infrastructures encompasses the networked geospatial databases and data handling facilities, the complex of institutional, organizational, technological, human, and economic resources which interact with one another and underpin the design, implementation, and maintenance of mechanisms facilitating the sharing, access to, and responsible use of geospatial data at an affordable cost for a specific application domain or enterprise. Williamson (2003) schreibt ebenfalls, dass bei der Entwicklung und Etablierung von GDI neben der technischen Komponente immer auch soziale, politische und kulturelle Rahmenbedingungen beachtet werden müssen. In dieser Arbeit geht es hauptsächlich um die technische Ebene, deshalb wird auf weitere Erläuterung der nicht-technischen Aspekte einer GDI verzichtet. Für die nähere Auseinandersetzung mit ihnen sei besonders die Lektüre von Groot und McLaughlin (2000a) und Williamson et al. (2003) empfohlen. Der Bedarf an räumlichen Daten kann auf globaler bis hin zur lokalen Ebene durch Geodateninfrastrukturen gedeckt werden. Auf den unterschiedlichen Ebenen gibt es bereits entsprechende Initiativen. (Rajabifard et al., 2003; Bernard et al., 2005b) Die GSDI Association kümmert sich um die globale Harmonisierung von GDI. Bekanntestes Produkt ist das weiter oben zitierte SDI Cookbook von Nebert (Nebert, 2004). INSPIRE kümmert sich um die Umsetzung einer europäisch harmonisierten Geodateninfrastruktur, um transeuropäische Projekte (besonders im Bereich der Nachhaltigkeit) und die Arbeit der Europäischen Kommission mit der entsprechenden Geodatengrundlage zu versorgen. Bundesweit koordiniert GDI-DE (GDI Deutschland) den Aufbau einer länder- und ressortübergreifenden Geodateninfrastruktur, die auch die Ziele von INSPIRE integriert. Viele Bundesländer haben ihre eigenen Initiativen: Eines der ältesten Beispiele ist die GDI NRW (Geodateninfrastruktur Nordrhein- Westfalen). Neuere Initiativen kommen aus Sachsen (GDI Sachsen) oder Bayern (GDI Bayern). Auch Bezirksregierungen oder Kommunen unterhalten zum Teil ihre eigenen GDI. Näheres zu den einzelnen GDI Projekten kann in Bernard et al. (2005c, Teil I) nachgelesen werden. Technologie ist die treibende Kraft beim Aufbau von GDI (Williamson, 2003). Da auf der technischen Ebene SOA Konzepte eine dominante Rolle spielen - das Zitat von Kiehle et al. (2007) anfangs lässt dies nur erahnen - wird kurz auf die Arbeit vom OGC eingegangen, weil selbiges die technische Standardisierung im Geoinformationsbereich vorantreibt und Standardisierung wichtiger Faktor der gewünschten Interope-

19 2 Grundlagen 11 rabilität ist. Kurze Einführungen zu den einzelnen OGC Standards und der technischen Komponente einer GDI liefert Bernard et al. (2005c, Teil II). Seit der Gründung 1994 liegt der Schwerpunkt des OGC auf der Spezifikation von Schnittstellen und Datenformaten, auf Inititativen zur Interoperabilität (z. B. OWS Phase 5, OWS-5) und auf Lobbyarbeit. Zusätzlich wird die Umsetzung von OGC Standards in der Geoinformationsgemeinschaft gefördert. Eine strategische Partnerschaft mit der ISO (International Organization for Standardization) erlaubt die gleichzeitige Veröffentlichung von OGC Standards als ISO Standard. 2.3 Funktionalitäten eines Geoinformationssystems Auf die Beschreibung der Eigenschaften eines (monolithischen) GIS wird hier nicht näher eingegangen. Neteler und Mitasova (2007, S. 11) liefern ausreichend komprimierte Grundlagen dafür. Für weitergehende Studien werden Longley et al. (2005) und Worboys und Duckham (2004) empfohlen. Der Begriff GIS Funktionalität hingegen ist für diese Arbeit von hoher Wichtigkeit. Burrough und McDonnell (1998, S. 13) unterteilen GIS Software in fünf funktionale Gruppen: Dateneingabe und Verifikation, Datenspeicherung und Datenbankenmanagement, Datenausgabe und Präsentation, Datentransformation, Benutzerinteraktion. Diese funktionalen Gruppen decken zusammen alle Bereiche eines GIS ab, wie es in Kapitel 1 beschrieben wird. Unter dem Begriff Datentransformationsfunktionalitäten lassen sich alle klassischen Geoprozessierungsfunktionalitäten aus den Bereichen der Geodatenanalyse zusammenfassen, die sowohl auf den geometrischen, als auch auf topologischen und sonstigen nicht räumlichen Attributen operieren (Burrough und Mc- Donnell, 1998, S. 14). Longley et al. (2005, Part IV Analysis) verstehen unter Geodatenanalyse Funktionalitäten für Kartographie und Kartenproduktion, Geovisualisierung, einfache und kompliziertere räumliche Analysen und räumliche Modellierung.

20 2 Grundlagen 12 Welche Funktionalitäten für die Anbindung über eine WPS Schnittstelle interessant sind, und welche überhaupt nicht benötigt werden, wird in Abschnitt erläutert. 2.4 Web Processing Service Schnittstelle Um sämtliche Funktionsbereiche eines traditionellen GIS in einer GDI umsetzen zu können und die Vorgaben von GDI Referenzarchitekturen zu erfüllen (s. Kapitel 1), fehlte auf Standardisierungsseite noch eine Spezifikation, die Geoprozessierung im Netz verfügbar macht. Diese Lücke schließt das OGC mit der Veröffentlichung der OpenGIS Web Processing Service Spezifikation (Open Geospatial Consortium Inc., 2007d), die im Folgenden näher beschrieben wird Prozess Im Sinne der WPS Spezifikation handelt es sich bei einem Prozess um ein Modell oder eine Berechnung, das bzw. die als Dienstinstanz verfügbar gemacht wird (Open Geospatial Consortium Inc., 2007d, S. 2). Bei einem Geoprozess handelt es sich um einen Prozess, der räumliche Daten bearbeitet (Schäffer, 2007, S. 3). Geoprozessierungsdienste können in unterschiedliche Diensttypen unterschieden werden (Open Geospatial Consortium Inc., 2002, S. 27 ff.): Räumliche Dienste Unter räumlichen Diensten versteht man Dienste, die die räumlichen Attribute von Geodaten ändern. Beispiele sind Koordinatentransformationsdienste, Orthorektifizierungsdienste, Generalisierungsdienste und Routingdienste. Thematische Dienste Thematische Dienste operieren auf den fachlichen Attributen von Geodaten, beispielsweise bei der Luftbildanalyse, der fachlichen Zusammenfassung in Geoobjektklassen oder Verfahren der Luftbildverbesserung (z. B. Kontraste verstärken). Zeitliche Dienste Alle Analysen, die sich mit zeitlicher Veränderung von Geodaten befassen, werden als zeitliche Dienste gewertet. Das ist besonders bei Betrachtung der Veränderung von kontinuierlichen Sensordaten interessant.

21 2 Grundlagen 13 Metadatendienste Mit Metadatendiensten werden im wesentlichen statistische Parameter von Geodatensätzen erfasst, z. B. Bestimmung des Mittelwerts oder des Medians, Berechnung der Standardabweichung, usw.. Es wird deutlich, dass die Überschneidung dieser Dienste mit traditionellen GIS Funktionalitäten sehr hoch ist Historie des Web Processing Erste Ansätze der Integration von Geoprozessierungsfunktionalitäten in verteilte Systeme gibt es schon längere Zeit. Beispielsweise beschreiben Bernard et al. (2001) und Schulze et al. (2002) die Integration der High Level Architecture (HLA) als Geoprozessierungsfunktionalität in die OGC Welt. Legt man die in Abschnitt aufgeführte Unterscheidung der Geoprozessierungsdiensttypen zugrunde, kann auch der Web Coordinate Transformation Service (WCTS) des OGC (Open Geospatial Consortium Inc., 2007e) - derzeit noch kein endgültiger Standard - als Geoprozessierungsdienst aufgefasst werden. Das Filter Encoding beim WFS wird nicht als Geoprozessierung bezeichnet, sondern als eine andere Sichtweise auf Daten beschrieben, obwohl Abfragen auf Verschneidung, Vereinigung, usw. möglich sind, die man im traditionellen GIS als Geoprozessierung beschreiben würde. Das Filter Encoding ist kein serviceorientierter sondern ein datenorientierter Ansatz. (Kiehle et al., 2007) Spezifikation Die WPS Spezifikation in der zur Drucklegung aktuellen Version ermöglicht Web Clients den Zugriff auf Berechnungen bzw. Berechnungsmodelle, die auf räumlichen Daten arbeiten. Als Daten können beliebige Formate - von GML bis zu binären Bilddaten - von lokalen oder im Netz verfügbaren Ressourcen verwendet werden. Die angebotenen Prozesse sind in ihrer Komplexität völlig variabel. Sowohl einfache Buffer Prozesse als auch die Berechnung von hochkomplexen Klimamodellen können zugreifbar gemacht werden. Die WPS Spezifikation legt nicht fest, welche Art von Prozessen angebunden wird, sondern definiert eine allgemeine Schnittstelle für den Zugriff auf Prozessierungsfunktionalitäten. Jede WPS Implementierung legt für sich selber fest, welche konkreten Prozesse sie anbietet. (Open Geospatial Consortium Inc., 2007d, S. 1 ff.)

22 2 Grundlagen 14 Prozesse werden über DescribeProcess Dokumente beschrieben, die sowohl von menschlicher Seite, als auch von Maschinen lesbar und verwendbar sind (Kiehle et al., 2007). Näheres dazu in Abschnitt In den meisten OGC Spezifiktionen wird die Verwendung von SOAP als Übertragungsprotokoll und WSDL für die Dienstbeschreibung noch nicht spezifiziert. Die WPS Spezifikation hingegen ist so neu, dass der Trend zur Verwendung von Mainstream IT Standards ansatzweise berücksichtig wird. Wie diese Richtung im OGC weiter verfolgt wird hängt u. a. von den Ergebnissen aus OWS-5 (Schäffer, 2008) ab Operationen der Web Processing Service Schnittstelle Die WPS Schnittstelle besteht aus drei mandatorischen Operationen, im Folgenden kurz dargestellt. Für nähere Informationen ist die jeweilige Fundstelle in der Spezifikation angegeben. GetCapabilities Wie jeder spezifizierte OGC Dienst muss auch die WPS Spezifikation die GetCapabilities Operation mandatorisch implementieren. Laut der OGC Web Services Common Specification (OWS Common Open Geospatial Consortium Inc., 2007b, S. 12), die allen OGC Spezifikationen zugrunde liegt, liefert die GetCapabilities Operation Metadaten über die spezifischen Server Operationen. Für den Fall des WPS sind dies alle mandatorischen Angaben aus OWS Common und zusätzlich Angaben über die angebotenen Prozessierungsfunktionalitäten (jeweils Name und Kurzbeschreibung), aber auch die sonstigen Schnittstellen DescribeProcess und Execute. Ebenso muss die URL (Uniform Resource Locator) zu einem WSDL Dokument als alternativer Schnittstellenbeschreibung angegeben werden. Der Request muss über HTTP/GET als Key Value Pair (KVP) definiert sein und kann optional auch über HTTP/POST als XML kodierte Anfrage gestellt werden. (Open Geospatial Consortium Inc., 2007d, S. 11 ff.) DescribeProcess Die DescribeProcess Operation liefert für einen oder mehrere angefragte WPS Prozesse die erweiterte durch XML Schema definierte Prozessbeschreibung. Enthalten sind Angaben zu sämtlichen Ein- und Ausgabeparametern und deren Datenformaten. Sie liefert das Gerüst für die konkrete Schnittstelle eines angebotenen Prozesses, der mit der Execute Operation angefragt werden kann. Die

23 2 Grundlagen 15 URL für das entsprechende WSDL Dokument darf ebenfalls nicht fehlen. Abschnitt geht genauer auf die Inhalte ein. Die Kodierung erfolgt analog zur DescribeProcess Operation. (Open Geospatial Consortium Inc., 2007d, S. 16 ff.) Execute Basierend auf den anzugebenden Parametern aus dem DescribeProcess Dokument kann ein bestimmter Prozess über Execute angefragt werden. Eingabedaten können in die Anfrage direkt hineingeschrieben oder als URL Referenz (as reference) übergeben werden. Das Ergebnis des Prozesses kann entweder direkt in das XML Antwortdokument hineingeschrieben werden (ResponseDocument) oder als Rohdaten zurückgeliefert werden (RawDataOutput). Für beide Antworttypen kann entschieden werden, ob die Antwort auf dem WPS Server gespeichert werden soll (storeexecuteresponse) oder nicht. Dies ist eine der wenigen OGC Spezifikationen, die eine asynchrone Anfrage ermöglichen. Sinnvoll ist dies bei Prozessen, die lange Prozessierungszeiten benötigen und deshalb bei synchroner Anfrage anfällig sind für time outs auf der Clientseite. Im Falle des Speicherns der Antwort auf der Serverseite wird sofort nach erster Anfrage eine URL zurückgeliefert, unter der das Ergebnis zu erwarten ist, und der aktuelle Status des Prozesses (failed, completed, paused, accepted, ongoing) abgefragt werden kann. Execute muss über HTTP/POST XML und kann zusätzlich über HTTP/GET KVP kodiert angefragt werden. (Open Geospatial Consortium Inc., 2007d, S. 30 ff.) In Abbildung 1 wird vereinfacht gezeigt, in welcher Reihenfolge typischerweise die WPS Operationen aufgerufen werden. Begonnen wird mit einer GetCapabilities Anfrage, die alle verfügbaren Prozesse und deren Kurzbeschreibung zurückgibt. Aus ihnen wählt der Benutzer die gewünschten Prozesse aus und schickt eine entsprechende DescribeProcess Anfrage. Als Antwort bekommt er die gewünschten Prozessbeschreibungen mit allen notwendigen Eingabe- und Ausgabeparametern. Er gibt Werte für die gewünschten Parameter an und schickt diese als Execute Request zur Prozessierung an den WPS. Das Ergebnis wird in gewünschter Form an den Client zurückgeliefert Das DescribeProcess Dokument Das DescribeProcess Dokument (Open Geospatial Consortium Inc., 2007d, S. 18 ff.) enthält Prozessbeschreibungen zu den angefragten Prozessen. Prozessbeschreibungen bestehen aus:

24 2 Grundlagen 16 Abbildung 1 Vereinfachte Darstellung eines typischen Zyklus der WPS Operationen: 1. GetCapabilities. 2. Capabilities (mit verfügbaren Prozessen). 3. DescribeProcess (mit Angabe des gewünschten Bufferprozesses). 4. DescribeProcessDokument (mit Layer und Bufferdistanz als notwendigen Eingabeparametern). 5. Execute (mit Angabe des gewünschten Bufferprozesses, der URL als Layerreferenz und einer Bufferdistanz als notwendigen Eingabeparametern). 6. GML Dokument (mit dem Ergebnis des Bufferprozesses als Feature Class). (Eigene Darstellung) Name und Kurzbeschreibung, wie auch schon im GetCapabilities Antwortdokument vorhanden. Eine bis endlich viele Beschreibungen von Ein- (Input) und Ausgabeparametern (Output). Parameter können mandatorisch oder optional sein und in der Anzahl beschränkt oder unbeschränkt. Sie haben eine der drei folgenden Datenstrukturen: ComplexData Eine komplexe Datenstruktur, beispielsweise ein GML Dokument oder Binärdaten. Es wird angegeben, ob sie direkt in die Execute Anfrage einkodiert werden soll, oder ob sie als im Netz verfügbare URL referenziert wird,

25 2 Grundlagen 17 so dass der WPS sie sich selbst herunterladen kann (spart eventuell zusätzliches Herunterladen auf den Clientrechner). Es wird jeweils ein Metadaten Tripel aus Format (MIME Type, mandatorisch), Enkodierung (z. B. UTF8, optional) und Schema (z. B. GML Packet, optional) benötigt. LiteralData Angabe des Parameters in einem primitiven Datentyp (z. B. Float, Integer oder String), etwa die Buffer Distanz als Gleitkommazahl. Parameter können auf bestimmte Werte oder Wertebereiche eingeschränkt werden. Die Vorgabe eines Standardwertes ist möglich. Wenn es erforderlich ist, können Maßeinheiten angegeben werden. BoundingBoxData Bei diesem Parameter handelt es sich um eine Bounding Box. Ein entsprechendes RBS (Räumliches Bezugssystem) muss angegeben werden. Zusätzlich unterstützte RBS sind optional. Es kann angegeben werden, ob asynchrone Anfragen möglich sind (statussupported), und ob das Ergebnis für das spätere Herunterladen auf dem Server hinterlegt werden kann (storesupported). Der Aufbau des DescribeProcess Dokuments ist durch ein entsprechendes in der Spezifikation beschriebenes XML Schema maschinenlesbar definiert. Clients und andere Dienste, die die WPS Schnittstelle verstehen, können untereinander kommunizieren. Anhang A skizziert ein bespielhaftes DescribeProcess Dokument für das v.generalize GRASS Modul. In dieser Arbeit spielt das Dokument als solches eine entscheidende Rolle, da pro GIS Funktionalität, die über einen WPS Wrapper verfügbar gemacht werden soll, eine eigene Prozessbeschreibung erzeugt werden muss. Abschnitt geht näher auf die automatische Erzeugung der Dokumente ein.

26 3 Konzeption der Anbindung klassischer GIS an einen WPS 18 3 Konzeption der Anbindung klassischer Geoinformationssysteme an einen Web Processing Service Nachdem im vorangehenden Kapitel die Grundlagen einer SOA, GDI und die WPS Schnittstelle beschrieben wurden, behandelt dieses Kapitel die Unterschiede und die Abgrenzung zwischen monolithischen GIS und durch WPS bereitgestellten Schnittstellen für GIS Funktionalitäten. Begonnen wird mit der Beschreibung spezieller GIS Eigenschaften, die benötigt werden um erfolgreich wrappen zu können (Abschnitt 3.2). Zusätzlich gibt es einige fundamentale Umsetzungsprobleme, deren Lösung in Abschnitt 3.3 erläutert wird. Abschnitt 3.4 fasst die gewonnenen Erkenntnisse zusammen und begründet, warum GRASS GIS in dieser Arbeit für eine exemplarische Implementierung ausgewählt wurde. 3.1 Benachbarte Arbeiten Im Folgenden wird kurz zusammengefasst, woran zur Zeit im Zusammenhang mit Geoprozessierung und der WPS Spezifikation geforscht wird. Anschließend werden ähnliche Umsetzungen beschrieben, die Geoprozessierung im Netz bereits ermöglichen. Foerster und Stoter (2006) untersuchen die Anbindung von Generalisierungsalgorithmen über die WPS Schnittstelle. In ihrer Diplomarbeit entwickelt Stollberg (2006) einen WPS zur Aggregation von räumlichen Daten. Anhand einer Fallstudie untersuchen Friis-Christensen et al. (2007) die Integration von WPS Geoprozessierung in eine heterogene OGC Dienstekette. Ein Ausblick auf mögliche Orchestrierungen mit Mainstream IT Standards wird gegeben. Einen ähnlichen Ansatz verfolgen Kiehle et al. (2007). Sie legen ihren Fokus aber eher auf Probleme bei der Diensteorchestrierung. Einen transaktionalen WPS für BPEL (Business Process Execution Language) basierte orchestrierte WPS Prozesse mit dazugehörigem graphischen Modellierungswerkzeug entwickelt Schäffer (2007) in seiner Diplomarbeit.

27 3 Konzeption der Anbindung klassischer GIS an einen WPS 19 Granell et al. (2007) untersuchen die Verwendung der WPS Spezifikation und die entstehenden Probleme bei der Verarbeitung von großvolumigen Satellitenbildern. Ebenso mit Rasterdaten arbeiten Díaz et al. (2007). Sie beschreiben den Aufbau einer Prozessierungskette aus grundlegenden und angepassten Diensten. Mit Aspekten der semantischen Interoperabilität und damit vor allem mit der besseren Beschreibung von Funktionalitäten befassen sich Lemmens et al. (2007) und Bucher und Joliviet (2008). Stollberg und Zipf (2007, 2008) vergleichen in ihren Arbeiten BPEL und den WPS selbst für die Orchestrierung. Eine allgemeine Untersuchung und mehrere Vorschläge für die Verbesserung der WPS Spezifikation liefern Michaelis und Ames (2008). Weitere Ergebnisse und Bezüge zur vorliegenden Arbeit werden in Abschnitt 6.1 erläutert. Implementierte Geoprozessierungsdienste Einen kurzen Überblick über erhältliche Geoprozessierungsdienste enthält Tabelle 1. Der 52 North WPS, ArcGIS Server, deegree WPS und PyWPS werden auf die Umsetzung der WPS Spezifikation, die angebotenen Funktionalitäten und ihr Lizenzmodell hin untersucht. Es wird schnell ersichtlich, dass entweder viele Funktionalitäten angeboten werden oder die WPS Spezifikation unterstützt wird. Der 52n (Kurzform für 52 North) WPS ist zudem die einzige Implementierung, die schon die Version der Spezifikation umsetzt. Über die vorgestellten Produkte hinaus gibt es noch einige Anwendungen im Netz, die einzelne Geoprozessierungsdienste bereitstellen. Hier handelt es sich z. B. um Routingfunktionalitäten. Da diese weder standardisiert sind noch viele Funktionalitäten auf einmal anbieten, werden sie hier nicht weiter untersucht. 3.2 Erforderliche Eigenschaften des Geoinformationssystems Folgende GIS Eigenschaften werden für ein erfolgreiches Wrapping herausgearbeitet: Programmierbare Prozesse ohne menschliche Interaktion, Fähigkeit zum Multitasking,

28 3 Konzeption der Anbindung klassischer GIS an einen WPS 20 Tabelle 1 Überblick über erhältliche Geoprozessierungsdienste. Untersucht wird die Umsetzung der WPS Spezifikation, das Angebot an Funktionalitäten und die Art der Lizenz. (L)GPL bedeutet (Lesser) General Public License. Umsetzung der WPS Spezifikation (Version) Angebot an GIS Funktionalitäten Lizenz 52 North WPS ja (1.0.0) 3 Beispielprozesse GPL & kommerziell ArcGIS Server 9.2 Keine Standardisierung Breites Spektrum an ArcGIS Funktionalitäten deegree WPS 2.2 ja (0.4.0) 1 Beispielprozess LGPL PyWPS ja (0.4.0) 10 Beispielprozesse GPL Kommerziell Maschinenlesbare Schnittstellenbeschreibungen / Automatische Interpretation von Eingabe- und Ausgabeparametern, Bestimmung des räumlichen Bezugssystems. Einige von ihnen werden als mandatorische Eigenschaften beschrieben. Andere hingegen sind optional, d. h. ein generelles Anbinden an eine WPS Schnittstelle wird durch ein Fehlen nicht blockiert. Für einen stabilen Betrieb werden sie allerdings dringend empfohlen. Im Folgenden werden die einzelnen Eigenschaften näher erläutert Programmierbare Prozesse ohne menschliche Interaktion Klassische GIS werden in direkter Interaktion vom Benutzer bedient und gesteuert. In serviceorientierten Architekturen sind in der Regel Web Services für die Abarbeitung der Benutzeranfragen zuständig. Der Benutzer sitzt nicht wie gewohnt vor seinem Rechner und kann das GIS anweisen, was zu tun ist, denn der Web Service läuft entfernt auf einem Applikationsserver. Die Steuerung erfolgt durch einen geeigneten (Browser-) Client. Für jede Interaktion, die der Benutzer tätigen möchte, muss eine Anfrage erzeugt, an den Service geschickt, dort prozessiert und eine geeignete Antwort wieder zurück an den Client geschickt werden. Dem SOA und auch OGC Prinzip der Zustandslosigkeit folgend, sollten nach jeder Abarbeitung eines Anfrage/Antwort- Paars keine Spuren oder Zustände auf dem Server hinterlassen werden. Interaktive Nachfragen zur Laufzeit einer Anfrage sind also ausgeschlossen. Weitere Probleme, die sich aus der Zustandslosigkeit herleiten lassen, sind in Abschnitt beschrieben. In der Anfrage müssen sämtliche Informationen mitgeliefert werden, die zur Laufzeit vom Service benötigt werden. Folglich sollte das GIS ebenfalls in der Lage sein, mit

29 3 Konzeption der Anbindung klassischer GIS an einen WPS 21 Listing 1 Beispielaufrufe für GIS über die Kommandozeile., # B e i s p i e l e i n e s e i g e n e n Kommandos pro GIS F u n k t i o n a l i t a e t. $ b u f f e r p r o c e s s b u f f e r d i s t a n c e =3 i n p u t d a t a=b e i s p i e l. shp # P a r a m e t r i s i e r t e r GIS A u f r u f. $ x y g i s p r o c e s s=b u f f e r p r o c e s s b u f f e r d i s t a n c e =3 i n p u t d a t a=b e i s p i e l. shp der Menge an gelieferten Parametern und Daten ohne weitere Nachfragen ein Ergebnis zu erzeugen. Eine Möglichkeit, unüberwacht nicht nur das GIS, sondern auch Einzelfunktionalitäten des GIS zu starten und auszuführen, ist eine mandatorische Eigenschaft des anzubindenden GIS. Es wird impliziert, dass das GIS auch ohne graphische Benutzeroberfläche auskommt. Folgende Möglichkeiten der unüberwachten Steuerung sind denkbar: Ausführung mittels eines Konsolenskripts, einer Batchdatei oder einer Programmiersprache, Ausführung über eine schon bestehende Webschnittstelle. Für die Prozessierung über ein Konsolenskript (Unix basierte Betriebssysteme) oder Batchdateien (Microsoft Windows) wird vorausgesetzt, dass sämtliche GIS Funktionalitäten entweder als eigene Kommandos zur Verfügung stehen, oder das GIS mit einem parametrisierten Aufruf gestartet werden kann. Entsprechende Beispiele liefert Listing 1. Ein Konsolenskript besteht aus einer Anzahl von einzelnen Befehlen, die nacheinander abgearbeitet werden. Listing 2 liefert ein bespielhaftes Unix Shell Skript, das in ein bestimmtes Verzeichnis wechselt (Zeile 2), die Dateien dort in einer Archivdatei zusammenfasst (Zeile 4) und diese dann auf eine andere Festplatte verschiebt (Zeile 6). Jeder dieser Schritte (Zeile 2, 4 und 6) ist als einzelner Prozess zu verstehen, die der Reihe nach abgearbeitet werden, sobald./simplebackup.sh auf der Konsole aufgerufen wird. Sollte ein Befehl fehlschlagen, wird in der Regel die Abarbeitung des Skripts abgebrochen. In Unixskripten sind einfache Schleifenkonstrukte und konditionale Abfragen (if-then-else) möglich. Unter Windows ist dies prinzipiell auch möglich, allerdings sehr rudimentär gehalten. Außerdem kann es erforderlich sein, dass für die Ausführung zusätzliche Umgebungsvariablen gesetzt oder sonstige Konfigurationsdateien vorhanden sein müssen. Diese können potentielle Nachfragen an den Benutzer ersetzen, die durch fehlende In-

30 3 Konzeption der Anbindung klassischer GIS an einen WPS 22, Listing 2 Beispiel eines Unix Shell Skripts (./simplebackup.sh) zur Erzeugung eines Backups und dessen Verschieben an einen anderen Ort. 1 # Wechseln i n das zu s i c h e r n d e Z i e l v e r z e i c h n i s. 2 cd /home/ j o e j o e 3 # S p e i c h e r n a l l e r vorhandenen Dateien i n e i n e r A r c h i v d a t e i ( backup. t a r ). 4 t a r c v f backup. t a r 5 # V e r s c h i e b e n der backup D a t e i auf e i n e e x t e r n e F e s t p l a t t e. 6 mv backup. t a r / media / e x t e r n teraktionsmöglichkeiten nicht gegeben sind. Hier kann es sich beispielsweise um Pfadangaben zu anderen ausführbaren Dateien bzw. Bibliotheken oder Datenbankumgebungen handeln. Bei den Umgebungsvariablen handelt es sich um eine Möglichkeit, im Voraus alle notwendigen Parameter zu setzen, so dass Nachfragen überflüssig werden. Dies ist nur dann möglich, wenn das GIS und das verwendete Betriebssystem Konfigurationen über Umgebungsvariablen zulassen. Das Vorgehen im Fall einer Schnittstelle für andere Programmiersprachen ist der Methode mit Konsolenskripten ähnlich. Anstatt eines simplen Skripts sind die zu verwendenden Ausdrücke einer komplexeren Programmiersprache entnommen (ESRIs ArcGIS erlaubt beispielsweise Python, Perl oder VBScript). So sind wesentlich komplexere Skripte möglich, die allerdings auch schwieriger (automatisch) zu erzeugen sind. Unabdingbar muss ein derartiges Skript aber auch von außen automatisch startbar sein, sei es nun über die Konsole oder über eine andersartige Schnittstelle des GIS, die auf Anfragen hört, sobald es gestartet ist. Sollte das GIS schon über eine andere Art von Webschnittstelle verfügen (beispielsweise SOAP), ist eine andere Herangehensweise erforderlich. In diesem Fall muss eine Zwischeninstanz erzeugt werden, die über die WPS Schnittstelle eingehende Anfragen in das Format der bestehenden GIS Schnittstelle transformiert und dann simuliert, dass ganz regulär ohne WPS angefragt wurde. Die Antwort des GIS muss auf dem Rückweg dann ebenfalls wieder in eine WPS-konforme Antwort transformiert und ausgeliefert werden Fähigkeit zum Multitasking Unter Multitasking versteht man eine Betriebsart, bei der mehrere Computer-Tasks gleichzeitig oder verzahnt ablaufen. Multitasking bezeichnet dasselbe wie Mehrprogrammbetrieb (Stallings, 2003, S. 851). Bei Stallings (2003, S.850) und Tanenbaum (2003, S. 22 f. und S. 87 ff) wird der Begriff Multiprogrammierung synonym zum Mul-

31 3 Konzeption der Anbindung klassischer GIS an einen WPS 23 titasking verwendet. Ein Computer-Task (s. Definition oben) entspricht einem Prozess im Sinne des Betriebssystems (nicht zu verwechseln mit einem WPS Prozess). Ein Betriebssystemprozess ist ein Programm in der Ausführung, mit dazugehörenden Systemressourcen (Stallings, 2003, S. 104). Betriebssystemprozesse können in einzelne Threads unterteilt sein, die eine unterbrechbare Arbeitseinheit repräsentieren und sequentiell abgearbeitet werden können. Wenn Threads nebenläufig prozessierbar sind, spricht die Literatur von Multithreading (Stallings (2003, S. 104), Tanenbaum (2003, S. 97)). Näheres zum Konzept des Multitasking und -threading und zu Betriebssystemprozessen liefern Tanenbaum (2003) und Stallings (2003). Angewandt auf das anzubindende GIS bedeutet dies, dass zwei Arten von nebenläufiger Bearbeitung von GIS Funktionalitäten möglich sind: Parallele Ausführung von Prozessen in einer GIS Instanz (Multitasking wird auf der obersten Ebene vom GIS durchgeführt), Ausführungen von mehreren GIS Instanzen gleichzeitig (Multitasking findet auf der Betriebssystemebene statt). Der Unterschied beider Ansätze besteht in der jeweiligen Verantwortung für das Ressourcenmanagement. Unter Ressourcen sind CPU Zeiten, Arbeitsspeicherbedarf, Zugriff auf Eingabe- und Ausgabegeräte und Prozessprioritäten zu verstehen. Bei der parallelen Ausführung von mehreren Prozessen in einer GIS Instanz ist das GIS für die Verteilung der entsprechenden Ressourcen zuständig, indem es entsprechende Betriebssystemprozesse inklusive der dazugehörigen Threads erzeugt und an das Betriebssystem weiterreicht. Wenn es das GIS ermöglicht, auf dem gleichen System mehrere Instanzen gleichzeitig auszuführen, muss das Betriebssystem in der Lage sein, entsprechende Betriebssystemprozesse zu erzeugen und Entscheidungsgewalt über die Ressourcen auszuüben. Im monolithischen GIS im Desktopbetrieb liegt der Fokus nicht auf der parallelen Ausführung von mehreren Prozessen. Es ist hier eher unüblich, dass rechenintensive Prozesse parallel ausgeführt werden müssen. In SOA bzw. Geodateninfrastrukturen ist dies allerdings eine wichtige Eigenschaft, da es in der Natur des verteilten Systems liegt, dass mehrere Anfragen von unterschiedlichen Clients gleichzeitig ankommen. Gleiches gilt für den in dieser Arbeit nicht betrachteten Betrieb des GIS über einen Terminalserver. Für die Erweiterung der GIS-Funktionalitäten um eine WPS Schnittstelle ist eine Vergabe der Ressourcen über die Betriebssysteme die bevorzugte Variante. Einerseits

32 3 Konzeption der Anbindung klassischer GIS an einen WPS 24 ist das Betriebssystem sehr gut auf die entsprechende Rechnerarchitektur angepasst, beispielsweise wenn mehrere Prozessoren bzw. Prozessorkerne im System vorhanden sind. Andererseits führt ein eventueller Absturz einer GIS Instanz nicht gleichzeitig auch zum Absturz der parallel ausgeführten Instanzen. Wenn Anfragen in einer einzigen Instanz parallel bearbeitet werden, führt ein Absturz unter Umständen auch zum Abbruch der restlichen Prozesse. Diese Eigenschaft muss im Voraus durch entsprechende Tests überprüft werden (siehe Abschnitt 3.3.3). Gerade bei der Prozessierung von großvolumigen Rasterdaten ist die Fähigkeit zum parallelen Prozessieren wichtig, egal ob in einer oder mehreren GIS Instanzen. Hier ist eine hohe Flexibilität gefordert, da es sinnvoll sein könnte, einen zeitaufwändigen Prozess zu unterbrechen oder in den Hintergrund zu verschieben, wenn eine schnell prozessierbare Anfrage ankommt. Der Anfrager der zeitaufwändigen Prozessierung hat eine längere Wartezeit kalkuliert, also fällt die Verzögerung nicht weiter ins Gewicht. Da die Prozessierungsdauer im Voraus meist nicht bekannt ist, ist dieser Ansatz schwer zu realisieren und kann nur durch zusätzliche Forschung vorangetrieben werden. Gleiches gilt für die Möglichkeit der Priorisierung von bestimmten Prozessen. Gerade in zeitkritischen Anwendungen, beispielsweise im Katastrophenschutzumfeld, ist dies immanent wichtig. Abschließend bleibt zu erwähnen, dass eine fehlende Multitaskingfähigkeit des GIS ein Wrapping mit einer WPS Schnittstelle nicht unmöglich macht, da der WPS jederzeit die Möglichkeit bietet, eine Anfrage unter der Begründung server busy zu verweigern. Dies wäre dann der Fall, wenn schon eine andere Anfrage prozessiert wird. Eine Alternative ist das Ablegen von Anfragen in einer FIFO (First In - First Out) Warteschlange, sofern es vom WPS oder dem Applikationsserver ermöglicht werden kann. Die Anfragen werden dann sequentiell abgearbeitet. Für eine möglichst störungsfreie und effiziente parallele Bearbeitung von Prozessen im WPS sind entsprechende Lastund Performanztests erforderlich (s. Abschnitt 3.3.3) Maschinenlesbare Schnittstellenbeschreibung / Automatische Interpretation von Eingabe- und Ausgabeparametern Ganz dem SOA Paradigma folgend werden die durch den WPS angebotenen Funktionalitäten maschinenlesbar in Form des DescribeProcess Dokuments beschrieben. Maschinenlesbar impliziert, dass die Beschreibung einer bestimmten Struktur bzw. einem semantischen und syntaktischen Schema folgt. Ein GIS benötigt in der Regel keine maschinenlesbaren Schnittstellenbeschreibungen, stattdessen werden die Funktio-

33 3 Konzeption der Anbindung klassischer GIS an einen WPS 25 nalitäten durch Hilfstexte oder Anleitungen beschrieben, so dass sie für den Benutzer verständlich und bedienbar sind. Für die angestrebte automatische Generierung von DescribeProcess Dokumenten ist es wichtig, dass auch die GIS Schnittstellenbeschreibungen in irgendeiner Form maschinenlesbar sind. Am einfachsten kann dies über eine fest spezifizierte (z. B. durch eine Document Type Definition (DTD) oder durch XML Schema) Beschreibung erfolgen. Ein prominentes Beispiel aus dem SOA Umfeld ist die Web Service Description Language (WSDL). Für die Transformation von einer spezifizierten XML Beschreibung in das Describe- Process Dokument gibt es sehr komfortable Lösungen, beispielsweise eine automatische Konvertierung über eine Extensible Stylesheet Language Transformation (XSLT). Sollte eine XML beschriebene Schnittstelle nicht verfügbar sein, gibt es noch weitere nicht ganz so offensichtliche und praktische Lösungen. Im Desktop GIS enthaltene Hilfetexte folgen oft einem bestimmten Schema und sind entsprechend formatiert, so dass mit höherem Aufwand ein Parser geschrieben werden kann, der aus den Hilfetexten die Informationen extrahieren kann. Sollte das GIS quelloffen verfügbar sein, kann auch der Quelltext durchsucht und geparst werden. Doch dazu muss dem Sourcecode ebenfalls eine entsprechende Struktur zugrunde liegen. Derart strukturierte Quelltexte sind bei Open Source Software durchaus üblich, da aufgrund der vielen heterogenen Entwickler eine Kollaboration ohne eine gewisse Struktur unmöglich ist. Beide alternativen Parser sind sehr aufwändig zu entwickeln und sehr fehleranfällig, sobald der Struktur in Einzelfällen nicht Folge geleistet wird. Ein sehr viel intensiveres und genaueres Testen (s. Abschnitt 3.3.3) ist in diesem Fall notwendig. Beim automatischen Generieren von DescribeProcess Dokumenten existiert ein weiteres strukturelles Problem, das in den unterschiedlichen Ansätzen zwischen GIS und WPS begründet ist: die unterschiedliche Interpretation von komplexen Eingabeparametern für einen Prozess. Mit komplexen Parametern sind die eigentlichen Geodaten gemeint, nicht zusätzliche einfache Parameter wie z. B. die Distanz eines Buffers. In einem GIS wird davon ausgegangen, dass die zu bearbeitenden Daten unter einem definierten Namen schon im Workspace (Erläuterungen zum Workspace in Abschnitt 3.3.1) vorhanden sind. Beim WPS werden die Daten erst zur Laufzeit der Prozessierung eingeladen (s. Abschnitt 3.3.1). Im GIS kann der Inputdatenlayer eines Prozesses nun über den definierten Namen angesprochen werden. Weitere Angaben über das Datenformat sind überflüssig, da der Importvorgang schon im Voraus durch den Benutzer erfolgt ist. Der Unterschied zwischen beiden Ansätzen wird in Listing 3

34 3 Konzeption der Anbindung klassischer GIS an einen WPS 26, Listing 3 Maschinenlesbare Beschreibung zweier Inputparameter (Inputlayer und Buffer Distanz) in einem DescribeProcess Dokument eines Buffer Prozesses. 1 <I n p u t minoccurs=" 1" maxoccurs=" 1"> 2 < o w s : I d e n t i f i e r>i n p u t</ o w s : I d e n t i f i e r> 3 <o w s : T i t l e>polygon to be b u f f e r e d</ o w s : T i t l e> 4 <o w s : A b s t r a c t>the G e o m e t r i e s to b u f f e r</ o w s : A b s t r a c t> 5 <ComplexData> 6 <D e f a u l t> 7 <Format> 8 <MimeType>t e x t /XML</ MimeType> 9 <Schema>h t t p : // schemas. o p e n g i s. net /gml / / f e a t u r e. xsd</schema> 10 </ Format> 11 </ D e f a u l t> 12 <Supported> 13 <Format> 14 <MimeType>t e x t /XML</ MimeType> 15 <Schema>h t t p : // schemas. o p e n g i s. net /gml / / f e a t u r e. xsd</schema> 16 </ Format> 17 </ Supported> 18 </ ComplexData> 19 </ I n p u t> 20 <I n p u t minoccurs=" 0" maxoccurs=" 1"> 21 < o w s : I d e n t i f i e r>b u f f e r</ o w s : I d e n t i f i e r> 22 <o w s : T i t l e>b u f f e r</ o w s : T i t l e> 23 <o w s : A b s t r a c t>b u f f e r d i s t a n c e i n map u n i t s</ o w s : A b s t r a c t> 24 <L i t e r a l D a t a> 25 <ows:datatype o w s : r e f e r e n c e=" x s : s t r i n g "/> 26 <ows:anyvalue /> 27 </ L i t e r a l D a t a> 28 </ I n p u t>, Listing 4 Maschinenlesbare Beschreibung zweier Inputparameter (Inputlayer und Buffer Distanz) in GRASS GIS für einen Buffer Prozess. 1 <parameter name=" i n p u t " type=" s t r i n g " r e q u i r e d=" y e s " m u l t i p l e="no"> 2 <d e s c r i p t i o n>name o f i n p u t v e c t o r map</ d e s c r i p t i o n> 3 </ parameter> 4 <parameter name=" b u f f e r " type=" f l o a t " r e q u i r e d="no" m u l t i p l e="no"> 5 <d e s c r i p t i o n>b u f f e r d i s t a n c e i n map u n i t s</ d e s c r i p t i o n> 6 </ parameter> (WPS) und Listing 4 (GRASS) deutlich. In GRASS wird der Inputlayer nur durch einen String input (Listing 4, Zeile 1) beschrieben. Angaben über den Datentyp sind nicht erforderlich. Beim WPS sind zusätzliche Angaben über das Datenformat notwendig, wie zum Beispiel Mime Type und Schema (Listing 3, Zeile 5 bis 18). Der automatische Konvertierer (z. B. XSLT Filter) ist nicht in der Lage die Inputparameter

35 3 Konzeption der Anbindung klassischer GIS an einen WPS 27 in Geodateninputlayer und sonstige Parameter zu unterscheiden, da er keine Kenntnis über ihre Bedeutung hat. Dementsprechend kann er auch nicht Geodateninputlayer in eine erweiterte WPS Form bringen. Ein GIS Experte sieht auf den ersten Blick, dass es sich beim Parameter input um den Layer handelt, der gepuffert werden soll, da er die Bedeutung interpretieren kann. Ein vollautomatisches Konvertieren ist also nicht möglich, ohne weitere Forschung zu betreiben (s. Kapitel 6). Die GIS Schnittstellen können maschinell in DescribeProcess Dokumente vortransformiert und bei Bedarf per Hand nachgearbeitet werden. Dieses Verfahren ist immer noch zeitsparender und weniger fehleranfällig als eine komplett händische Erzeugung. Falls eine maschinenlesbare Schnittstellenbeschreibung auf Seiten des GIS nicht vorhanden und auch nicht in den beschriebenen Wegen erzeugbar ist, ist ein Wrappen mit einer WPS Schnittstelle dennoch möglich. In dem Fall müssen sämtliche DescribeProcess Dokumente händisch erzeugt werden; auf eine automatisierte Erzeugung muss verzichtet werden Bestimmung des räumlichen Bezugssystems Bei einem derart generischen Dienst, wie dem WPS, mit dem aufgrund der Vielfalt der angebotenen Prozesse viele unterschiedliche Fragestellungen bearbeitet werden können, ist es für ein korrektes Ergebnis immanent wichtig, das richtige räumliche Bezugssystem zu ermitteln. Da dies vor dem eigentlichen Anfragezeitpunkt noch nicht bekannt ist, muss zur Laufzeit bestimmt werden, in welchem Bezugssystem die Eingabedaten vorliegen. Um Ergebnisse vergleichbar und korrekt zu erzeugen, müssen bei unterschiedlichen RBS Transformationen vorgenommen werden. Einen umfassenden Überblick über die theoretischen Hintergründe liefert Iliffe (2000). Das RBS kann durch zwei verschiedene Vorgehensweisen bestimmt werden: Manuelles Einfügen eines zusätzlichen Inputparameters, der das RBS beschreibt, Automatische Extraktion des RBS aus den jeweiligen Datenquellen. Ersteres ist relativ einfach zu lösen, wenn einzelne Anfragen gestellt werden und weitestgehend auf Service Chaining verzichtet wird. Unter der Voraussetzung, dass vom Benutzer das zu den Daten passende RBS angegeben wird, ist es ein sehr zuverlässiges Verfahren. Allerdings muss das Wissen über das entsprechende RBS vorhanden sein. Dies ist in vielen Fällen nicht einfach, wenn beispielsweise dezentrale GML

36 3 Konzeption der Anbindung klassischer GIS an einen WPS 28 Daten verwendet werden, für die nicht zwingend die Angabe eines RBS vorgeschrieben ist (Open Geospatial Consortium Inc., 2007c, S. 54 ff.). Beim WFS ist die Angabe zwar vorgeschrieben, jedoch kann diese auf verschiedenste Weise erfolgen (Open Geospatial Consortium Inc., 2005, S. 83 f.). Zusätzlich ist es schwierig, Prozessketten zu erzeugen, für die dann jeweils wieder per Hand ein Bezugssystem angegeben werden muss. Ebenfalls muss festgelegt werden, wie RBS eindeutig beschrieben werden. Selbst bei Verwendung von EPSG (European Petroleum Survey Group Geodesy) Codes muss die entsprechende Version der Datenbank definiert sein. EPSG Codes werden als Quasi-Standard vom Surveying and Positioning Committee der International Organisation of Oil & Gas Producers (OGP) gepflegt und veröffentlicht (Ogp, 2008). Mittels einer Zahlenkodierung wird ein Koordinatenreferenzsystem eindeutig identifiziert, inklusive Transformations- und Konvertierungsparametern für den Wechsel in ein neues Koordinatenreferenzsystem. Zweiteres ist ein komplizierteres Unterfangen. Für jede Datenquelle muss automatisch bestimmbar sein, welches Bezugssystem verwendet wird. Es muss also eine Programmlogik geben, die für jede beliebige Datenquelle (WCS, WFS, Shapedatei, etc.) ermitteln kann, welches Bezugssystem verwendet wird. Dies ist für GML Daten noch relativ einfach, da dort Angaben zum RBS gespeichert werden können, nach denen konkret gesucht werden kann. Bei Daten des OGC Web Coverage Service (WCS) kann man entweder ein RBS referenzieren oder gleich eine komplette Definition mitliefern (Open Geospatial Consortium Inc., 2006c, S. 7 f.). Zusätzlich ist die Angabe der Bezugssysteme im Kontext der OGC Dienste nicht zwingend vorgeschrieben, gleiches gilt für Shapedateien (Enviromental Systems Research Institute, Inc., 1998). Trotz dieser Heterogenitäten im Umgang mit RBS muss es Mechanismen geben, selbige zu ermitteln. Wenn diese Mechanismen bereits durch das GIS bereitgestellt werden, ist eine eigene Programmierung nicht erforderlich. Eine entsprechende Anpassung der Importund Exportfunktionalitäten für den einzelnen WPS Workspace entfällt trotzdem nicht. Beide Ansätze können nicht vermischt werden, da zur Erstellung des DescribeProcess Dokuments feststehen muss, ob der entsprechende RBS Parameter mitgegeben werden muss oder nicht. Eine Verkettung beider Ansätze - in der Art, dass erst überprüft wird, ob ein entsprechender zusätzlicher Parameter gegeben ist und falls nicht, automatisch ermittelt wird - ist denkbar, aber sehr kompliziert und mit viel Eigenimplementierung verbunden. Für beide Ansätze gilt ebenfalls: Wenn das RBS nicht schon in der Datengrundlage oder deren Metadaten enthalten ist, ist eine Bearbeitung nicht möglich oder es muss (falls vom GIS unterstützt) in einer unreferenzierten Umgebung

37 3 Konzeption der Anbindung klassischer GIS an einen WPS 29 operiert werden. Aufgrund der Möglichkeit, dass Daten auch unreferenziert prozessiert werden können, wird die automatische Bestimmung des RBS auf der technischen Ebene als optionale Eigenschaft betrachtet. Auf inhaltlicher Ebene und wenn Wert auf räumlich akurate Ergebnisse gelegt wird, ist der korrekte Umgang mit RBS eine mandatorische Eigenschaft. Longley et al. (2005, S. 125) schreiben: Many of the benefits of GIS rely on accurate georeferencing - the ability to link different items of information together through common geographic location; the ability to measure distances and areas on the Earth s surface, and to perform more complex forms of analysis; and the ability to communicate geographic information in forms that can be understood by others. Die gleiche Meinung vertreten auch Manning und Brown (2003) für GDI: If spatial data are not built on a solid positional foundation, problems with data compatibility and positional uncerteinty will arise. The ability of SDI to facilitate efficient collection, management, access and utilization is contingent upon having an accurate, efficient and well-maintained positional framework as the fundamental layer. Deshalb sei es dringend empfohlen nicht auf unreferenzierten Geodaten zu arbeiten. 3.3 Probleme bei der Anbindung Im vorangehenden Abschnitt werden Eigenschaften beschrieben, die ein GIS dafür qualifizieren, mit einem WPS Wrapper versehen zu werden. Darüberhinaus gibt es noch drei Probleme, die es zu lösen gilt: Zustandslos vs. zustandsbehaftet - Wie kommt man vom zustandsbehafteten GIS zum zustandslosen WPS? Benötigte und nicht benötigte Funktionalitäten eines Geoinformationssystems im WPS - Welche Funktionalitäten können im WPS nicht verwendet werden? Softwaretest - Wie lässt sich das Wrapping auf Korrektheit und Zuverlässigkeit überprüfen? Einzelheiten finden sich in den folgenden Abschnitten.

38 3 Konzeption der Anbindung klassischer GIS an einen WPS Zustandslos vs. zustandsbehaftet Klassische GIS sind in der Regel zustandsbehaftet. Für die Bearbeitung von Aufgaben stehen sogenannte Workspaces zur Verfügung. Diese ermöglichen, dass Zwischenergebnisse gespeichert werden können und dass Arbeit unterbrochen werden kann, um zu einem späteren Zeitpunkt wieder aufgenommen zu werden. Im Gegensatz dazu fordert die allen OGC Spezifikationen zugrundeliegende OpenGIS Abstract Specification: For simplicity it is desired that a service be stateless, i.e., that a service invocation be composed of a single request-response pair with no dependence on past or future interactions. (Open Geospatial Consortium Inc., 2002, S. 22). Deshalb ist auch der WPS als zustandsloser Service spezifiziert worden. Mit einer Einschränkung: Die WPS Spezifikation erlaubt es, Ergebnisse für einen späteren Abruf auf dem Server zu belassen (Parameter storesupported, Open Geospatial Consortium Inc. (2007d, S. 22)). Da dies aber nicht erneute und parallele Anfragen beeinflusst, ist ein WPS trotzdem als zustandsloser Service zu betrachten. Ein Workspace umfasst neben den eigentlichen zu bearbeitenden Daten Angaben über räumliche Bezugssysteme und sonstige Metadaten, die zur Bearbeitung notwendig sind. Die Speicherung erfolgt auf persistentem Speicher, beispielsweise der Festplatte. Meistens werden Daten in einem nativen Datenformat vorgehalten, z. B. eine Personal Geodatabase bei ArcGIS oder einer Map Location bei GRASS. Das macht eine entsprechende Konvertierung in externe Formate notwendig, sofern die Daten beispielsweise in einer GDI weiterverwendet werden sollen. Ein einmal angelegter Workspace kann für eine unbegrenzte Anzahl von Aufgaben, die mit den eingefügten Daten lösbar sind, verwendet werden. Um erfolgreich GIS Funktionalitäten mit einer WPS Schnittstelle zu wrappen, muss dieser Widerspruch überwunden werden. Auf der einen Seite braucht das GIS einen Workspace um Aufgaben zu erfüllen, und auf der anderen Seite darf der WPS nach Bearbeitung einer Anfrage und dem Rückschicken einer Antwort keine darauf bezogenen Dateien speichern. Für jede Anfrage muss also ein solcher Workspace on-the-fly generiert werden, der nach Bearbeitung der Anfrage wieder gelöscht wird. Aufgrund der Heterogenität der möglichen Anfragen ist eine Wiederverwendung eines Workspace meistens nicht sinnvoll. Für die Erzeugung eines Workspaces sollte das RBS und das Format der zu importierenden Daten bekannt sein (s. auch Abschnitt 3.2.4), ebenso das Exportdatenformat. Wenn es sich um Rasterdatenprozessierungen handelt, spielt die Auflösung und eventuelle Größe von einzelnen Kacheln ebenfalls ein wichtige Rolle.

39 3 Konzeption der Anbindung klassischer GIS an einen WPS 31 Ein GIS definiert nicht explizit, welche Datenformate für einen bestimmten Prozess importiert und exportiert werden können. Stattdessen steht eine Reihe von Eingabeund Ausgabewerkzeugen zur Verfügung, die die entsprechenden Daten in das native GIS Datenformat konvertieren und damit im Workspace verfügbar machen, und zur Weiterverarbeitung in ein beliebiges Format exportieren. Im WPS wird durch das DescribeProcess Dokument hingegen genau definiert, welche Input- und Outputdatenformate vom jeweiligen Prozess unterstützt werden. Bei der on-the-fly Generierung des Workspace muss also nicht nur beachtet werden, welcher Prozess gestartet wird, sondern auch, welche Import- und Exportwerkzeuge verwendet werden müssen. Es mag verwundern, dass das Workspace Konzept auch in einer Web Service basierten Umgebung noch notwendig ist. Aber auch für eine Prozessierung mit eigener Implementierung der GIS Funktionalitäten ist es in den meisten Fällen notwendig temporäre Dateien anzulegen. Da auch ein Workspace meistens nur aus einzelnen Dateien besteht, ist der Mehraufwand kaum größer. Problematischer ist hingegen der erhöhte Aufwand für Im- und Export der Dateien, gerade im Fall des Chaining von mehreren Prozessen. Für jede einzelne Anfrage bzw. für jeden Prozess müssen Datenkonvertierungen durchgeführt werden, obgleich es eventuell (je nach Problemstellung) möglich wäre, die Dateien nur einmal in den Workspace zu importieren und die verschiedenen Prozesse dort durchlaufen zu lassen. Wiederholter Im- und Export von Daten und das damit verbundene Parsen kann zu Performanzeinbußen führen, wenn importierte Daten theoretisch wiederverwendbar sind. Es sei explizit erwähnt, dass eine Wiederverwendung nicht möglich ist, ohne die WPS Spezifikation zu verletzen und damit die Interoperabilität anzugreifen. Dieses Problem wird in Kapitel 6 wieder aufgegriffen. Sollte es sich bei dem anzubindenden GIS um eine GIS Bibliothek handeln (beispielsweise Geotools oder die JTS Topology Suite), ist die Verwendung eines Workspace im oben beschriebenen Sinn nicht erforderlich, eine Konvertierung der Geodaten in die entsprechenden Datenstrukturen der Bibliothek hingegen schon Benötigte und nicht benötigte Funktionalitäten eines Geoinformationssystems in einer Geodateninfrastruktur Wie in Kapitel 1 beschrieben bietet ein GIS per Definition ein breites Spektrum an Funktionalitäten aus den Bereichen Visualisierung, Analyse, Modellierung, Dateneingabe und Datenverwaltung. Nicht alle Funktionalitäten werden in einer GDI benötigt. Dazu gehören:

40 3 Konzeption der Anbindung klassischer GIS an einen WPS 32 Interaktive Funktionalitäten, Visualisierungsfunktionalitäten, Datenverwaltungsfunktionalitäten. Sollte das GIS Funktionalitäten anbieten, die zur Laufzeit noch zusätzliche Informationen des Benutzer benötigen (interaktive Funktionalitäten), können diese im WPS nicht verwendet werden. Dafür gibt es zwei Gründe. Erstens kann ein Prozess nicht unterbrochen, der Benutzer also nicht nach zusätzlichen Eingaben gefragt werden, um dann den Prozess an genau der Stelle mit den neuen Eingaben fortzusetzen. Das würde die Zustandslosigkeit verletzen (siehe Abschnitt 3.3.1). Daraus ergibt sich, dass zweitens das GIS völlig unüberwacht steuerbar sein muss (siehe Abschnitt 3.2.1). Bei einer unüberwachten Steuerung müssen alle Eingabeparameter vor der Laufzeit bekannt sein, eine spätere Interaktion zur Laufzeit ist ausgeschlossen. Funktionalitäten zur Visualisierung im Desktop GIS werden ebenfalls nicht benötigt, da das GIS serverseitig ausgeführt wird und der verwendete Client für die Visualisierung verantwortlich ist. Dazu zählen explizit nicht Datenexportfunktionalitäten, die Visualisierungen ermöglichen, beispielsweise wenn ein Vektor- mit einem Rasterdatensatz verschnitten werden und das Ergebnis in einem Bildformat (z. B. png) angezeigt werden soll. Zu den Datenverwaltungsfunkionalitäten zählen z. B. das Duplizieren oder Löschen von Layern, das Ändern von Koordinatenreferenzsystemen des Workspace oder sonstige Administrationskommandos. Aufgrund der Zustandslosigkeit des WPS sollten Workspaces nicht von außen her administrierbar sein. Deshalb sollten derartige Funktionalitäten auch nicht von außen verfügbar sein. Intern kann sich durchaus eine andere Situation ergeben, beispielsweise wenn bestimmte Kommandos zur Erzeugung eines Workspaces unerlässlich sind. Näheres zu den Implikationen der Zustandslosigkeit ist in Abschnitt beschrieben. Das Problem benötigte und nicht benötigte GIS Funktionalitäten zu unterscheiden, ist ein semantisches. Bei einer automatischen Generierung von Prozessbeschreibungen für den WPS kann der Rechner nicht selbst entscheiden. Menschliche GIS Expertise ist notwendig. Bei einer geschickten Modellierung einer WPS Implementierung können aber im Nachhinein alle nicht benötigten Prozesse wieder entfernt werden. Falls die entsprechenden Funktionalitäten im Desktop GIS in irgendeiner Form schon vorsortiert sind, können vorher schon bestimmte Kategorien von der automatischen Generierung ausgeschlossen werden.

41 3 Konzeption der Anbindung klassischer GIS an einen WPS Softwaretest Für technische und kommerzielle Softwaresysteme ist die Qualität der Software zum entscheidenden Faktor für den Erfolg von Produkten und Unternehmungen geworden. [...] Ein Mittel dies zu erreichen, ist das systematische Prüfen und Testen der entwickelten Software (Spillner und Linz, 2004, S. 1). Dem Testen von Web Services in einer SOA wird eine große Bedeutung beigemessen. Erl schreibt: Given their generic nature and potential to be reused and composed in unforseebale situations, services are required to undergo rigorous testing prior to deployment into a production environment (Erl, 2005, S. 360). Beim Testen wird überprüft, ob das System fehlerfreie Ergebnisse liefert. Ein Fehler liegt dann vor, wenn das Systemverhalten zur Laufzeit (Istverhalten) unter zu definierenden Vor- und Nachbedingungen vom modellierten Sollverhalten abweicht und somit die Anforderungen ans Softwaresystem nicht erfüllt werden. Normalerweise werden beim Testen stichprobenhaft reguläre Fälle und alle potentiell fehleranfälligen Randbereiche oder Extremfälle untersucht. Testen ist nicht mit Debugging zu verwechseln. Debugging ist ein Verfahren zur Fehlerbehebung durch den Softwareentwickler, Testen dient zum Aufdecken eben jener Fehler. (Spillner und Linz, 2004, S. 7 ff.) Testen findet in unterschiedlichen Abstraktionsstufen statt. Zuerst wird im Komponententest überprüft, ob einzelne Komponenten ihren Spezifikationen entsprechen. Über den Integrationstest, der der Überprüfung von Komponentengruppen dient, wird im Systemtest überprüft, ob das System als Ganzes einwandfrei funktioniert. Im anschließenden Abnahmetest wird das System auf die Erfüllung der vom Kunden definierten Anforderungen hin untersucht. (Spillner und Linz, 2004, S. 39) Sowohl beim klassischen GIS als auch beim WPS handelt es sich um sehr flexible und somit komplexe Applikationen. Es ist unerlässlich Tests durchzuführen, um zu überprüfen, ob alle Teile des Systems korrekt zusammenarbeiten. Gerade bei in situ heterogenen Geodaten muss das gelieferte Ergebnis überprüft werden. Unvorhersehbare Situationen entstehen ständig, da nicht vorausgesagt werden kann, welche Art von Daten der Benutzer oder ein anderer Web Service zur Bearbeitung liefert. Wie oben beschrieben, ist das Wrapping eines GIS mit einer WPS Schnittstelle mit vielen Arbeitsschritten verbunden. Gerade bei der Verkettung von Prozessen müssen die Daten oft im- und exportiert werden. Die möglichen Im- und Exportdatenformate werden durch das DescribeProcess Dokument definiert und entweder durch XML Datentypen, XML Schema oder MIME-Typen maschinenlesbar beschrieben. Diese vorgegebenen Datenformate werden gerade von älteren GIS nicht zwangsläufig verstanden

42 3 Konzeption der Anbindung klassischer GIS an einen WPS 34 und müssen durch entsprechende Parser noch einmal in für das GIS verständliche Datenformate umgewandelt werden. Bei der hohen Anzahl der Arbeitsschritte oder nur minimal fehlerhaften Parsern kann schnell Informationsverlust auftreten. Dies kann zu falschen Ergebnissen führen. Im klassischen Fall Desktop GIS ist ein derartiges Parsen normalerweise nicht erforderlich. Dort wird einmal in das native Datenformat importiert und von da an nur noch auf diesem Format weitergearbeitet. Die Fehleranfälligkeit ist hier deutlich niedriger, aber dennoch auch vorhanden. Testen kann auf allen Systemebenen durchgeführt werden. Beim Wrapping ist der Integrationstest besonders wichtig, da überprüft werden muss, ob die Ergebnisse, die das GIS in der klassischen Verwendung produziert, mit denen über die WPS Schnittstelle ermittelten, übereinstimmen. Tests auf tieferen Ebenen (Komponententest) können ebenfalls durchgeführt werden, sind aber im ersten Schritt zu vernachlässigen. Beim Auftreten von Fehlern im Integrationstest werden derartige feingranularere Tests notwendig, damit die Fehlerquelle eingegrenzt werden kann. Beim Testen wird der Ergebnisdatensatz gegen ein auf anderem Wege produziertes Referenzergebnis validiert. Im Falle des mit einer WPS Schnittstelle ausgestatteten klassischen GIS wird das Referenzergebnis vom GIS im normalen Betrieb (also meist Desktopbetrieb) erzeugt. Da nicht davon ausgegangen werden kann, dass das zugrunde liegende GIS und seine Algorithmen quelloffen zur Verfügung stehen, wird angenommen, dass das GIS mathematisch und semantisch einwandfreie Ergebnisse liefert. Der identische Inputdatensatz des Referenzergebnisses wird dann als Eingabedatensatz für den WPS verwendet und mit den gleichen Parametern und der gleichen Funktionalität ebenso prozessiert. Wenn das Ergebnis mit dem Referenzergebnis übereinstimmt, kann davon ausgegangen werden, dass für diesen Algorithmus mit dem entsprechenden Datenformat ein einwandfreies Ergebnis erzielt wird. Sollte es sich bei dem anzubindenden GIS nicht um ein eigenständig lauffähiges System handeln (beispielsweise eine Funktionsbibliothek), muss eine entsprechende Implementierung in einer für die Bibliothek nutzbaren Umgebung erzeugt werden. Sollte es sich (wie in der vorliegenden Arbeit) um ein quelloffenes GIS handeln, kann noch ein zusätzlicher Schritt durchgeführt werden. Mit der Fachkenntnis über die entsprechenden Algorithmen und Datenstrukturen und Programmiererfahrung in der dem GIS zugrundeliegenden Programmiersprache kann nachvollzogen werden, wie das Referenzergebnis zustande gekommen ist. Zusätzlich zum funktionalen Testen von Web Services sollten noch weitere Untersuchungen durchgeführt werden. Dazu zählen in erster Linie Performanz- und Lasttests

43 3 Konzeption der Anbindung klassischer GIS an einen WPS 35 (Erl, 2005, S. 368). Performanztests überprüfen die Verarbeitungsgeschwindigkeit von Prozessen, d. h. wie lange der Benutzer auf das von ihm gewünschte Ergebnis warten muss. Friis-Christensen et al. (2007) verweisen auf eine Studie von Nah: Although TWT [Tolerable Waiting Time] can vary under different circumstances and contexts, the findings from this study suggest that most users are willing to wait for only about two seconds for simple information retrieval tasks on the Web (Nah, 2004). Derartig niedrige Latenzzeiten können bei der Bearbeitung von Geodaten in den meisten Fällen nicht erzielt werden, jedoch zeigt die Studie gut, wie relevant Wartezeiten für Benutzer sind. Mit Lasttests kann untersucht werden, was bei konkurrierendem Zugriff auf die WPS Schnittstelle - und damit das unterliegende GIS - passiert. Wird die Bearbeitungszeit nur deutlich verlängert oder stürzt das GIS eventuell ab? Hier sei auf die in Abschnitt beschriebene Multitaskingfähigkeit verwiesen. 3.4 Zusammenschau und Schlussfolgerung Abschnitt liefert eine abschließende Gegenüberstellung und Zusammenfassung der Eigenschaften, die ein monolithisches GIS mitbringen muss, damit es mit einer WPS Schnittstelle ergänzt werden kann. Eine Referenzarchitektur wird in Abschnitt vorgestellt. In Abschnitt wird erläutert, warum GRASS als ein Kandidat für die exemplarische Entwicklung ausgewählt worden ist Mandatorische und optionale Eigenschaften des Geoinformationssystems Diese Arbeit stellt kein generelles Rahmenwerk zur Verfügung, um beliebige GIS Funktionalitäten mit einer WPS Schnittstelle auszustatten, sonder beschränkt sich auf die dafür benötigten Eigenschaften und eine entsprechende Konzeption, die je nach GIS umgesetzt werden muss. Im Folgenden wird zusammengefasst, welche mandatorischen und optionalen Konventionen / Eigenschaften / Attribute oder Qualitäten ein GIS auszeichnen müssen, damit es sich für eine WPS Schnittstelle qualifiziert (s. Abschnitt 3.2). Tabelle 2 gibt einen Überblick über Eigenschaften und deren Status. Für den WPS werden die entsprechenden Eigenschaften ebenso aufgeführt, um die Vergleichbarkeit zu gewährleisten. Der Fokus liegt allerdings auf den Eigenschaften des GIS. Die Untersuchung hat ergeben, dass das GIS nur eine mandatorische Eigenschaft erfüllen muss: Die unüberwachte Steuerung und Ausführung von Einzelfunktionalitäten. Die weiteren optionalen Eigenschaften lassen sich in zwei Gruppen aufteilen: Eigen-

44 3 Konzeption der Anbindung klassischer GIS an einen WPS 36 Tabelle 2 Eigenschaften von GIS und WPS bezogen auf die Tauglichkeit als WPS. Unterschieden wird in mandatorische und optionale Eigenschaften. GIS WPS Programmierbare Prozesse mandatorisch mandatorisch Multitaskingfähigkeit optional optional Maschinenlesbare Schnittstellenbeschreibung Bestimmung des RBS optional (bei automatischer Erzeugung von DescribeProcess Dokumenten mandatorisch) optional (technisch) / mandatorisch (inhaltlich) mandatorisch optional (technisch) / mandatorisch (inhaltlich) schaften, die den zuverlässigen, korrekten und stabilen Ablauf gewährleisten, und eine Eigenschaft, die eine automatische Generierung von WPS Prozessen ermöglicht. Für einen sinnvollen Einsatz sind gewisse Qualitätsansprüche zu berücksichtigen. Geodaten raumbezogen zu analysieren ohne ein räumliches Bezugssystem zu beachten, ist in den meisten Fällen nicht sinnvoll (s. Abschnitt 3.2.4). Gleiches gilt für eine fehlende Multitaskingfähigkeit, da es in einer SOA permanent zu dem Fall kommen kann, dass zwei Anfragen zeitgleich gestellt und prozessiert werden sollen. Für die semi-generische Erzeugung von WPS Prozessen ist die maschinenlesbare Beschreibung der GIS Funktionalitäten unverzichtbar. Semi-generisch deshalb, weil selbst mit einer maschinenlesbaren Schnittstelle bestimmte semantische Probleme nicht gelöst werden können (Details beschreibt Abschnitt 3.2.3) Referenzarchitektur Aus den genannten Eigenschaften und zu lösenden Problemen ergibt sich eine Referenzarchitektur. Abbildung 2 zeigt exemplarisch, wie eine Execute Anfrage des Client über den WPS an das GIS weitergeleitet wird. Für die Bearbeitung in einem temporären Workspace werden die Daten über GIS-eigene Funktionalitäten importiert. Nach der Prozessierung findet der Export der Daten in das vom Benutzer gewünschte Format ebenfalls mit GIS-eigenen Funktionalitäten statt. Das vom GIS erzeugte Ergebnis wird dann über den WPS wieder zurück an den Client geschickt. Aus Abbildung 2 ist ersichtlich, dass der WPS nur als Wrapperservice in Erscheinung tritt und bis auf die Verarbeitung der WPS Anfragen keine weiteren Prozessierungen vornimmt. Dafür ist das GIS im vollem Umfang (inklusive Import und Export) selbst zuständig.

45 3 Konzeption der Anbindung klassischer GIS an einen WPS 37 Abbildung 2 Referenzarchitektur für die Anbindung von GIS Funktionalitäten an eine WPS Schnittstelle. Beispielhaft wird eine Execute Anfrage bearbeitet. Vor der Prozessierung der Daten im temporären GIS Workspace muss mit GIS-eigenen Funktionalitäten der Import in den Workspace stattfinden. Die generierte Antwort wird ebenso mit GIS-eigenen Exportfunktionalitäten exportiert und im vom Nutzer gewünschten Datenformat über den WPS an den Client zurückgeliefert. (Eigene Darstellung) GRASS als anzubindendes Geoinformationssystem Auf Grundlage der in diesem Kapitel beschriebenen mandatorischen und optionalen Eigenschaften (Abschnitt 3.2) und der angesprochenen Probleme (Abschnitt 3.3), hat sich sehr schnell herausgestellt, dass GRASS ein geeignetes GIS für eine exemplarische Implementierung ist. Tabelle 3 gibt einen ersten Überblick über die zu erfüllenden Eigenschaften, deren Umsetzung in GRASS und die möglichen Problemlösungsstrategien. GRASS ist hochgradig modularisiert: Due to the modular character of GRASS, a monolithic GRASS program does not exist. In fact, GRASS is a collection of modules which are run in a special environment. The structure allows GRASS to be completely controlled from outside through scripts (Neteler und Mitasova, 2007, S. 338). Das Zitat zeigt, dass zwei wichtige Voraussetzungen gegeben sind.

46 3 Konzeption der Anbindung klassischer GIS an einen WPS 38 Tabelle 3 Eigenschaften von GRASS und die Art der Umsetzung und Probleme und deren Lösung in GRASS bzgl. der Erweiterung um eine WPS Schnittstelle. Eigenschaft Programmierbare Prozesse (mandatorisch) Multitaskingfähigkeit (optional) Maschinenlesbare Schnittstellenbeschreibung (optional) Automatische Bestimmung des RBS (optional) Problem Erzeugung von Workspaces Unterscheidung von benötigten Funktionen Erzeugung von Referenzergebnissen zum Testen Umsetzung in GRASS ja, skriptgesteuert ja, durch Modularisierung ja, durch XML-Beschreibung eingeschränkt, hängt von entsprechender Funktionalität und verwendeter Datengrundlage ab Lösung in GRASS ja, skriptgesteuert gut, da schon vorsortiert in situ Erstens kann GRASS komplett durch Shell Skripte konfiguriert und ausgeführt werden. Damit ist die einzige wirklich mandatorische Eigenschaft (s. Abschnitt 3.4.1) erfüllt. Zweitens wird durch die Modularisierung erreicht, dass keine zentrale GIS Instanz (das monolithic GRASS program ) vorhanden ist, in der alle Prozesse gesteuert werden, sondern jedes Modul für sich angesprochen werden kann, wenn die entsprechende Umgebung gesetzt ist. Das monolithic GRASS program ist nicht zu verwechseln mit dem Begriff des monolithischen GIS, wie in Kapitel 1 beschrieben. Die einzelnen entstehenden Betriebssystemprozesse werden durch selbiges gesteuert. Dies ist die bevorzugte der beiden beschriebenen Multitasking Varianten (s. Abschnitt 3.2.2). Auch eine XML-basierte Schnittstellenbeschreibung kann von GRASS für jedes Modul erzeugt werden. Durch das Kommando <grassmodule> --interface-description kann eine entsprechende, durch eine standardisierte DTD (Document Type Definition) spezifizierte Beschreibung erzeugt werden (Neteler und Mitasova, 2007, S. 333). Damit steht einer (semi-)automatischen Transformation in ein DescribeProcess Dokument, wie in Abschnitt erläutert, nichts mehr im Wege. Einzig die automatische Bestimmung des RBS (Abschnitt 3.2.4) ist in GRASS nur bedingt möglich. Hier wird durch die zu importierenden Datengrundlage bestimmt, ob das RBS automatisch geparst werden kann oder nicht. Für shape Dateien ist dies relativ einfach, da diese, sofern sie denn referenziert sind, das RBS in einer *.prj Datei

47 3 Konzeption der Anbindung klassischer GIS an einen WPS 39 ablegen, die ausgelesen werden kann. Für GML Dateien oder Streams von Feature Services ist dies nicht ohne weiteres möglich, da hier die Angabe des RBS sehr heterogen ausfällt. Mit ein wenig Aufwand und der Entwicklung eines entsprechenden zusätzlichen Parsers kann dieses Problem allerdings gelöst werden. Wie oben beschrieben, kann GRASS komplett skriptgesteuert ausgeführt werden. Das impliziert auch die Erzeugung von entsprechenden GRASS Map Locations (Abschnitt 3.3.1), die mit simplen Betriebssystemkommandos als Verzeichnisstruktur mit zusätzlichen Dateien generiert werden können. Auch ein Teil der nicht benötigten Funktionalitäten kann direkt identifiziert werden, da GRASS Module schon durch ein entsprechendes Präfix im Namen gekennzeichnet sind. Beispielsweise können alle nicht benötigten Visualisierungsfunktionalitäten (s. Abschnitt 3.3.2) im Voraus erkannt und von der automatischen Prozesserzeugung ausgeschlossen werden. Ein Teil der nicht benötigten Funktionalitäten muss allerdings auch weiterhin mit Expertenwissen aussortiert werden. Da es sich bei GRASS um ein eigenständig lauffähiges GIS handelt, ist die Erzeugung von Referenzergebnissen für das Testen (Abschnitt 3.3.3) kein Problem. Anforderungen an die konkrete Umsetzung mit GRASS und dem 52 North WPS werden im folgenden Kapitel beschrieben, ebenso Details zur konkreten Implementierung und Problemlösung.

48 4 Implementierung 40 4 Implementierung Im folgenden werden die für die Implementierung verwendeten Softwarekomponenten vorgestellt. Desweiteren wird die verwendete Architektur beschrieben, und die Umsetzung der in Kapitel 3 beschriebenen Konzeption im Detail aufgezeigt. 4.1 Verwendete Software Bei der verwendeten Software handelt sich um schon bestehende Komponenten, die in einigen Punkten angepasst bzw. erweitert werden müssen, damit ein erfolgreiches Wrapping von GIS Funktionalitäten mit einer WPS Schnittstelle durchführbar wird. Für die Kernkomponenten, das Desktop GIS und den Web Processing Service, wird ausschließlich Open Source lizenzierte Software verwendet. Durch den frei verfügbaren und ausdrücklich anpassbaren Quellcode ist es möglich, Prozessabläufe und zugrundeliegende Datenstrukturen innerhalb der Software besser zu verstehen, diese effizienter anzupassen und Ergebnisse besser zu kontrollieren. Zudem entspricht es der wissenschaftlichen Natur der Arbeit, dass Ergebnisse von Algorithmen transparent nachvollziehbar sind (Neteler und Mitasova, 2007, S. 2) und eigene Erkenntnisse wieder an die Wissenschaft zurückgegeben werden können, ohne dass lizenzrechtliche Probleme oder Kosten entstehen. Neteler und Mitasova (2007, S.1) schreiben weiter, dass Open Source GIS neben den weit verbreiteten proprietären Lösungen eine wichtige Rolle in der Weiterentwicklung von GIS Technologien spielen, indem sie experimentelle Ansätze fördern. Diesen Ansprüchen wird Genüge getan. Anpassungen und Erweiterungen der Software (in diesem Fall des Web Processing Service) erfolgen durch die objektorientierten Programmiersprachen Java (Ullenboom, 2008) und Groovy (Koenig et al., 2007), deren Kerne ebenfalls Open Source Lizenzen unterliegen. Grundlagen zur objektorientierten Programmierung können umfassend bei Meyer (1997) und für den Geoinformatikbereich bei Schneider (1996) und Worboys (1994) nachgelesen werden Geographic Resources Analysis Support System - GRASS Bei GRASS ( handelt es ich um eines der größten und bekanntesten klassischen Desktop GIS. GRASS bietet eine hohe Anzahl von Geoprozessierungsfunktionalitäten aus dem Vektor- und Rasterdatenbereich. Das schließt Funktionalitäten für räumliche Analysen, Modellierung, Bildverarbeitung und fortgeschrittene Visualisierung mit ein. (Neteler und Mitasova, 2007, S. XI)

49 4 Implementierung 41 GRASS ist ein modular aufgebautes GIS, sprich jede einzelne Funktionalität ist als Modul gekapselt. Insgesamt existieren mehr als 350 Module für Management, Prozessierung, Analyse und Visualisierung von georeferenzierten Daten (Neteler und Mitasova, 2007, S. 3), also genau die klassischen GIS Funktionalitäten wie in Abschnitt 2.3 beschrieben. GRASS ist unter der GPL (General Public License) lizenziert und wird als OSGeo (Open Source Geospatial Foundation, Projekt geführt (Neteler und Mitasova, 2007, S. 2 f.). Durch die Verwendung von GRASS ist der WPS nicht mehr plattformunabhängig, da GRASS nur unter Unix ähnlichen Betriebssystemen (z. B. Linux) lauffähig ist. In der gerade erschienenen Version 6.3 von GRASS ist erstmals eine native Unterstützung für Windows umgesetzt worden. Dies kann in zukünftigen Studien mit einbezogen werden North Web Processing Service Der 52 North Web Processing Service ( implementiert Version der WPS Spezifikation (Open Geospatial Consortium Inc., 2007d). Es handelt sich um einen auf Servlets basierten Dienst, der komplett in Java realisiert wurde. Er unsterstützt sämtliche von der Spezifikation geforderten Merkmale, inklusive der asynchronen Kommunikation und rudimentärer SOAP und WSDL Unterstützung. Durch die modulare API (Application Programming Interface) und den generischen Ansatz ist es sehr einfach möglich, weitere Prozesse hinzuzufügen und so die Funktionalität zu erweitern (Schäffer, 2007, S. 41). Zusätzlich zum Dienst gibt es einen auf udig (User-friendly Desktop Internet GIS) aufbauenden generischen Client, dessen Architektur und Funktionsweise von Foerster und Schäffer (2007) ausführlich beschrieben wird. Der 52n WPS unterliegt einem dualen Lizenzmodell. Eine Verwendung unter der GPL ist ebenso möglich wie die Nutzung über eine kostenpflichtige kommerzielle Lizenz. Alternativ wurde die Verwendung von PyWPS ( org) in Erwägung gezogen, das auch die Möglichkeiten bietet, GRASS Funktionalitäten über eine WPS Schnittstelle verfügbar zu machen. Die Entscheidung für die 52n Implementierung erfolgte aus rein pragmatischen Gründen. Die 52n Entwickler sind vor Ort verfügbar, und eine Einarbeitung in eine neue Programmiersprache war nicht

50 4 Implementierung 42 notwendig. Zudem unterstützt der 52n WPS zum Zeitpunkt der Arbeit als einziger WPS die Spezifikation in der Version Systemanforderungen Use Cases eignen sich u. a. dazu, konkrete funktionale Anforderungen an das System zu formulieren (Cockburn, 2003, S. 15 und S.22). Sie dienen als Grundlage für die in diesem Kapitel beschriebene Implementierung. Use Cases werden definiert als Übereinkunft, die zwischen den Stakeholdern eines Systems über dessen Verhalten getroffen wird (Cockburn, 2003, S. 15). Balzert (2000, S. 126) spricht ebenfalls von Uses Cases als Synonym von Geschäftsprozessen, die auf der einen Seite die Funktionalität eines Produkts (Geschäftsprozess im Kleinen), als auch Abläufe innerhalb eines Unternehmens beschreiben (Geschäftsprozess im Großen). Cockburn (2003, S. 22) unterscheidet in System-Use-Cases für die zugrundeliegende Systemebene, die die Anforderungen für Software beschreiben, und Geschäfts-Use-Cases für die Übersichtsebene, die Vorgänge innerhalb eines Unternehmens aus der Sicht der Beteiligten beschreiben. Aufgrund der besseren Eingänglichkeit werden im Folgenden die Begriffe von Cockburn verwendet. Das Szenario wird anhand eines Geschäfts-Use-Case beschrieben, der die Anforderungen an das System aus externer Sicht definiert. Parallel dazu wird mit zwei System- Use-Cases gezeigt, was innerhalb der Software als Zusammenspiel mit den in diesem Kapitel beschriebenen Kompononenten geschieht. Sowohl Balzert (2000, S. 138) als auch Cockburn (2003, S. 15 und S. 160) schreiben, dass Use Cases so zu formulieren sind, dass sie jemand ohne Spezialkenntnisse, z. B. der Auftraggeber, verstehen kann. Auf zusätzliche graphische Hilfsmittel wie Flussoder Sequenzdiagramme oder Petri-Netze kann verzichtet werden, da sie Spezialkenntnisse erfordern und meistens in der Regel nicht detailliert genug sind, um einen Use Case ausreichend zu formulieren (Cockburn, 2003, S. 15 und S. 160). Der Aussage folgend, dass einfacher Text die beste Darstellungsform (Cockburn, 2003, S. 15) bietet, und dem Hinweis: Verfassen Sie Use Cases lieber auf Textgrundlage (Cockburn, 2003, S. 290), wird in dieser Arbeit auf graphische Hilfsmittel bei der Use Case Beschreibung verzichtet.

51 4 Implementierung System-Use-Case I - Vektorfunktionalitäten des 52 North WPS-GRASS nutzen Im Folgenden wird in einem System-Use-Case ein Standardablauf beschrieben, den das System ausführen können soll. Der unterstrichene Bereich verweist auf den zweiten System-Use-Case. Primärakteur GIS Experte. Umfang 52 North WPS mit angebundenem GRASS, udig WPS Client. Ebene Ziel auf Systemebene. Stakeholder und Interessen GIS-Experte - Analyseergebnis einer Vektorfunktionalität. Vorbedingungen Die zu analysierenden Vektordaten liegen auf einem WFS vor. Eine Internetverbindung ist vorhanden. Der WPS Client und der WPS sind gestartet. Entsprechende WPS Prozesse sind aus der GRASS Schnittstellenbeschreibung semiautomatisch erzeugt und von einem GIS-Experten nachgearbeitet worden. Nachbedingung Das Ergebnis der Analyse im GML Format kann in beliebigem Client visualisiert werden. Standardablauf 1. Der GIS-Experte übergibt dem Client die URL des WPS. 2. Der Client sendet eine GetCapabilities Anfrage an den WPS. 3. Der WPS sendet ein Capabilities Dokument an den Client zurück. 4. Der Client entnimmt dem Capabilities Dokument die Namen der verfügbaren Prozesse und zeigt sie an. 5. Der GIS-Experte wählt den gewünschten Prozess aus. 6. Der Client stellt für den gewählten Prozess eine DescribeProcess Anfrage an den WPS.

52 4 Implementierung Der WPS liefert ein entsprechendes DescribeProcess Dokument als Schnittstellenbeschreibung an den Client zurück. 8. Der Client präsentiert dem GIS-Experten eine Eingabemaske, die sich an den geforderten Parametern des DescribeProcess Dokuments orientiert. 9. Der GIS-Experte füllt die Eingabemaske aus. 10. Der Client schickt die Werte aus der Eingabemaske als Execute Anfrage zum WPS. 11. Der Web Processing Service bearbeitet die Execute Anfrage für Vektordaten und schickt das entsprechende Ergebnis zurück. Erweiterungen Für den Fall falscher Eingaben oder anderer Fehlfunktionen wird die Verarbeitung abgebrochen oder neu gestartet. Aufgrund einer Fülle von möglichen Fehlerquellen würde die konkrete individuelle Behandlung den Rahmen der Arbeit sprengen. Im folgenden System-Use-Case wird beschrieben, was passiert, wenn an den WPS eine Execute Anfrage gestellt wird System-Use-Case II - Web Processing Service verarbeitet die Execute Anfrage für Vektordaten Der zweite System-Use-Case geht mehr ins Detail. Er beschreibt den internen Ablauf bei der Abarbeitung einer Execute Anfrage, inklusive dem Zusammenspiel der einzelnen WPS Komponenten. Primärakteur WPS. Umfang 52 North WPS mit angebundenem GRASS, Applikationsserver, Betriebssystem Ebene Ziel auf Systemebene. Stakeholder und Interessen WPS - Abarbeitung der Anfrage.

53 4 Implementierung 45 Vorbedingungen Die zu analysierenden Vektordaten liegen auf einem WFS vor. Eine Internetverbindung ist vorhanden. Der WPS ist gestartet. Entsprechende WPS Prozesse sind aus der GRASS Schnittstellenbeschreibung semi-automatisch erzeugt und von einem GIS-Experten nachgearbeitet worden. Nachbedingung Der Client verarbeitet das Ergebnis nach Belieben (z. B. Visualsierung). Standardablauf 1. Der Applikationsserver erhält eine Anfrage an den WPS und leitet sie an das WPS Servlet weiter. 2. Das WPS Servlet erkennt, dass es sich um eine Execute Anfrage handelt und erzeugt einen entsprechenden RequestHandler. 3. Der RequestHandler erkennt, dass es sich um einen GRASS Prozess handelt und startet einen GrassInputHandler, der für die Verarbeitung und Weitergabe der Eingabeparameter an den GrassVectorAlgorithm zuständig ist. 4. Der generische GrassVectorAlgorithm beginnt das im Nachhinein auszuführende Betriebssystemskript zu erzeugen: a) Mit Betriebssystemoperationen wird die entsprechende GRASS Map Location (der GIS Workspace) im Dateisystem erzeugt. b) Die vom GrassInputHandler übergebenen komplexen Eingabeparameter (in der Regel die zu verwendenden Vektordatenlayer im GML Format) werden vom Betriebssystem (hier der Textbrowser Lynx) heruntergeladen, wenn eine URL als Referenz übergeben wurde. Alternativ werden sie bei Übergabe im Request (inline) direkt in ein temporäres Verzeichnis hineingeschrieben. c) Die erzeugten Layer werden aus dem temporären Verzeichnis mit einem GML Importkommando in die GRASS Map Location importiert. d) Aus den sonstigen (einfachen) Eingabeparametern und dem Prozessnamen wird ein Befehl erzeugt, der das entsprechende GRASS Modul aufruft. e) Ein GRASS Vektordaten Export Modul wird aufgerufen, um das Ergebnis aus dem internen GRASS Format wieder in GML zu exportieren. Die GML-Datei wird in einem temporären Verzeichnis gespeichert.

54 4 Implementierung Das Betriebssystem wird vom GrassVectorAlgorithm angewiesen, das im vorherigen Schritt erzeugte Skript auszuführen. 6. Der RequestHandler parst das Ergebnis aus dem temporären Verzeichnis und schreibt es in die Execute Antwort. 7. Die erzeugte GRASS Map Location wird gelöscht. 8. Das WPS servlet sendet die Execute Antwort zurück an den Client. Erweiterungen Für den Fall falscher Eingaben oder anderer Fehlfunktionen wird eine entsprechende RuntimeException erzeugt und an den Client ausgeliefert. Dies führt aufgrund der Zustandslosigkeit zu einem vollständigen Abbruch der Anfrage. Der GIS-Experte muss die Anfrage umformulieren oder, wenn administrative Probleme vorliegen, den entsprechenden Administrator kontaktieren. 4.3 Einbindung in Web Processing Service Workflows Die Einbindung von WPS-GRASS Prozessen in BPEL basierte Workflows, wie in der Arbeit von Schäffer (2007) beschrieben, wird aus Zeit- und Aufwandsgründen nicht weiter untersucht. Die Integration sollte aber generell möglich sein, da die Prozesse für sich atomar ausführbar sind und deshalb auch in einem BPEL Container ausgeführt werden können. Die Zustandslosigkeit ist gewahrt. Bei einer Einbindung in einen Workflow wird vermieden, dass Zwischenergebnisse (z. B. des Generalisierungsprozesses aus dem Geschäfts-Use-Case) erst heruntergeladen, dann verfügbar gemacht (sei es im Client oder als neuer Layer in einem WFS) und für den nächsten Prozess des Workflows wieder hochgeladen werden müssen. Wesentlich komplexere Workflows können mit Schäffers transaktionalem WPS als zusammengefasster Black Box Prozess für die Zukunft für andere Benutzer weiterverwendbar bleiben. Der folgende Abschnitt beschreibt die Architektur für die konkrete Umsetzung der vorher beschriebenen Anforderungen mit GRASS und dem 52 North WPS. 4.4 Architektur Im folgenden wird auf Einzelheiten der Architektur eingegangen. Einen einfachen graphischen Überblick gewährt Abbildung 3. Einzelheiten zu den wesentlichen Komponenten werden erläutert. Genaue Beschreibungen zu Vorgehensweisen, die sich expli-

55 4 Implementierung 47 zit aus Kapitel 3 ergeben, werden nach der Architektur in eigenen Abschnitten ausgeführt. Abbildung 3 Referenzarchitektur für die Anbindung von GRASS an eine WPS Schnittstelle. Beispielhaft wird eine Execute Anfrage für die v.generalize Funktionalität bearbeitet(1.). Vor der Prozessierung der Daten im temporären GIS Workspace muss ein Shellskript erzeugt werden (2.), das die GRASS Umgebung (Map Location) erzeugt und mit GIS-eigenen Funktionalitäten den Import und Export in die Map Location und die eigentliche Prozessierung durchführt. Die generierte Antwort wird als temporäre Datei für den WPS verfügbar gemacht (3.), der sie im vom Nutzer gewünschten Datenformat an den Client zurückgeliefert (4.). (Eigene Darstellung) Algorithmus Repositorium - GrassProcessRepository Auf Basis der von Schäffer (2007, S. 70) eingeführten dynamischen Algorithmenrepositorien wurde ein GRASS Repositorium entwickelt. In den Algorithmenrepositorien können verschiedene Typen von Prozessen entweder nach unterschiedlichem techni-

56 4 Implementierung 48 schen Hintergrund oder fachlichen Kategorien aufgeteilt werden. Zum Zeitpunkt des Dienststarts wird überprüft, welche Repositorien und Prozesse verfügbar sind. Diese werden im Anschluss geladen. Im Standardfall sind nur die beispielhaften Prozesse verfügbar, die mit dem WPS in seiner Grundkonfiguration in einem statischen Repositorium mitgeliefert werden. In diesem Fall werden die Prozesse in der WPS Konfigurationsdatei eingetragen und geladen. Im Falle des dynamischen GRASS Repositoriums musste ein dynamischerer Ansatz als die Konfigurationsdatei gewählt werden, da eine Eintragung von bis zu dreistelligen Prozessen in eine Konfigurationsdatei nicht sehr komfortabel ist. Stattdessen wird vom GrassProcessRepository dynamisch ermittelt, welche DescribeProcess Dokumente vorhanden sind und diese werden dementsprechend jeweils als Prozess verfügbar gemacht. Das Repositorium ist auch für die Generierung von Algorithmeninstanzen zuständig. Das GrassProcessRepository implementiert das IAlgorithmInterface des WPS. Durch die Implementierung als Singleton (Gamma et al., 1995, S. 127 ff.) wird sichergestellt, dass nur eine einzige Instanz des Repositoriums existieren kann. Verarbeitung von Eingabedaten - InputHandler In der 52n WPS Standard Konfiguration ist der WPS direkt für das potentielle Herunterladen oder das Parsen der im Execute Request mitgelieferten Daten und die Umformung in Geotools ( Datenstrukturen verantwortlich. Die 52n Standard Architektur stellt primär auf Geotools basierte Algorithmen zur Verfügung. Der mitgelieferte InputHandler erzeugt die Geotools Datenstrukturen, damit diese im Algorithmus verwendet werden können. Im Fall der GRASS Anbindung ist dieser Schritt überflüssig, da keine Geotools Datenstrukturen verwendet werden und der eigentliche Datenimportvorgang erst vom Algorithmus durchgeführt wird. Zum Zeitpunkt des Aufrufens des InputHandler kann der Import noch nicht erfolgen, da noch kein GRASS Workspace angelegt werden kann. Er wird deshalb übersprungen. Der entwickelte GrassInputHandler bereitet die URL für die Übergabe an den Algorithmus vor bzw. schreibt die in der Execute Anfrage mitgelieferten Daten in eine temporäre Datei. Um dies zu erreichen überschreibt der GrassInputHandler die Methode handlecomplexvaluereference vom InputHandler. Verarbeitung des Prozessergebnisses - Anpassung des GML2BasicGenerators Mit der erstellten Implementierung sind nur Vektordaten im GML Format erzeugbar. Um das Ergebnis korrekt an den Client zu übermitteln (oder zum späteren Herunter-

57 4 Implementierung 49 laden abzuspeichern), war nur eine kleine Änderung am GML2BasicGenerator notwendig. Normalerweise liefert der Algorithmus eine Geotools FeatureCollection zurück, die vom Generator in eine temporäre Datei geschrieben wird. Im GRASS Fall wäre dies wieder ein redundanter Schritt, da das Ergebnis eines GRASS Vektor Algorithmus schon in einer temporären Datei im Dateisystem abgelegt worden ist (siehe Abschnitt 4.6). Der angepasste Generator überprüft nun, ob er eine Geotools Feature- Collection als Ergebnis vom Algorithmus geliefert bekommt oder eine Referenz auf die dazugehörige temporäre Datei. 4.5 Automatische Erzeugung der DescribeProcess Dokumente Wie in Abschnitt vorgeschlagen, wurde für die Erzeugung von DescribeProcess Dokumenten ein XSLT Filter erzeugt, der die entsprechenden Prozessgrundgerüste kompiliert. Es müssen nur DescribeProcess Dokumente per Hand modifiziert werden, die mehr als einen komplexen Eingabeparameter (im Sinne der WPS Spezifiktion) benötigen, oder einen, der nicht als input tituliert wird. Die Gründe dafür sind im angeführten Abschnitt erläutert. Für die erfolgreiche Transformation von GRASS XML Schnittstellenbeschreibungen wird zusätzlich zum eigentlichen XSLT Filter noch ein Hilfsprogramm benötigt, dass den automatischen Ablauf kontrolliert. Bei der Transformation ist viel XML Parsen und Zugriff aufs Dateisystem erforderlich. Deshalb wurde für die Implementierung des Hilfsprogramms die Programmiersprache Groovy ausgewählt, die für beides eine sehr gute und einfache Unterstützung bietet. Im ersten Schritt wird das Verzeichnis durchsucht, in dem die GRASS Module gespeichert sind, um eine Liste mit allen verfügbaren GRASS Modulen zu bekommen. Im Anschluss werden analog zu Abschnitt direkt alle Module wieder aus der Liste entfernt, die mit d. beginnen, da es sich um Visualisierungsfunktionalitäten handelt, die in einem verteilten System serverseitig nicht benötigt werden. Zusätzlich werden die Module entfernt, die in einer Konfigurationsdatei vom Benutzer vorher festgelegt werden können. Für die Erzeugung der GRASS XML Schnittstellenbeschreibungen wird als nächster Schritt ein Shell Skript generiert, das eine rudimentäre GRASS Umgebung definiert, in der die Beschreibung der gewünschten Module mit dem Parameter interface-description erzeugt wird. Die entstehenden Beschreibungen werden jeweils als Datei in ein temporäres Verzeichnis geschrieben. Auf jede XML Datei im temporären Verzeichnis wird nun der XSLT Filter ange-

58 4 Implementierung 50 wendet, der für jede Funktionalität ein eigenes DescribeProcess Grundgerüst erzeugt. Alle DescribeProcess Dokumente werden ebenfalls in einem temporären Verzeichnis gesammelt. Nun liegt es an menschlicher Expertise, die uneindeutigen DescribeProcess Dokumente von Hand so zu modifizieren, dass sie für den WPS verwendbar sind. Im letzten Schritt müssen die erzeugten und modifizierten DescribeProcess Dokumente noch in die 52n WPS GRASS Web Application, sprich den Servlet Kontext, verschoben werden, damit sie beim initialen Start des WPS vom GrassAlgorithm- Repository erkannt und bearbeitet werden können. 4.6 Skriptgenerierung Die Kommunikation des WPS mit GRASS zur Laufzeit, wie im System-Use-Case II (Abschnitt 4.2.2) beschrieben, findet ausschließlich über Shell Skripte statt. Für die Erzeugung dieser Skripte ist die Klasse AbstractGrassAlgorithm zuständig. Für Raster- und Vektorfunktionalitäten gibt es jeweils eigene Unterklassen. Für die Implementierung ist allerdings nur GrassVectorAlgorithm umgesetzt worden. Die Unterscheidung erfolgt im Wesentlichen aus Gründen des Datenimports. GRASS oder auch andere GIS schreiben nicht vor, wie die Daten für die GIS Funktionalitäten in den Workspace importiert werden, sie müssen dort nur vorhanden sein. Der Benutzer ist selber dafür verantwortlich, die entsprechenden Daten mit den GIS-eigenen Importierungsfunktionalitäten einzuladen. Der WPS hingegen schreibt bestimmte unterstützte Datenformate vor. Aus Gründen der zustandslosen Modellierung (Abschnitt 3.3.1) muss der WPS zur Laufzeit automatisch entscheiden, welche Daten wie importiert werden sollen. Je nach Datenformat müssen unterschiedliche Import- und Exportfunktionalitäten verwendet werden (z. B. v.in.ogr für Vektordatenimport und r.in.gdal für Rasterdatenimport). Die Verwendung dieser Funktionalitäten ist mandatorisch, da sonst der Workspace nicht mit Daten befüllt, und eine Prozessierung deshalb dann nicht stattfinden kann. In jedem Fall müssen zu Beginn des Skripts Umgebungsvariablen gesetzt werden. Dazu zählen: Installationsverzeichnis von GRASS in der Variable GISBASE, Pfad zur GRASS Konfigurationsdatei (GISRC), Pfad zum Verzeichnis, in dem die ausführbaren Dateien von GRASS liegen (meistens /bin und /scripts) in der bestehenden PATH Variable,

59 4 Implementierung 51 Listing 5 Verzeichnisstruktur eines GRASS Workspace vor der Prozessierung (ohne importierte Daten). In der Datei.grassrc befinden sich einige Konfigurationsparameter für GRASS (siehe Listing 6), in DEFAULT_WIND ist ein XY Bezugssystem definiert.,. /. g r a s s r c. /PERMANENT. /PERMANENT/DEFAULT_WIND Listing 6 Inhalt der.grassrc Konfigurationsdatei für GRASS. Zu sehen sind u. a. Angaben zum Namen der Map Location und die Anweisung, dass GRASS im textbasierten Modus, ausgeführt werden soll und dass schon bestehende Dateien überschrieben werden sollen. MAPSET: PERMANENT LOCATION_NAME: wps_ 8e4f3f10 966b d00 4b254672e6c5 DIGITIZER : none GISDBASE : /home/ j o e j o e / apps / apache tomcat / temp OVERWRITE: 1 GRASS_GUI : t e x t Pfad zu den GRASS Bibliotheken in bestehender LD_LIBRARY Variable. Listing 5 zeigt einen leeren temporären GRASS Workspace (ohne importierte Geodaten). In der Datei DEFAULT_WIND ist ein rudimentäres XY Bezugssystem definiert. In der Datei.gisrc sind GRASS Konfigurationsangaben festgehalten (siehe Listing 6). Dazu zählen u. a. die Angabe, GRASS im textbasierten Modus zu starten und der Name der Map Location. Listing 7 zeigt exemplarisch den Import, die Prozessierung und den Export über GRASS Funktionalitäten. Die Skriptgenerierung erfolgt ansonsten wie im System-Use- Case II beschrieben. Ein vollständiges Beispielskript findet sich im Anhang B. Weitere Listing 7 Auszug aus einem Shellskript für v.generalize. Mit lynx wird der Eingabedatenlayer vom WFS herunterladen und in eine temporäre Datei gespeichert. Der eigentlich Import der Daten in die GRASS Map Location wird über v.in.ogr durchgeführt. Anschließend wird die Generalisierung mit v.generalize durchgeführt und das Ergebnis mit v.out.ogr wieder in eine temporäre Datei gespeichert, die vom WPS weiterverwendet werden kann., l y n x source " h t t p : / / wfs. dyndns. org :8080 / g e o s e r v e r / wfs? v e r s i o n =1.0.0&SERVICE=WFS&REQUEST=GetFeature &typename=topp : r o u t e " > i n p u t. gml v. i n. ogr o dsn=i n p u t. gml output=i n p u t v. g e n e r a l i z e i n p u t=i n p u t output=output v. out. ogr i n p u t=output dsn=output. gml format=gml

60 4 Implementierung 52 Informationen zur unüberwachten Steuerung von GRASS finden sich in Neteler und Mitasova (2007, S. 331 ff.). 4.7 Bestimmung des räumlichen Bezugssystems Leider werden RBS in GML Dateien nicht einheitlich angegeben. Eine vollautomatische Bestimmung des RBS ist daher nicht einfach umsetzbar. Aus Zeitgründen wurde deshalb in dieser Arbeit ein fest definiertes RBS statisch eingefügt. Es handelt sich um das weltweit anwendbare System der Längen- und Breitengrade (Ogp, 2008, EPSG Code 4326). Es sei wiederholt, dass eine korrekte Arbeitsweise ohne entsprechende RBS nicht möglich ist (Abschnitt 3.2.4).

61 5 Nachweis der Machbarkeit 53 5 Nachweis der Machbarkeit An einem realen Szenario, das durch einen Geschäfts-Use-Case beschrieben wird, wird gezeigt, wie die Überlegungen aus Kapitel 3 und die daraus abgeleitete Implementierung zu einem lauffähigen System führen. Grundlagen und Konzepte von Use Cases werden in Abschnitt 4.2 beschrieben. 5.1 Geschäfts-Use-Case - Amerikaner ermittelt bereiste Bundesstaaten Der Geschäfts-Use-Case beschreibt die Systemanforderungen aus Sicht des Benutzers, anhand eines konkreten Beispiels, das den Arbeitsablauf exemplarisch verdeutlichen soll. Statt der verwendeten Generalisierungs- und Overlapprozesse, können aus dem Funktionalitätenfundus des unterliegenden GIS auch andere ausgewählt werden. Der Geschäfts-Use-Case ist konstruiert und keiner realen Problemstellung entnommen. Umfangreiche frei verfügbare und professionell erhobene Daten gibt es fast ausschließlich nur in Nordamerika, da sie dort aus Steuermitteln erhoben und deshalb als Allgemeingut angesehen werden. In Europa und in den meisten Teilen der restlichen Welt, sind behördlich und damit auch professionell erhobene Daten nicht frei erhältlich. Für ihre Nutzung muss eine Gebühr entrichtet werden. Den Unterschied zwischen beiden Ansätzen diskutiert u. a. Rhind (2000). Ein Projekt wie openstreetmap.org ( bei dem kollaborativ von den Benutzern Daten erhoben und anderen zur Verfügung gestellt werden, bietet eine alternative freie Datenquelle. Derartige Daten sind leider meistens nicht komplett erhoben, da nur eine nutzungsgetriebene Erfassung stattfindet. Bestimmte Daten (z. B. behördliche Grenzen) können nicht von Laien aufgenommen werden, da man sich im Gelände, nur mit GPS (Global Positioning System) und eigenen Augen ausgestattet, nicht an Landmarken orientieren kann. Deshalb wird für den vorliegenden Geschäfts-Use-Case auf amerikanische Daten zurückgegriffen und ein passendes Problem konstruiert. Der unterstrichene Bereich verweist auf die in den Systemanforderungen (Abschnitt 4.2) verwendeten System-Use-Cases. Anhand von Bildschirmfotos werden die einzelnen Arbeitsschritte dokumentiert. Primärakteur Mr Pennypincher (Geoinformatikinteressierter Amerikaner).

62 5 Nachweis der Machbarkeit 54 Umfang 52 North WPS mit angebundenem GRASS. Ebene Überblick. Stakeholder und Interessen Mr Pennypincher - Liste mit durchquerten US-Bundesstaaten. Vorbedingungen Mr Pennypincher fährt oft quer durch die USA. Er möchte wissen, welche Bundesstaaten er dabei bereist hat. Da die Sales Tax (eine Art Mehrwertsteuer) in allen Staaten unterschiedlich ist und er den gleichen Weg zurückfährt und noch Besorgungen machen will, möchte er den Staat mit der niedrigsten sales tax ermitteln. Sein GPS (Global Positioning System) Gerät hat auf dem Hinweg kontinuierlich seine räumliche Position ermittelt und aufgezeichnet. Am Zielort angekommen, lädt Mr Pennypincher den vektorisierten GPS track auf seinen mobilen Computer. In einem Dienstekatalog findet er einen entsprechenden Feature Service mit den Grenzen der US-Bundesstaaten. Abbildung 4 Anzeige der GetCapabilities Anfrage an den WPS. Auf der linken Seite wird die Liste der verfügbaren Prozesse angezeigt. Neben denen aus der Standardkonfiguration werden einige GRASS Prozesse angeboten (erkennbar durch das grass im Namen). Auf der rechten Seite wird das DescribeProcess Dokument für v.generalize angezeigt. (Eigene Darstellung) Nachbedingung Mit der Liste der durchquerten US-Bundesstaaten ermittelt Mr Pennypincher mittels einer Internet Recherche den Staat mit der niedrigsten Sales Tax und kauft dort auf dem Rückweg ein.

63 5 Nachweis der Machbarkeit 55 Abbildung 5 Eingabemaske für v.generalize des udig WPS Plugins. Es kann der Eingabedatenlayer und der zu verwendende Generalisierungsalogrithmus (hier Douglas-Peucker) mit entsprechendem Schwellwert angegeben werden. Das zugrundeliegende DescribeProcess Dokument findet sich in Anhang A. (Eigene Darstellung) Abbildung 6 Eingabemaske für v.select des udig WPS Plugins. Es können die beiden Eingabedatenlayer mit ihren Feature Types und der zu verwendende Operator (hier overlap) gewählt werden. (Eigene Darstellung) Standardablauf Da sich für Mr Pennypincher die Anschaffung eines eigenen GIS Pakets nicht lohnt und sein mobiler Rechner für komplizierte Berechnungen nicht mit genug Rechenleistung ausgestattet ist, möchte er die im Internet verfügbaren Vektorfunktionalitäten des 52 North WPS-GRASS nutzen. Er startet einen WPS Client und