"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Sensor Observation Service 2.0.0

For SOS 1.0.0, click here.

The Bigger Picture - Sensor Web Enablement (SWE)

This section is an extract from OGC 06-021r4 Section 6 Sensor Web Enablement and OGC Sensor Web Enablement (SWE) 2012 web site OGC Standards section.

The Sensor Observation Service (SOS) is part of the Sensor Web Enablement (SWE) framework of standards. Sensor Web Enablement (SWE) extends the OGC web services and encodings frame-work by providing additional models, services and encodings to enable the creation of web-accessible sensor assets through common interfaces and encodings . Referring to the diagram below, SWE services are designed to enable discovery of sensor assets and capabilities (1), access to those re-sources and data retrieval (5 and 6), as well as subscription to alerts (2, 3 and 4), and tasking of sensors to control observations (2).

SWE Overview

The main adopted or pending OGC Standards in the SWE framework include:
  • Observations & Measurements (O&M) - The general models and XML encodings for observations and measurements.
  • Sensor Model Language (SensorML) - standard models and XML Schema for describing the processes within sensor and observation processing systems.
  • Transducer Markup Language (TML) - Conceptual model and XML encoding for supporting real-time streaming observations and tasking commands from and to sensor systems.
  • Sensor Observation Service (SOS) - Open interface for a web service to obtain observations and sensor and platform descriptions from one or more sensors.
  • Sensor Planning Service (SPS) - An open interface for a web service by which a client can 1) determine the feasibility of collecting data from one or more sensors or models and 2) submit collection requests.
Other SWE standards are under discussion or in various stages of development.


This section is an extract from OGC 12-006 Introduction section.

The function for SOS in the SWE framework is to provide a standardized interface for managing and retrieving metadata and observations from heterogeneous sensor systems. Sensor systems contribute the largest part of geospatial data used in geospatial systems today. Sensor systems include for example in-situ sensors (e.g. river gauges), moving sensor platforms (e.g. satellites or Autonomous Unmanned Vehicles) or networks of static sensors (e.g. seismic arrays). Used in conjunction with 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.

Observation Model Overview

This section is an extract from OGC 12-006 section 6 Observation Model Overview.

SOS is primarily designed to provide access to observations. It relies on the Observations and Measurements (O&M) [ISO 19156:2010] standard to encode data gathered by sensors. An XML encoding of this conceptual model is defined in the OGC implementation specification [OGC 10-025]. The basic Observation model is depicted in diagram below :

O&M Model

An Observation provides a result whose value is an estimate of a property of the observation target, the feature of interest ; i.e. an observation is a property-value-provider for the feature of interest. An instance of an Observation is classified by its phenomenonTime, featureOfInterest, observedProperty, and the procedure used. The procedure is usually a sensor but can also be for example a computation or post-processing step. More detailed information about the observation data model can be found in [ISO 19156].

SOS 2.0.0 Model Overview

This section is an extract from OGC 12-006 section 7 SOS Model Overview and .

As shown in the model below, the Core of the SOS 2.0 builds upon certain specifications. Based on the Core, extensions can be defined to add further functionality.

SOS Model

The SOS Core defines three mandatory operations:

Following are the extensions of the SOS core which specify additional operations (optional) as listed below:

Enhanced Operations Extension:

Transactional Extension:

Result Handling Extension:

Filter Operations

This section is an extract from OGC 12-006 section Filter Capabilities Section.

The following are the minimum required filter operations for SOS 2.0.0 :

Phenomena and Units of Measure (informative)

This section is an extract from OGC 12-006 section 16 Annex C - Phenomena and Units of Measure (informative)

Identifying and referencing Phenomena and Units of Measure

A critical issue for interoperability is defining a standard way to refer to the phenomena that are measured by sensors and the units of measure for those phenomena. This is important for both
  1. discovery of SOS service instances in a catalog and
  2. to parameterize a request to a given service instance that offers a choice of observed properties.
As SOS is intended to be used in a very wide variety of applications in a large number of application domains it is not feasible to construct a single comprehensive and authoritative dictionary for phenomena and units of measure. Observable phenomena include most properties of all feature types in all application domains. The range of different phenomena and units of measure is large, unknown apriori, and in fact both unknowable and incomputable. Phenomena and units of measure are often specific to a given domain and the mechanism used to reference them must support a decentralized approach.

One goal of SOS and SWE in general is to specify a standard mechanism for consistently identifying phenomena and units of measure that will scale (up or down) to handle any number of definitions in any application domain. The mechanism for identifying phenomena and units of measure must be flexible enough to handle this.

The solution for identifying phenomena and units of measure is to use external references. These may resolve to resources expressed in a variety of forms, utilizing various technologies including semantic web representations. GML dictionaries provide a relatively lightweight format which is compatible with the GML representation of data and web-based addressing patterns used by SOS. Services and clients use URIs to refer to specific entries in a particular GML dictionary.

The URI might be a URN in cases where the reference is to phenomena or units of measure that are defined by an OGC dictionary or a dictionary hosted by another well-known organization. URN values using OGC as the authority must follow the format specified in OGC document 06-023r1 - Definition identifier URNs in OGC namespace.

