Sensor Observation Service

Der Sensor Observation Service (SOS) ist ein Webservice zur Abfrage von Echzeit-Sensordaten sowie von Sensordatenzeitreihen. Die angebotenen Sensordaten umfassen einerseits Beschreibungen von Sensoren selbst, die in der Sensor Model Language (SensorML) kodiert werden, sowie die Messwerte, die in dem Observations&Measurements (O&M) Format kodiert werden. Der Webservice sowie beide Datei-Formate sind offene Standards und in gleichnamigen Spezifikationen des Open Geospatial Consortium (OGC) definiert. Falls der SOS transaktional (SOS-T) ist, können neue Sensoren über die Serviceschnittstelle registriert und anschließend Messwerte eingefügt werden. Der SOS kann sowohl Daten von Vor-Ort- als auch von Fernerkundungssensoren anbieten. Ferner können die Sensoren sowohl mobil als auch stationär sein.

Seit 2007 ist der SOS ein offizieller OGC-Standard. Der Vorteil des SOS ist, dass Sensordaten – gleich welcher Art – in einem einheitlichen Format und über standardisierte Operationen im Internet verfügbar werden und somit der webbasierte Zugriff auf Sensordaten vereinfacht wird. Da der SOS ein OGC-Standard ist, ermöglicht er ferner eine einfache Integration in bestehende Geoservice-Infrastrukturen oder in allgemeine Geoinformationssysteme.

Operationen

Der SOS hat drei sogenannte Kernoperationen, die von jeder SOS-Implementierung angeboten werden müssen. Die GetCapabilities-Operation ermöglicht die Abfrage einer Servicebeschreibung mit Infos über die Serviceschnittstelle sowie die angebotenen Sensordaten. Für den laufenden Betrieb ist die GetObservation-Funktion vermutlich die wichtigste. Hiermit lassen sich Messwerte von Sensoren abfragen. Die DescribeSensor-Funktion gibt detaillierte Informationen über einen Sensor oder ein Sensorsystem, die gelieferten Daten und die Prozesse, welche die Daten verarbeiten, zurück.

Kernoperationen (Core Profile):

• GetCapabilities - gibt ein XML-Servicebeschreibung zurück, die einerseits Infos über die Schnittstelle (angebotene Operationen) sowie über die angebotenen Sensordaten, wie z. B. Zeitraum, für den Sensordaten verfügbar sind, Sensoren, welche die Messwerte produzieren, oder Phänomene, die beobachtet werden (z. B. Lufttemperatur), enthält.
• GetObservation - pull-basierte Abfrage von Beobachtungswerten mit Metadaten; die Messwerte sowie ihre Metadaten werden in dem Observations&Measurements-Format (O&M) zurückgeliefert.
• DescribeSensor - liefert Sensormetadaten in SensorML kodiert zurück. In dem SensorML-Datensatz sind in der Regel die ID des Sensors, die Position sowie beobachtete Phänomene enthalten. Ferner können weitere Informationen, wie z. B. Kalibrierungsdaten beschrieben werden.

Transaktionale Operationen (Transactional Profile):

• RegisterSensor - ermöglicht es, einen neuen Sensor in einem laufenden SOS zu registrieren
• InsertObservation - ermöglicht das Einfügen von Messdaten für registrierte Sensoren in den SOS

Erweiterte Operationen (Enhanced Profile):

• GetResult - bietet die Möglichkeit, bei gleichbleibenden Metadaten (z. B. Sensor, beobachtetes Objekt) für eine Messwertreihe, nur den Messwert ohne die Metadaten abzufragen
• GetFeatureOfInterest - liefert das Geoobjekt, dessen Eigenschaften von Sensoren überwacht werden, in der Geography Markup Language (GML) kodiert zurück
• GetFeatureOfInterestTime - liefert Zeitperioden, in denen Messwerte für ein beobachtetes Objekt im SOS vorhanden sind.
• DescribeFeatureType - liefert den Typ des beobachteten Geoobjekts zurück (XML-Schema)
• DescribeObservationType - liefert den Typ der Beobachtung zurück (XMLSchema, z. B. om:Measurement)
• GetObservationById - ermöglicht die Abfrage einer Beobachtung per ID
• DescribeResultModel - liefert das XML-Schema des Messwertes; dies ist vor allem bei komplexen Messwerten, wie z. B. multispektralen Daten, von Bedeutung.

Verwendung der Methoden

