Konferenz 2009/OpenLayers SOS: Unterschied zwischen den Versionen

Aus FOSSGIS Wiki
Zur Navigation springenZur Suche springen
K (1 Version: Zusammenführung der Wikis)
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 77: Zeile 77:
[2] SensorGIS: http://www.sensorgis.de/
[2] SensorGIS: http://www.sensorgis.de/
[3] OpenLayers: http://www.openlayers.org
[3] OpenLayers: http://www.openlayers.org
[[Kategorie:FOSSGIS Konferenz 2009]]
[[Kategorie:OpenLayers]]

Aktuelle Version vom 7. November 2013, 11:53 Uhr

OpenLayers trifft Sensor Observation Service (SOS) Till Adams Dominik Helle Einführung In einem Geoinformationssystem (GIS) werden hinsichtlich der Aktualität von Daten immer höhere Ansprüche gestellt. So werden für bestimmte Analysen und Berechnungen Geodaten in Echtzeit benötigt. Um diesem Anspruch gerecht zu werden, werden immer häufiger Sensoren und Sensornetzwerke eingesetzt. Um die Kommunikation mit Sensorsystemen zu vereinheitlichen hat das Open Geospatial Consortium (OGC) die sogenannten SWE-Standards (Sensor Web Enablement) definiert. Eine Spezifikation ist der Sensor Observation Service (SOS) - er hat zur Aufgabe die aufgenommenen Daten von Sensoren über eine definierte Schnittstelle zugänglich zu machen. Es gibt einige Mapserver, die in der Lage sind einen SOS anzubieten, allerdings gibt es bisher kaum Benutzeroberflächen (Clients), die in der Lage sind Sensordaten strukturiert sowie in ihrer räumlichen Verteilung anzuzeigen. Aus diesem Grunde wurde die OpenLayers Bibliothek um einen neuen Layertyp „SOS“ erweitert. Am Ende des Vortrags wird die mögliche Veredelung von Sensordaten in Tabellen, Diagrammen, interpolierten Oberflächen in einem WebGIS anhand von Live Beispielen demonstriert.

Die Spezifikation: SOS Sensor Observation Services (SOS) beschreiben standardisierte Webservices, die den Zugang zu Beschreibung (Capabilities) und Daten von Sensoren bieten. Diese Sensoren, ausgestattet mit der entsprechenden Messeinheit, können Umweltparameter wie Temperatur, Erschütterung, Abfluss, Bodenfeuchte oder kurz – jeden Parameter, der ein physikalisches Signal liefert - messen. Die SOS-Spezifikation ist Teil der OGC Sensor Web Enablement (SWE) Spezifikation. Der SOS ist ein pull basierter Service, dass bedeutet er reagiert auf eine Anfrage Abb. 1: Schematische Darstellung der SWE Spezifikationen vom Benutzer, ähnlich einem WMS oder WFS. Das Ergebnis der Anfrage wird in der Auszeichnungssprache OM beschrieben. Neben den Beobachtungswerten können auch Beschreibungen von Sensoren beim SOS angefordert werden. Sie stehen als SensorML Dokument zur Verfügung. Der Funktionsumfang der entwickelten Schnittstelle reicht vom Darstellen des Sensors über das Abfragen von Messwerten bis hin zum Erzeugen eines Diagramms. Als Testumgebung wurden Sensordaten aus einem Pilotprojekt der Zugspitze mit einem UMN Mapserver als SOS Dienst zur Verfügung gestellt.

Drahtlose Sensornetzwerke Drahtlose Sensornetzwerke ersetzen drahtgebundene Systeme und eröffnen neue Anwendungsfelder. Sie reduzieren Zeit und Aufwand bei der Herstellung, der Installation und im Betrieb. Die Sensorträger werden in Form von drahtlosen Sensornetzwerken zusammengeschaltet, bei der sich hunderte bis tausende Sensoren spontan und autark miteinander vernetzen, Daten sammeln und diese Informationen zu einem zentralen Knoten transportieren. Durch Bestimmung der Koordinate der Sensoren werden die gemessenen Daten zu Geodaten und können in einer Karte dargestellt werden. Dies bedeutet, dass sich z.B. eine Grundwassergleichenkarte in Echtzeit interpolieren und darstellen lässt. Die Erweiterung und Kombination von gemessenen Daten um die räumliche Komponente in einem GIS, nennen wir SensorGIS [2]. Wir verstehen darunter die Übermittlung von Daten in Echtzeit aus drahtlosen Sensornetzwerken in ein webbasiertes, geographisches Informationssystem. Abb. 2 Schematische Darstellung eines SensorGIS [2]

