Motivation

Die Zahl der verfügbaren Dienste für Geo-Daten und Geo-Anwendungen steigt ständig. Dies schafft Potential für neuartige Anwendungen, welche insbesondere auf die Kombination dieser Dienste setzen. Ein zentrales Problem ist, die Dienste geeignet zu kombinieren und integrieren sowohl auf konzeptioneller Ebene als auch programmiertechnisch. Dies gilt bei den Client-Server-Umgebungen sowohl auf der serverseitigen Anwendung, als auch auf dem Client.

Serverseitig erreicht man zwar Flexibilität durch die unterschiedlichen Geo-Dienste des OGC (Open Geospatial Consortium), wie Web Map Service(WMS), Web Feature Service (WFS), Web Processing Service (WPS) oder das Sensor Web Enablement (SWE), allerdings ist die Kombination dieser Dienste noch mit relativ viel Aufwand verbunden. Dies ist vor allem dann der Fall, wenn die Geo-Dienste mit anderen Ressourcen außer denen der OGC Standards verknüpft werden soll.

Im Client/Portal-Bereich gibt es im Grunde zwei Realisierungsansätze. Zunächst die reinen Frameworks, welche die volle Freiheit erlauben, allerdings einen hohen Programmieraufwand bedeuten. Zudem die fertigen Clients/Portale, welche allerdings eher auf dezidierte Web-GIS-Anwendungen ausgelegt sind. Ziel ist daher die Konzeption und Entwicklung eines generischen Systems, welches unterschiedliche Geo-Dienste verwalten und insbesondere verknüpfen kann. Das Ergebnis soll für unterschiedliche Aufgabenstellungen nutzbar, bzw. erweiterbar sein und ausreichend Schnittstellen für weitere Entwicklungen hinsichtlich der Eingabe, Verwaltung, Analyse und Darstellung bieten.

Aktivitäten

In einer ersten Phase wurde ein fundiertes Allgemeinkonzept entwickelt und geeignete verfügbare Komponenten ausgewählt. Im Bereich der Benutzerschnittstelle wurde sich für die Portalsoftware Liferay entschieden. Diese bietet bereits einige Grundfunktionalität und lässt sich mit eigenen Komponenten (Portlets, Services, Hooks) sehr gut erweitern. Die Verwendung von Portlets erlaubt es zudem später Anwendungen flexibel zusammenzusetzen. Das Grundsystem wurde bereits erstellt, und erste prototypische Erweiterungen entwickelt.

Da auch serverseitig die flexible Kombination der Dienste und Ressourcen möglich sein soll, muss dafür gesorgt werden sie über Module im Programm sehr stark zu entkoppeln. Die Aufgaben lassen sich dann in Workflows definieren, die aus einer Reihe von Schritten zusammengesetzt sind. Diese Workflows bestehen im einfachsten Fall aus einem Input, welcher dann prozessiert wird und einem Output an welchen die Daten gegeben werden. Derzeit sind Module in der Entwicklung, die auf Basis von Projekten des Spring Frameworks (SpringXD, Spring Integration, Spring Social, Spring Data) Schnittstellen für Datenquellen, Prozesse und Datenspeicher zur Verfügung stellen.

In einem Beispielszenario werden die Möglichkeiten des Prototyps untersucht. Hierzu wird ein Social Media Analyse Werkzeug entwickelt, welches den Grundgedanken von Tweetmap (http://tweetmap.fh-mainz.de) aufgreift. Es sollen Tweets zu bestimmten Themen gesammelt in einer Sentiment-Analyse bearbeitet und dann im Sinne von Human As Sensors in einem Geo-Sensor-Netzwerk über einen Sensor Observation Service (SOS), welcher Bestandteil des SWE ist, bereitgestellt werden.

Resultate

Der aktuelle Prototyp basiert auf dem Architekturmodell aus Abbildung 1. Als zusätzliche Portalkomponenten gibt es eine erste Kartenanwendung und deren Ebenenmanagement. Zudem gibt es erste Tests einer zeitlichen Diagrammvisualisierung, welche später zur zeitlichen Navigation/Filterung genutzt werden soll. Auf der Serverseite wurden verschiedene Dienste aufgesetzt und die ersten Module für einen Workflow entwickelt. Dieser beinhaltet derzeit vor allem Input- und Outputmodule , wie eine Twitter-Schnittstelle und die Bereitstellung dieser Daten als Sensor in ein SOS. Damit kann ein Hintergrundprozess, welcher z.B. die Twittermeldung zu einem Thema sammelt und in den SOS schreibt, wie in einer UNIX-Shell definiert werden [Abbildung 2]. Die „Pipes“ definieren hierbei den Kanal, welchen die einzelnen Module nutzen. Dabei können sämtliche Module, als auch der Kanal auf unterschiedlichen Servern liegen. Auch die Verwaltung der Workflows geschieht über eine Web-Schnittstelle. Im nächsten Schritt sind die entwickelten Module nun zu erweitern und weitere Module, vor allem für die Datenprozessierung (z.B. Twitter-Sentiment), sind zu entwickeln. Zudem sind die Schnittstellen zur Benutzeranwendung (Portal) herzustellen.