Neben den Kernoperationen gibt es noch zusätzlich Operationen, die nicht zwingend implementiert werden müssen. In vielen Projekten wird vorerst neben den grundlegenden Funktionen zusätzlich nur die InsertObservation-Methode verwendet. Diese ermöglicht es, von Außen Daten in den laufenden Sensor Observation Service einzupflegen. Die Daten werden streng nach den O&M-Spezifikationen eingebettet in einer XML-Datei an den SOS übergeben.

Finden von Diensten und Sensoren

Ist ein potenzieller Nutzer auf der Suche nach Sensoren, geschieht dieses gewöhnlich auf einem hohen Abstraktionsniveau. Die Suche wird entweder von einem sensorbezogenen Standpunkt, oder aber beobachtungsbezogen durchgeführt. Ein Nutzer sucht im Allgemeinen sensorbezogen, wenn er bereits Kenntnisse über Sensoren in einer Gegend hat und nun deren Messwerte abfragen möchte. Beobachtungsbezogen sucht ein Nutzer immer dann, wenn er in einer bestimmten Gegend Sensordaten erhalten möchte. Ihm sollen dann alle Messungen, die einem bestimmten Phänomenen zugehören, angezeigt werden.

Abbildung 1 - Vorgehensweise eines Nutzers beim Finden von Sensordaten

Begriffswelt um den Sensor Observation Service

Das OGC hat – nicht nur Rahmen des SOS – eine eigene wohldefinierte Begriffswelt. Zum besseren Verständnis hier einige wichtige Begriffe:

Begriff	Beschreibung
Feature of Interest (FOI)	Das ~ repräsentiert das Geoobjekt, für das die Messwerte gelten und das von Sensoren gemessen wird. Über das FeatureOfInterest erfolgt in der Regel die Verortung (Georeferenzierung) der Messpunkte, d. h. das Geoobjekt besitzt Koordinaten (z. B. Länge/Breite und Höhe über NN). Die Festlegung des FOI hängt sehr stark vom Projekt ab und muss je nach Struktur gewählt werden.
Observation	Eine ~ liefert einen Messwert (Result) für die Eigenschaft (Phenomenon) eines observierten Objekts (FeatureOfInterest). Der Wert selbst wird durch einen Sensor oder Prozeduren erzeugt (Procedure). Ferner wurde das Phänomen zu einem bestimmten Zeitpunkt erfasst (SamplingTime) und der Wert an einem bestimmten Zeitpunkt erzeugt (ResultTime). Häufig stimmen die Werte überein, weshalb in der Praxis dann die SamplingTime als Zeitpunkt der Observation verwendet wird.
Offering	Ein ~ ist eine logische Gruppierung von miteinander in Bezug stehenden Observationen, welche gemeinsam von einem Dienst angeboten werden.
Phenomenon	Ein ~ (Phänomen) stellt eine Eigenschaft (physikalische Größe) eines Geoobjekts dar. (Lufttemperatur, Windgeschwindigkeit, Schadstoffkonzentration der Atmosphäre, Reflektierte Strahlung in bestimmten Frequenzband, etc.)
Procedure	Eine ~ (Prozedur) erzeugt den Messwert einer Observation. Dieses kann durch das Auslesen eines Sensors, Simulation oder auch einen numerischen Prozess geschehen.
In-situ	~ ist der lateinische Begriff für „vor Ort und Stelle“.

Software

Der SOS ist ein Standard des OGC und definiert letztlich nur die Serviceschnittstelle, nicht aber wie der Service implementiert wird. Es gibt derzeit mehrere OpenSource Umsetzungen des Dienstes:

• Java-SOS-Implementierung von 52°North
• Java-SOS-Implementierung innerhalb des Frameworks deegree der Firma lat/lon
• die C++-SOS-Implementierung in MapServer
• Java-, Perl- und Python-SOS-Implementierungen des OOSTethys-Projekts

Weblinks

• OpenGIS Sensor Observation Service auf der Website des OGC
• Webseite der SensorWeb Allianz SWA

• SOS-Implementierung von 52°North
• OOSTethys-Projekt

Standards des Open Geospatial Consortiums (OGC)

CityGML | GML | GMLJP2 | GeoRSS GML | GeoXACML | KML | Filter Encoding | GO | Simple Feature Access | ED/SLD

Web Service Framework

Web Service Common | OpenLS/OLS | TJS

Sensor Web Enablement (SWE): O&M | SensorML | TML | SOS | SPS

OpenGIS Web Services (OWS): WCAS/CSW | WCTS | WCS | WCPS | WFS | WMC | WMS | WMTS | WPS | W3DS