Short description of the SOS standard

The OGC Sensor Observation Service (SOS) standard is applicable to use cases in which sensor data needs to be managed in an interoperable way. This standard defines a Web service interface which allows querying observations, sensor metadata, as well as representations of observed features. Further, this standard defines means to register new sensors and to remove existing ones. Also, it defines operations to insert new sensor observations. Sensor descriptions are encoded using the SensorML standard and sensor data (observations) using the O&M standard.

SOS operations

The OGC SOS 2.0 specification was adopted in 2012 and besides the core operations three extension are defined within the specification: Enhanced, Transactional, and Result Handling.

Core

  • GetCapabilities, for requesting a self-description of the service .
  • GetObservation, for requesting the pure sensor data encoded in Observation&Measurements (O&M).
  • DescribeSensor, for requesting information about the sensor itself, encoded in a Sensor Model Language (SensorML) instance document.

Enhanced Extension

  • GetFeatureOfInterest, for requesting the GML 3.2.1 encoded representation of the feature that is the target of the observation.
  • GetObservationById, for requesting the pure sensor data for a specific observation identifier.

Transactional Extension

  • InsertSensor, for publishing new sensors.
  • UpdateSensorDescription, for updating the description of a sensor.
  • DeleteSensor, for deleting a sensor.
  • UpdateSensorDescription, for publishing observations for registered sensors.

Result Handling Extension

  • InsertResultTemplate, for inserting a result template into a SOS server that describes the structure of the values of a InsertResult or GetResult request.
  • InsertResult, for uploading raw values accordingly to the structure and encoding defined in the InsertResultTemplate request.
  • GetResultTemplate, for getting the result structure and encoding for specific parameter constellations.
  • GetResult, for getting the raw data for specific parameter constellations.


The Role of SOS in SDDI

Currently, the Sensor Observation Service is in use in the SSD district London QEOP. The SOS facades has been set up for the following two sensors:

  • Weather stations - The weather stations are set up and operated by Intel UK and measure in total 15 properties in the park including temperature, humidity, wind speed etc. The observations are recorded every minute.
  • Smart Meters - The "fake" smart meters for 3 buildings have been set up by TUM, which measure electricity and gas consumption for the buildings every 30 minutes. The discussion is already in place with LLDC if the similar SOS facades can be set up for the real smart meters operated in the park by Engie.

More details about the implementations can be found here.

Standard Specification

Specification documents: http://www.opengeospatial.org/standards/sos

Implementations / Products

The following selection of products was made by the SDDI team and includes those implementations which are (or likely will be) used in the SSD project and from which we know that they are compatible with the requirements of the Smart Sustainable Data Infrastructure. Please note that the list is not a complete list of available or suitable SOS implementations. The Open Geospatial Consortium provides a catalog of implementations of their standards which can be found at http://www.opengeospatial.org/resource. Note that also the OGC list is not complete and not necessarily completely up-to-date.

SOS service implementations:

NameLicenseHomepageShort descriptionUsed in SSD districts
52° North SOSOpen Sourcehttp://52north.org/communities/sensorweb/sos/index.html

The 52°North SOS 4.x is a complete implementation of the SOS 1.0 and 2.0 specifications including all extensions. The 52°North SOS aggregates readings from live, in-situ and remote sensors. It runs on all major platforms (Windows, Linux, Mac OS X) and provides a RESTful binding extension. Tools for the batch import of sensor data (e.g. given in CSV format) are included.

London QEOP

istSOSOpen Sourcehttp://istsos.orgistSOS is an OGC SOS server implementation written in Python and allows for managing and dispatching observations from monitoring sensors according to the Sensor Observation Service standard. It runs on all major platforms (Windows, Linux, Mac OS X) and provides a RESTful binding extension.
OpenSensorHubOpen Sourcehttps://opensensorhub.orgOpenSensorHub (OSH) is a Free and Open Source Software (FOSS) community building a sensor hub platform to support web-enabled access to virtually any sensor system (simple to complex). OpenSensorHub is based primarily on the OGC Sensor Web Enablement (SWE) standards. OSH hubs and services have been deployed on Android smart phones and tablets, Raspberry Pi and various ARM platforms, on Arduino boards, on laptops and desktops, and on the Cloud.

SOS implementations of clients, interfaces, and libraries required to access and work with an SOS service:

 NameTypeLicenseHomepageShort descriptionUsed in SSD districts
52° North SOSWebclientOpen Sourcehttp://52north.org/communities/sensorweb/sos/index.html

The 52°North SOS 4.x package comes with two web clients. One with a map interface and a graphical viewer of sensor data (time series graphs), and one text-based interface for the testing of the CS/W operations.

London QEOP

QGIS SOS Client

Python Plugin for QGISOpen Sourcehttps://plugins.qgis.org/plugins/SOSClient/QGIS SOS Client is a plugin for the Open Source GIS Quantum GIS. It allows to request sensor observation data from an OGC Sensor Observation Service server and to generate plots with it.
istSOSWebclientOpen Sourcehttp://istsos.org

istSOS is an OGC SOS server implementation written in Python. The istSOS package comes with a web client with a map interface and a graphical viewer of sensor data (time series graphs). The package also provides code to view SOS data in combination with OpenLayers 3.


Additional Information

to be provided

  • No labels