Introduction

A Sensor Observation Service provides an API for managing deployed sensors and retrieving sensor data and specifically “observation” data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today.

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.

For SISS, we would be implementing SOS 2.0.0 candidate specification (OGC 10-037).

Overview

This section is an extract from OGC 06-009r6 section 6.1 General Approach.

The goal of SOS is to provide access to observations from sensors and sensor systems in a standard way that is consistent for all sensor systems including remote, in-situ, fixed and mobile sensors. This is a challenging task because the users of sensor data have historically been divided into those who primarily deal with in-situ sensors and those who primarily deal with remote sensors. The terminology, perspective, and expectations of these two broad groups are different.

SOS leverages the Observation and Measurements (O&M) specification for modelling sensor observations and the TransducerML and SensorML specifications for modelling sensors and sensor systems.

Operations

DescribeSensor - provides detailed information about the sensors and processes generating those measurements.

GetObservation - provides access to the sensor observations and measurement data via a spatio-temporal query that can be filtered by phenomena.

Other non-mandatory operations include:

RegisterSensor

InsertObservation

GetResult

GetFeatureOfInterest

GetFeatureOfInterestTime

DescribeFeatureOfInterest

DescribeObservationType

DescribeResultModel

Observation Offerings

This section is an extract from OGC 06-009r6 section 6.3 Observation Offerings.

A SOS organizes collections of related sensor system observations into Observation Offerings. The concept of an Observation Offering is often equivalent to that of a sensor constellation discussed in the introduction to this document. An Observation Offering is analogous to a “layer” in Web Map Service because each offering is typically a nonoverlapping group of related observations. Each Observation Offering is constrained by a number of parameters including the following:

Specific sensor systems that report the observations,

Time period(s) for which observations may be requested (supports historical data),

Phenomena that are being sensed,

Geographical region that contains the sensors, and

Geographical region that contains the features that are the subject of the sensor observations (may differ from the sensor region for remote sensors)

An SOS service instance should factor these classifiers into offerings such that in response to a GetObservation request the likelihood of getting an empty response for a valid query should be minimized.

Identifying and referencing Phenomena and Units of Measure

This section is an extract from OGC 06-009r6 section 6.4 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 (i) discovery of SOS service instances in a catalog and (ii) 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.

Describing and defining Phenomena and Units of Measure

This section is an extract from OGC 06-009r6 section 6.5 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 modelling 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.

Filtering and Filter Expressions

This section is an extract from OGC 06-009r6 section 6.6 Filtering and Filter Expressions.

The SOS GetObservation operation includes an ad-hoc query capability that allows a client to filter observations by time, space, sensor, and phenomena. This leverages the OGC Filter Encoding specification. However, the SOS augments the ad-hoc query capability with typed filter expressions bound to the standard observation properties.

The GetObservation operation factors the spatial, temporal, and property-based query components into separate query elements. Instead of allowing a general filter expression, the filter is built up using a set of specific elements which have very clear semantics and restricted scope. This strategy is enabled by and is a corollary of the fact that SOS is designed to support a predefined information model (observations).

The capabilities document for SOS includes a FilterCapabilities section that is used to indicate the query parameters supported by the service. The filter capabilities element has been broken up into spatial capabilities, scalar capabilities, ID capabilities, and temporal capabilities. The factored design of the filter capabilities reflects the factored approach to query expressions in SOS.

Supported Filters

The following filter operations are supported for the SOS 1.0.0 GetObservation operation:

spatial filters:

Contains

Intersets

Overlaps

BBOX

temporal filters:

T_Equals

T_After

T_Before

T_During

result filters:

PropertyIsEqualTo

PropertyIsNotEqualTo

PropertyIsLessThan

PropertyIsGreaterThan

PropertyIsLessThanOrEqualTo

PropertyIsGreaterThanOrEqualTo

PropertyIsLike

PropertyIsNull

PropertyIsBetween

Service Discovery

This section is an extract from OGC 06-009r6 section 7.2.2 Service Discovery.

Service discovery is accomplished by using one or more OGC Catalog Service (CS-W) instances. The CS-W specification allows entities to be registered so that they can later be discovered by data consumers. It is also expected that catalogs may periodically harvest information from the capabilities documents of each service they know about in order to keep that service’s attributes up to date. OGC Catalog Services allow the following information to be used for discovery:

Time period of observations

Phenomena captured by observations

Spatial extent of observations

GML names used in observation offerings

GML descriptions used in observation offerings

OGC Catalogs may additionally enable discovery based on other parameters, such as the feature of interest, procedure/sensor, sampling rate.

Observation Discovery

This section is an extract from OGC 06-009r6 section 7.2.3 Observatioin Discovery.

Observation discovery happens at the service level. The capabilities offerings that are available from a service can be used to further target GetObservationd requests. This is an optional step and can be skipped in many cases if the catalog response has sufficient information for the purpose of the consumer.

Get Sensor Metadata

This section is an extract from OGC 06-009r6 section 7.2.4 Get Sensor Metadata.

Sensor metadata can be retrieved for any sensor that is advertised in an observation offering using the DescribeSensor operation. This will return a SensorML or TML document with detailed information about the sensor. This might be used to filter out observations produced by sensors that, for example, do not have robust enough error detection and correction or are not accurate enough for the purposes of the data consumer. This is an optional step that may be skipped in many cases.

NOTE: The available sensors are identified in the GetCapabilities response, so may also be harvested by a registry that is indexing the service.

Get Sensor Observations

This section is an extract from OGC 06-009r6 section 7.2.5 Get Sensor Observations.

Sensor observations are obtained using the GetObservation operation. This operation supports a selection mechanism that supports subsetting the observations that will be returned from a call to GetObservation. GetObservation allows the client to filter a large dataset to get only the specific observations that are of interest.

NOTE: The GetObservation operation is used for observation access and not generally for discovery, which is instead handled with ObservationOffer elements of the SOS Capabilities document and queries of online registry services.