Sensor Observation Service: Unterschied zwischen den Versionen

Der Sensor Observation Service (SOS) ist ein Webservice zur Abfrage von Echtzeit-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.

Begriffswelt um den Sensor Observation Service

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

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 Open-Source-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

• SOS-Implementierung von 52°North
• OOSTethys-Projekt des OGC Network