How to retrieve information about the observations and sensor metadata provided by a SOS 2.0?

Service metadata can be retrieved as the so-called Capabilities document by invoking the GetCapabilities operation. The general structure of the SOS 2.0 Capabilities document conforms to what is defined by the OWS Common standard, and hence SOS 2.0 Capabilities documents look similar to the Capabilities documents of all other OGC web services. The figure below  shows the sections of an SOS 2.0 Capabilities document.

  • Light blue sections: defined by [url=]OWS Common[/url] standard.
  • Light green section: defined by the [url=]Filter Encoding [/url] standard.
  • Dark blue sections: defined by the SOS 2.0 standard.


  • The ServiceIdentification section provides common information about the service (e.g. service version, type of service, etc.)
  • The ServiceProvider section states contact information about the responsible party of the SOS server.
  • The OperationsMetadata section lists the operations supported by a service and the supported parameters (optional: listing of supported parameter values)
  • The InsertionCapabilities section provides metadata, if the insertion of sensors and observations is supported by the SOS.
  • The filterCapabilities section lists the supported temporal and spatial filter operators (e.g. spatial Intersects) and operands (e.g. gml:Polygon).
  • The Contents section of a Capabilities document advertises the data which is provided by the SOS.

Observation Offering

In the SOS, observations are grouped into layers per each sensor system. These layers are called ObservationOffering (or short: offering). A sensor system can be a simple thermometer, but can also consist of several sensors or even sub-(sensor)systems. For example, a valid sensor system can be a system of sensors attached to a weather station, or it can be a network of spatially distributed sensors.

The observation offering lists the metadata for its associated observations including the sensor system which made the observations of the offering. However, observations from one particular sensor can be assigned to multiple offerings (belonging to the same sensor). This way some functionality is given which allows grouping of observations according to certain thematic criteria, for example the grouping of observations per county, region, state etc. Another example would be some kind of pre-filtered observations, such as severe and all weather forecasts. To summarize, there is a 1:n relationship between procedures and observation offerings and there is a n:m relationship between observations created by these procedures and observation offerings.

The basic properties of an observation offering are:   (dark green colored in the figure below)

  • identifier: a unique string identifying the offering within the service 
  • procedure: the (physical / virtual) sensor (system) which produced ALL the observations associated with the offering
  • observed area: the geographical area within which the associated observations were made
  • phenomenon time: the time frame between which the results of the associated observations apply to the observed properties
  • result time: the time frame between which the results of the associated observations were measured

To reduce the size of the Capabilities document, SOS 2.0 introduces the so-called property inheritance mechanism. The principle of this mechanism is shown in the figure below. Now, the property inheritance mechanism enables observation offerings to inherit certain properties from the Contents section. This is in particular helpful, if multiple observation offerings of an SOS server have the same metadata. Then, those metadata have to be stated only ones, namely by the Contents section. All observation offerings which do not 'redefine' the metadata listed in the Contents section automatically inherit those metadata.

Inheritable properties of the observation offering are:    (dark blue colored in the figure below)

  • observable properties: list of all the observed properties (e.g. 'temperature' or 'water level') of the observations associated with the observation offering
  • procedure description formats: the format (e.g. SensorML) in which descriptions of associated procedures can be encoded when calling the DescribeSensor operation
  • feature of interest types: the different types of features of interest of the observations grouped by this observation offering
  • response formats in which the associated observations can be encoded by the SOS (by default this is O&M 2.0 identified by the value ''), 
  • observation types: the types of observation which are used by the service to encode the observations associated with the offering
  • related features: features of which the service provider thinks they are worth linking to. This can be (but do not have to be) the features of interest of the offering's observations. However, in some use cases (e.g. mobile sensors) it makes no sense to list all sampling features (because there are too many). Hence, related features are not restricted to those features of a sampling campaign, but can be in general features which support the discovery of the associated observations.

The cardinalities (e.g. '0..*') of the different offering properties in the figure below, indicate how many instances of a particular property can / must be associated with one observation offering AFTER applying the property inheritance from the Contents section.


Example Use Cases


a) Stationary Sensor Network

In this example, an SOS 2.0 hosts sensor observations from a network of sensor stations. In this case, air quality is measured at air quality monitoring stations across Europe. Thereby, each station of the network has a set of sensors attached measuring a selection of NH3, H2S, CO and SO2.

Here is the link to the Capabilities document.

For each station, a separate observation offering is contained in the Capabilities. The contents section defines observable properties and related features. The observation offerings inherit those properties as long as they don't specify their own values for the properties.


a.2) Homogeneous Stationary Sensor Network

This example of a Capabilities document shows an alternative approach to example (a). In this case, all the stations of the network have the same set of sensors attached and thus the same observable properties are measured. Furthermore, we assume that the network is huge (> 1.000 stations) so that it is inefficient to list one offering per sensor system. Instead, we consider the network itself as a sensor system (of systems) and have only one offering.


b) Mobile Sensors

Here, an SOS 2.0 serves observations gathered by a mobile sensor. In this case, marine gliders are deployed in the Gulf of Mexico and attached with sensors measuring sea water temperature and salinity.

Please find the Capabilities document here.

For each mobile sensor glider, an observation offering is contained. Also in this case, the observation offerings inherit properties from the contents section.


Hi this page is a very

Hi this page is a very usefull: thanks for your workI want to let you know that some hyper-link are broken: i.e. a.2) the word "document" opens this link the correct link is without the "test" word: regards,Francesco Massa

Hello Massa, Thank you for

Hello Massa,

Thank you for the update. All of the links should be correct now.

Capabiltiies examples point

Capabiltiies examples point to password protected subversion respository.

Thanks, David, I changed it

Thanks, David, I changed it to a public repository.