Sensor Observation Service

The Sensor Observation Service (SOS) is a web service to query real-time sensor data and sensor data time series and is part of the Sensor Web. The offered sensor data consists of data directly from the sensors, which are encoded in the Sensor Model Language (SensorML), and the measured values in the Observations and Measurements (O & M) encoding format. The web service as well as both file formats are open standards and specifications of the same name defined by the Open Geospatial Consortium (OGC).

If the SOS supports the transactional profile (SOS-T), new sensors can be registered on the service interface and measuring values be inserted. A SOS implementation can be used both for data from in-situ as well as remote sensing sensors. Furthermore, the sensors can be either mobile or stationary.

Since 2007,^[1] the SOS is an official OGC standard. The advantage of the SOS is that sensor data - of any kind - is available in a standardized format using standardized operations. Thus the web-based access to sensor data is simplified. It also allows easy integration into existing Spatial Data Infrastructures or Geographic Information Systems.

In 2016 OGC approved the SensorThings API standard specification, a new RESTful and JSON-based standard provide functions similar to SOS. As both SensorThings API and SOS are based on the OGC/ISO 19156:2011, the two specifications have been demonstrated in an OGC IoT pilot that they can interoperate with each other.^[2]

The SOS has three so-called core operations that must be provided by each implementation. The GetCapabilities operation allows you to query a service for a description of the service interface and the available sensor data. For using the SOS, the GetObservation function is probably the most important. It can be utilized to retrieve data for specific sensors. The DescribeSensor function returns detailed information about a sensor or a sensor system and the producing processes.

• GetCapabilities returns an XML service description with information about the interface (offered operations and endpoints) as well as the available sensor data, such as the period for which sensor data is available, sensors that produce the measured values, or phenomena that are observed (for example air temperature).
• GetObservation allows pull-based querying of observed values, including their metadata. The measured values and their metadata is returned in the Observations and Measurements format (O & M).
• DescribeSensor - provides sensor metadata in SensorML. The sensor description can contain information about the sensor in general, the identifier and classification, position and observed phenomena, but also details such as calibration data.

• RegisterSensor allows to register a new sensor in a deployed SOS.
• InsertObservation can be used to insert data for already registered sensors in the SOS.

• GetResult provides the ability to query for sensor readings without the metadata given consistent metadata (e.g. sensor, observed object).
• GetFeatureOfInterest returns the geoobject whose properties are monitored by sensors in Geography Markup Language encoding.
• GetFeatureOfInterestTime provides time periods in which measurements of an observed object in the SOS are available.
• DescribeFeatureType returns the type of the observed geoobjects (XML Schema)
• DescribeObservationType returns the type of observation (XML Schema), such as om: Measurement).
• GetObservationById allows to query a specific observation using an identifier returned by the service as response to an InsertObservation operation.
• DescribeResultModel provides the XML Schema of the measured value, which is particularly important for complex measurements, such as multi-spectral data.

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

Term	Description
Feature of interest (FOI)	The ~ represents the geoobject who is subject to the measured values and is measured by sensors. The FOI is usually the means of locating (geocoding) the measuring points, i.e. the geoobject has coordinates (for example latitude, longitude and altitude). It depends very much on the project and must be chosen depending on the task at hand.
Observation	An ~ gives a measurement (result) for the property (Phenomenon) of an object under observation (FOI). The value itself is generated by a sensor or by procedures (procedure). Furthermore, the phenomenon was detected at a particular time (sampling time) and generated the value at a particular time (Result Time). Often these two time values are consistent, so in practice the sampling time is used as the time of observation.
Offering	An ~ is a logical grouping of observations that are related to each other, which are jointly offered by a service.
Phenomenon	A ~ is a property (physical quantity) of a geoobject. Examples are air temperature, wind velocity, pollutant concentration of the atmosphere, reflected radiation in certain frequency band, et cetera.
Procedure	A ~ produces the measured value of an observation. This can be done by reading a sensor, or a numerical simulation process.
In situ	~ is the Latin term for "on the spot."

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

• Java SOS implementation by 52°North^[3]
• Java SOS implementation within the deegree framework by the company lat/lon^[4]
• A C implementation of SOS in MapServer
• Java, Perl and Python implementations by the project OOSTethys^[5]
• A Python implementation as istSOS^[6]

Also, proprietary implementations exist.^[7]

• OpenGIS Sensor Observation Service on the OGC website