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.
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:
Also, proprietary implementations exist.[7]