A URL may be used when the reference is to a new or non-standard definition, for example in the case that a service provides its own dictionary or uses a third-party dictionary that is not well-known. If the specific definition is a sub-element within a dictionary provided as a single resource, then its URL must include a fragment identifier or XPointer to locate the definition within the dictionary.

Describing and defining Phenomena and Units of Measure

Entities like units of measure and phenomena are not physical objects in the real world. They are concepts and can only be defined by convention or by their relationship to other intangible concepts. Phenomena or units of measure that are defined in reference to other types can be considered to be derived or constrained entities and can be derived from more basic entities. Concepts like phenomena and units of measure occupy a different meta-level in the information modeling hierarchy, and their definitions are usually subject to more rigorous governance arrangements, compared with “instance” level data, such as observations and sensor instances. Hence, they will ideally be managed in a registry environment. The GML Dictionary representation may be thought of as a “static” view of such a collection of resources that would usually be provided by a service, such as a register or catalogue.

The SWE initiative relies on the existing GML support for identifying or defining units of measure. This is based on the usual hierarchy of base, derived and “other” (or “conventional”) units, such as defined by the Systeme International. The mechanism for deriving units is well-defined and can be done automatically using software as long as the base units are commonly understood. Ideally, though, UCUM symbols are used.

A GML conformant schema for describing phenomena derived by combination and/or constraining base phenomena was developed as part of the SWE initiative. This schema allows for the definition of base phenomena in much the same way that base units are defined in GML. Derived phenomena can be developed as a constraint on an existing phenomenon, an aggregation of existing phenomena, or as a composite of existing phenomena. SensorML 1.0.1 contains a schema for describing such phenomena.

Relationship to Web Feature Service (WFS) (informative)

This section is an extract from OGC 12-006 section 17 Annex D - Relationship to Other OGC Web Service Standards (informative)

The approach that has been taken in the development of SOS, and the SWE specifications on which it depends, is to carefully model sensors, sensor systems, and observations in such a way that the model covers all varieties of sensors and supports the requirements of all users of sensor data. SOS leverages the standard properties of these two data types (sensors, observations) to provide specialized operation signatures for observation data.

This may be contrasted with the approach taken in the Web Feature Service (WFS). WFS is based on a generic definition of a geographic feature that is flexible enough to encompass any real-world entity, and uses GML application schemas to define the feature type exposed by a specific service instance. Hence, the WFS “get data” request is highly parameterized since it must be fully generic. With this approach, interoperability requires organizations to agree on domain-specific GML application schemas. Clients that access a WFS for rich processing in a particular domain must have a-priori knowledge of the application schemas used in that domain.

The SOS defines a common model for all sensors, sensor systems and their observations. This model is “horizontal” since it applies to all domains that use sensors to collect data. The domain-specific details are encapsulated in the second layer (features-of-interest, observed properties, sensor descriptions) allowing the basic “observation” to be processed by a generic client. In that sense, the SOS also provides feature rich access to observation data and metadata.

How to Couple SOS and WFS

Example 1 : Relationship between SOS and WFS where WFS is providing features of interest


The SOS is providing dynamic property values encoded in O&M observations for certain features of interest. These features are provided by an external WFS. For example, the SOS is providing surface temperature for a certain lake. Then the dynamic surface temperature values are provided by the SOS whereas the feature of interest, the lake, is provided by a WFS instance. As described above, the advantage for using an SOS is that it offers the surface temperature values and its metadata in the well-defined O&M format and that pre-defined filters (such as for time, location or producing procedure) can be used instead of the generic GetFeature operation of the WFS for retrieving the observations.

Example 2 : Relationship between SOS and WFS where SOS is encapsulating WFS


In this case, the SOS is using a WFS at the backend for handling the features of interest. The SOS offers both the observations as well as the features of interest. In the example above, the client can retrieve the surface temperature observations as well as the feature of interest, the lake, from the same SOS instance. The operation for retrieving features of interest through the SOS interface is kept very simple, as there is only a limited set of query parameters.

The two examples above point out that it is not a question whether you want to use either SOS or WFS, but a question of how to combine or couple the two services. As stated above, the SOS describes a WFS profile with pre-defined observation feature types contained in the O&M specification and specialized operation signatures for retrieving these observations. Usually, it is used for providing dynamic property values for certain features of interest in the form of time series. These features of interest can be served either by the SOS instance itself (via GetFeatureOfInterest operation) or by an external WFS.


Topic attachments
I Attachment Action Size Date Who Comment
OM_Model.jpgjpg OM_Model.jpg manage 51.2 K 17 Nov 2011 - 16:18 FlorenceTan O&M Model
SOSWFS1.jpgjpg SOSWFS1.jpg manage 19.9 K 18 Nov 2011 - 14:50 FlorenceTan WFS Providing Featores of Interest
SOSWFS2.jpgjpg SOSWFS2.jpg manage 20.4 K 18 Nov 2011 - 14:50 FlorenceTan SOS is encapsulating WFS
SWEFramework.jpgjpg SWEFramework.jpg manage 26.9 K 18 Nov 2011 - 11:05 FlorenceTan SWE Services and Encodings Interactions
sos_model.jpgjpg sos_model.jpg manage 30.5 K 27 Sep 2012 - 09:17 FlorenceTan SOS 2.0 Model
Topic revision: r11 - 27 Sep 2012, FlorenceTan

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).