Entwicklung Um die Frage nach der Bereitstellung eines Clienten für die SOS Daten technisch zu beantworten wurde zunächst untersucht, welche technischen Lösungen bereits existieren und wie sich die bestehenden Komponenten nutzen bzw. erweitern lassen. Grundsätzlich wurde von Anfang an die Erweiterung eines bestehenden WebMapping Clienten favorisiert. Weitere Auswahlkriterien waren Performance, Benutzerfreundlichkeit sowie eine flexible Architektur der zu erweiternden Software. Der Client benötigt weiterhin Schnittstellen um dienstebasiertes Kartenmaterial z. B. über WMS oder WFS, aber auch andere Datenquellen wie Google, OSM Daten usw. einbinden zu können. Nur so können die Daten des SOS in einem räumlichen Kontext dargestellt werden. Aus diesen Gründen fiel die Wahl auf OpenLayers [3]. OpenLayers besitzt alle nötigen Eigenschaften und bietet derzeit die besten Möglichkeiten die Schnittstelle zu integrieren. Um mit dem SOS kommunizieren zu können mussten standardisierte Anfragen erstellt werden. Um dies zu gewährleisten wurde eine eigene Klasse entwickelt, welche die nötigen XML-Dokumente bereitstellt. Die neue OpenLayers Schnittstelle basiert auf drei Teilklassen:


Format.SOS erzeugt standardisierten Request und parst die Antwort Funktionen zur Erzeugung der Requests GetCapabilities DescribeSensor GetObservation Filter encoding für zeitliche und räumliche Filter Funktionen zum Parsen der Antwort (OM document) read geometry read measured values read timestamp

Layer.SOS Anzeige der Objekte in der Karte Layertyp SOS in OpenLayers kommuniziert mit dem SOS via HTTP-Post erstellt PopUp zum Anzeigen der Informationen erstellt für den Sensor einen Marker auf der Karte

Visualisation Erzeugen von Diagrammen und Datentabellen In der Klasse sind Funktionen zum Erstellen der drei Hauptoperationen GetCapabilites, DescribeSensor und GetObservation implementiert. Weiterhin verfügt die Klasse über Funktionen, um räumliche und zeitliche Filter zu erstellen und ggf. in die GetObservation-Anfrage zu integrieren. Neben dem Erstellen von XML Dokumenten ist die Klasse auch in der Lage, die Antwort des SOS zu verarbeiten. Da der SOS zu jeder GetObservation Anfrage eine Punktgeometrie liefert, wird er als Punktlayer betrachtet. Punkte können durch einen Marker auf der Karte dargestellt werden.





Visualisierung Für die Visualisierung der Sensordaten werden die Sensoren und die Eigenschaften aus dem Capabilities Dokument des SOS gelesen. Es besteht die Möglichkeit, dass die Anfrage zeitlich begrenzt wird. Aus der Auswahl des Benutzers wird ein der entsprechenden GetObservation Aufruf erstellt. Das Ergebnis wird nach erfolgreicher Abfrage in einer Tabelle oder als Graph visualisiert.

Abb. 3 Darstellung der Messwerte in Diagramm und Tabelle Abschluss/Zusammenfassung Das Ergebnis der Implementierung ist ein neue Layer-Klasse für OpenLayers. Mit Hilfe dieser kann nun ein SOS eingebunden und zusammen mit anderen Geodaten auf einer Karte dargestellt werden. Weiterhin sorgt der neue Layer dafür, dass die Informationen des SOS dem Benutzer zugänglich sind, dass heißt sie werden gespeichert und können abgefragt werden. Außerdem verfügt die Schnittstelle über zeitliche Filterfunktionen. Die Ergebnisse des SOS können in einer Tabelle oder einem Graphen dargestellt werden. Prinzipiell sind natürlich weitere Verwendung, wie die Anbindung eines WPS o.ä. denkbar – so können aus gemessenen Punktwerten z. B. kontinuierliche Oberflächen interpoliert werden. Die Firma terrestris hat dies int einem anderen Projekt, in dem ebenfalls Sensordaten visualisiert werden, bereits realisiert. Hier sorgt ein GRASS im Backend für die nötigen Interpolationsalgorithmen, ein OpenLayers Client im Frontend visualisiert die Daten. Im Vortrag wird hierzu ein Beispiel gezeigt.


Kontakt zu den Autoren: Till Adams Dominik Helle terrestris GmbH Co KG Omniscale Irmintrudisstr. 17, 53111 Bonn Dominik Helle Oliver Tonnhofer GbR ++49 / (0)228 / 962 89952 Industriestraße 1, 26121 Oldenburg adams@terrestris.de helle@omniscale.de

Literatur Links [1] SWE SOS: http://www.opengeospatial.org/standards/sos [2] SensorGIS: http://www.sensorgis.de/ [3] OpenLayers: http://www.openlayers.org