Sensor Observation Service
Der Sensor Observation Service (SOS) stellt eine einheitliche Webserviceschnittstelle zur pull-basierten Abfrage von real-time Sensordaten sowie Sensordatenzeitreihen dar. Die angebotenen Sensordaten umfassen einerseits Beschreibungen von Sensoren, die in der Sensor Model Language (SensorML) enkodiert werden, sowie die Messwerte, die in dem Observations&Measurements (O&M) Format enkodiert werden. Beide Formate sind in gleichnamigen Spezifikationen des OGC definiert. Falls der SOS transaktional ist, können neue Sensoren über die Serviceschnittstelle registriert und anschließend Messwerte eingefügt werden. Der SOS kann sowohl Daten von In-situ- 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 (Open Geospatial Consortium). 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, die die Messwerte produzieren, oder Phänomene, die observiert werden (z. B. Lufttemperatur, enthält.
- GetObservation - pull-basierte Abfrage von Beobachtungswerten mit Metadaten; die Messwerte sowie ihre Metadaten werden in dem Observations&Measurements (O&M) Format zurückgeliefert.
- DescribeSensor - liefert Sensormetadaten in SensorML kodiert zurück. In dem SensorML Dokument sind in der Regel ID des Sensors, Position, sowie observierte 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 Observationen 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) enkodiert zurück
- GetFeatureOfInterestTime - liefert Zeitperioden, in denen Messwerte für ein observiertes Objekt im SOS vorhanden sind.
- DescribeFeatureType - liefert den Typ des observierten Geoobjekts zurück (XMLSchema)
- DescribeObservationType - liefert den Typen der Observation zurück (XMLSchema, z. B. om:Measurement)
- GetObservationById - ermöglicht die Abfrage einer Observation per ID
- GetResultModel - liefert das Xml-Schema des Messwertes; dies ist vor allem bei komplexen Messwerten, wie z. B. multispektral 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 Daten 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 potentieller Nutzer auf der Suche nach Sensoren geschieht dieses gewöhnlich auf einem sehr hohen Abstraktionsniveau. Die Suche wird entweder von einem sensorbezogenen Standpunkt, oder aber observationsbezogen durchgeführt. Ein Nutzer sucht im Allgemeinen sensorbezogen, wenn er bereits Kenntnisse über Sensoren in einer Gegend hat und nun Observationen zu den Sensoren abfragen möchte. Observationsbezogen sucht ein Nutzer immer dann, wenn er in einer bestimmten Gegend Sensordaten erhalten möchte. Ihm sollen dann alle Observationen, welche ein vom Nutzer spezifizierten Phänomenen zugehören, angezeigt werden. Doch auch hier interessieren den Nutzer nicht vordergründig die Sensoren, sondern die Messungen aus der Gegend.
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 observiert wird. Über das FeatureOfInterest erfolgt in der Regel die Verortung (Georeferenzierung) der Observationen, 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 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“. |
Anbieter von SOS-Implementierungen
Der SOS ist ein Standard des OGC und definiert letztlich nur die Serviceschnittstelle, nicht aber wie der Service implementiert wird. Es gibt derzeit drei OpenSource Umsetzungen des Dienstes:
- der SOS von 52°North (http://52north.org/)
- der SOS im deegree Framework der Firma lat/lon (http://www.deegree.org/)
- der SOS im UMN-Mapserver (http://mapserver.gis.umn.edu/)
Literatur
- Arthur Na (IRIS Corp.), Mark Priest (3eTI) vom 26. Oktober 2007; http://www.opengeospatial.org/standards/sos → 06-009r6_Sensor_Observation_Service.pdf abgerufen: 25. Mai 2008
- Judit Mays (deegree.org) 15.04.2008. [1] abgerufen: 14. 05 2008
- MapServer Stephen Lime, 15. Januar 2008 (http://mapserver.gis.umn.edu) abgerufen: 17. Mai 2008