Skip navigation.
Home
OGC Network
 OGC® Home | OGC Network™ | OGC Forum
Home

Sensor Observation Service (SOS) Introduction

What is it?

The Sensor Observation Service (SOS) is an approved Open Geospatial Consortium standard. The standard defines a web service interface for the discovery and retrieval of real time or archived data produced by all kinds of sensors like mobile or stationary as well as in-situ or remote sensors.

The sensor data can be either observations or descriptions of the producing sensors containing metadata like calibration information, positions, etc. Observations are returned encoded as O&M Observations, while information about sensors are returned encoded in SensorML or TML. Used in conjunction with these OGC standards and other OGC specifications, the SOS provides a broad range of interoperable capability for discovering, binding to and interrogating individual sensors, sensor platforms, or networked constellations of sensors in real-time, archived or simulated environments.

What operations does the SOS offer?

The operations of the SOS are separated in four profiles. The Core Profile consists of the three basic operations which is provided by every SOS implementation. The optional Transactional Profile could be used for registering sensors and inserting observations into the SOS. The Enhanced Profile comprises additional optional operations. If a SOS implementation implements all operations, it implements the Entire Profile.

Core Profile

SOS has the following three mandatory core operations which provide its basic functionality:

  • GetCapabilities: The GetCapabilities operation returns a service description containing information about the service interface (e.g. supported operations, service version) and the available sensor data (e.g. registered sensors, time period of available observations, spatial extent of features for which observations are available).
  • DescribeSensor: The DescribeSensor operation returns a description of one specific sensor, sensor system or data producing procedure containing information like position of sensor, calibration, input- and outputs, etc. The response has to be either encoded in SensorML or in TML.
  • GetObservation: The GetObservation operation provides pull-based access to sensor observations and measurement-data via a spatio-temporal query that can be filtered by phenomena and value constraints.

    Transactional Profile

    There are two optional operations to support transactions:

  • RegisterSensor: The RegisterSensor operation allows sensor data providers to register new sensors with the SOS via the service interface by sending either a TML or a SensorML sensor description to the SOS.
  • InsertObservation: The InsertObservation operation allows the client to insert new observations for a sensor system. Sensor observations can only be inserted for sensors that have first been registered with the SOS.

    Enhanced Profile

    The Enhanced Profile defines the following additional operations which are optional for the SOS implementations to provide:

  • GetResult: The purpose of the GetResult operation is to allow a client to repeatedly obtain sensor data from the same set of sensors without having to send and receive requests and responses that largely contain the same metadata except for a new timestamp.
  • GetObservationByID: The GetObservationByID operation is designed to return an observation based on an identifier.
  • GetFeatureOfInterest: The GetFeatureOfInterest operation returns one or more descriptions of target features of observations (FeatureOfInterest).
  • GetFeatureOfInterestTime: The GetFeatureOfInterestTime operation returns the time periods for which the SOS will return data for a given FeatureOfInterest.
  • DescribeFeatureType: The DescribeFeatureType operation returns the XML schema for the specified GML feature which depicts a target feature of observations (FeatureOfInterest).
  • DescribeResultModel: The DescribeResultModel operation returns the XML schema for the result element of a certain observation type. This is of special interest for complex result elements, e.g. containing multi-spectral values.

    How can the SOS be used?

    The usage of the SOS could be described from two user perspectives: the sensor data publisher perspective and the data consumer perspective.

    Consumer Perspective

    Figure 1 depicts a sequence diagram that shows a sensor data consumer discovering two SOS instances from a CS-W catalog by using the GetRecords operation. The consumer then performs service-level discovery on each service instance by requesting the capabilities document and inspecting the observation offerings. The consumer invokes the DescribeSensor operation to retrieve detailed sensor metadata in SensorML or TML for sensors advertised in the observation offerings of the two services. Finally, the consumer calls the GetObservation operation to actually retrieve the observations from both service instances.

    Consumer Sequence

    Figure 1: SOS Consumer Sequence Diagram

    Sensor Data Publisher Perspective

    Figure 2 is a sequence diagram that shows how two sensor data producers interact with an SOS instance that supports the transactional profile. The first producer discovers the SOS using a CS-W catalog. The second producer has been configured to know the location of the SOS. When the producers determine that they are communicating with new sensors they register those sensors with the SOS. The producers publish sensor observations from all sensors in their control to the SOS. The diagram also shows a sensor data consumer. Consumers can request observations from the SOS at any time using the GetObservation operation. The consumer does not need to be aware of the existence of the producers and vice versa.

    SOS Data Provider Sequence

    Figure 2: SOS Sensor Data Publihser Sequence Diagram

    • Back to main SOS page

    AttachmentSize
    SOS_consumer_seq.JPG40.75 KB
    SOS_provider_seq.JPG44.22 KB