Sensor observation service

from Wikipedia, the free encyclopedia

The Sensor Observation Service ( SOS ) is a web service for querying real-time sensor data and sensor data time series. The sensor data offered include, on the one hand, descriptions of the sensors themselves, which are coded in the Sensor Model Language ( SensorML ), and the measured values, which are coded in the Observations & Measurements ( O&M ) format. The web service and both file formats are open standards and are defined in the specifications of the same name of the Open Geospatial Consortium (OGC). If the SOS is transactional ( SOS-T ), new sensors can be registered via the service interface and measured values ​​can then be inserted. The SOS can provide data from both on-site and remote sensing sensors. Furthermore, the sensors can be both mobile and stationary.

The SOS has been an official OGC standard since 2007. The advantage of the SOS is that sensor data - no matter what kind - are available in a uniform format and via standardized operations on the Internet, thus simplifying web-based access to sensor data. Since the SOS is an OGC standard, it also enables simple integration into existing geoservice infrastructures or into general geographic information systems.

Operations

The SOS has three so-called core operations that must be offered by every SOS implementation. The GetCapabilities operation enables a service description to be queried with information about the service interface and the sensor data offered. The GetObservation function is probably the most important one for ongoing operations. This can be used to query measured values ​​from sensors. The DescribeSensor function returns detailed information about a sensor or a sensor system, the data supplied and the processes that process the data.

Core Operations (Core Profile):

  • GetCapabilities - returns an XML service description that contains information about the interface (offered operations) and the offered sensor data, such as B. Period of time for which sensor data is available, sensors that produce the measured values, or phenomena that are observed (e.g. air temperature).
  • GetObservation - pull-based query of observation values ​​with metadata; the measured values ​​and their metadata are returned in the Observations & Measurements format (O&M).
  • DescribeSensor - returns sensor metadata encoded in SensorML. The SensorML data record usually contains the ID of the sensor, the position and observed phenomena. Further information, such as. B. Calibration data are described.

Transactional Operations (Transactional Profile):

  • RegisterSensor - makes it possible to register a new sensor in a running SOS
  • InsertObservation - enables the insertion of measurement data for registered sensors in the SOS

Enhanced Operations (Enhanced Profile):

  • GetResult - offers the possibility, with constant metadata (e.g. sensor, observed object) for a series of measured values, to only query the measured value without the metadata
  • GetFeatureOfInterest - returns the spatial object, the properties of which are monitored by sensors, encoded in the Geography Markup Language (GML)
  • GetFeatureOfInterestTime - supplies time periods in which measured values ​​for an observed object are available in the SOS.
  • DescribeFeatureType - returns the type of the observed spatial object (XML schema)
  • DescribeObservationType - returns the type of observation (XMLSchema, e.g. om: Measurement)
  • GetObservationById - enables an observation to be queried by ID
  • DescribeResultModel - supplies the XML schema of the measured value; this is particularly important for complex measured values, such as B. multispectral data is important.

Using the methods

In addition to the core operations, there are additional operations that do not necessarily have to be implemented. In many projects, in addition to the basic functions, only the InsertObservation method is initially used. This enables external data to be entered into the ongoing Sensor Observation Service. The data is embedded in an XML file and transferred to the SOS strictly in accordance with the O&M specifications.

Finding services and sensors

If a potential user is looking for sensors, this is usually done on a high level of abstraction. The search is carried out either from a sensor-related point of view or else on an observation-related basis. A user generally searches sensor-related if he already has knowledge of sensors in an area and now wants to query their measured values. A user searches based on observation whenever he wants to receive sensor data in a certain area. All measurements that belong to a certain phenomenon should then be displayed to him.

Procedure for the Sensor Observation Service
Figure 1 - Procedure of a user in finding sensor data

Terminology around the Sensor Observation Service

The OGC has - not only in the context of the SOS - its own well-defined terminology. For a better understanding, here are some important terms:

term description
Feature of Interest (FOI) The ~ represents the geo-object for which the measured values ​​apply and which is measured by sensors. The FeatureOfInterest is usually used to locate (georeference) the measuring points, i. H. the spatial object has coordinates (e.g. length / width and height above sea level). The definition of the FOI depends very much on the project and must be selected depending on the structure.
Observation A ~ delivers a measured value (Result) for the property (Phenomenon) of an observed object (FeatureOfInterest). The value itself is generated by a sensor or procedures (procedure). Furthermore, the phenomenon was recorded at a certain point in time (SamplingTime) and the value generated at a certain point in time (ResultTime). The values ​​often coincide, which is why in practice the SamplingTime is used as the time of observation.
Offering A ~ is a logical grouping of related observations that are offered together by a service.
Phenomenon A ~ (phenomenon) represents a property ( physical quantity ) of a geo-object (air temperature, wind speed, pollutant concentration in the atmosphere, reflected radiation in a certain frequency band, etc.)
Procedure A ~ (procedure) generates the measured value of an observation. This can be done by reading out a sensor, simulation or a numerical process.
In-situ ~ is the Latin term for "on the spot".

software

The SOS is a standard of the OGC and ultimately only defines the service interface, but not how the service is implemented. There are currently several open source implementations of the service:

  • Java -SOS implementation from 52 ° North
  • Java SOS implementation within the deegree framework from lat / lon
  • the C ++ OS implementation in MapServer
  • Java, Perl and Python OS implementations of the OOSTethys project

Web links