Sensor Observation Service

Overview

The OGC Sensor Observation Service (SOS) is part of the OGC Web Services (OWS) initiative. As such it supports the generalized OWS services GetCapabilities , DescribeX, and GetX methods. In the particular case of SOS these methods are GetCapabilities , DescribeSensor, and GetObservation (which doesn't truly conform to the general OWS service description...) It also defines a number of optional services RegisterSensor, InsertObservation, GetResult, GetFeatureOfInterest, GetFeatureOfInterestTime, DescribeFeatureOfInterest, DescribeObservationType, and DescribeResultModel. Of these optional services GetResult seems to be most in line with the general OPeNDAP value of "send the data as compactly as possible" since it allows the client to minimize the transmission of ancillary metadata associated with the transmitted values of Observations.

Required Operations

These three server operations are required

ows:GetCapabilities

In response to an ows:GetCapabilities request with a service attribute set to SOS an SOS service returns an sos:Capabilities document. The sos:Capabilities document is formed form of the three OWS defined sections ows:ServiceIdentification, ows:SeriviceProvider, and ows:OperationsMetadata. There are two additional sections, sos:FilterCapabilities and sos:Contents which contain information unique to the SOS service semantics.

Content Sections

ows:ServiceIdentification, ows:SeriviceProvider, ows:OperationsMetadata

These three parts of the sos:Capabilities responses are defined in the OWS specification. The contents of these documents are very site specific, and unlikely change very often. I think an implementation strategy for this would simple be static files, or records in a database with a user interface for making changes (I say - why not a file? It's easy!)

sos:FilterCapabilities

In this section the server advertises which of the OGC Filter Encoding (Sub-setting) activities it supports. Again this information is unlikely to change very often (probably only through server upgrades) so it could be cached in files or a database.

sos:Contents

This section contains the "meat" of the sos:Capabilities document: A list (or catalog if you will) of all of the sos:ObservationOfferings available from the service. These sos:ObservationOffering elements each of which represents/describes a collection os related sensor system observations.

sos:ObservationOffering

The section (clause) 6.3 of the SOS specification describes the sos:ObservationOffering as follows:

An 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 non-overlapping 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.

For example, suppose an SOS instance advertises two sensors – one that reports wind speed and the other that reports air temperature. If these sensors are attached to the same weather station, they should probably be included in the same offering. That is because a GetObservation request for weather data for a given area that includes the weather station to which the sensors are attached and for time periods that the weather station is reporting will almost always have data for both sensors. If the client asks for wind speed only, air temperature only, or both, the time and location of the results should be the same.

On the other hand, if the two sensors are located on weather stations that are far apart in space or which report during non-overlapping time periods, then they should probably be factored into two distinct offerings. If they were put into the same offering, then the combinatorial space of that single offering would be relatively sparse. In other words, it would frequently be the case that a GetObservation request asking for temperature might return a result where one for wind speed might not. The client might have to make quite a few GetObservation requests on a “sparse” offering before finding data, which is clearly undesirable.

This definition makes it clear that the organization and content of each ObservationOffering is tightly coupled to the types of sensors, what phenomena they measure, and how they are organized in the physical world. Thus each sos:ObservationOffering is in essence a logical data set whose structure must be determined by humans.

From the practical standpoint of writing server software to provide SOS services it would seem that each sos:ObservationOffering would be carefully defined and handwritten by someone familiar with sensor system(s) whose data is being made available through the SOS service. Automatic generation of the sos:ObservationOffering content appears to be beyond the ability (scope?) of current systems to produce. The SOS specification does provide an (optional) API through which clients might learn about the structure of the documents produced by the service via a set of requests that return XML schema documents describing the features, observations, and result models used by the service (sos:DescribeFeatureType, sos:DescribeObservationType, and sos:DescribeResultModel respectively). However constructing these schemas, along with instances of the sos:ObservationOffering content still appears to be a human centric activity and not likely to be done through some kind of automation.

sos:DescribeSensor

The sos:DescribeSensor is used to request a SensorML document that provides a detailed description of the sensor. SensorML is a complex standard that is intended to provide a language that can describe all possible sensors, sensor networks, sensor data processing, and sensor data. The last is significant in that SensorML does define a data model. Unfortunately the SOS specification is quite vague regarding how SensorML should be used to return the sensor description. Section (clause) 8.3.3 of the SOS specification states:

"A SensorML or TML document describing the sensor system."

And that's all it says on the matter.

I think from an implementation perspective this information, like the previous content, represents material that is very site/service specific and will have to be generated by hand by humans. Given the complexity of the SensorML specification it would probably be useful (but probably not practical) to provide a GUI/form based tools for helping people create sensor descriptions that can be stored as SensorML documents.

sos:GetObservation

"The GetObservation operation is designed to query a service to retrieve observation data structured according to the Observation and Measurement specification."

The Observation and Measurement Specification (OM) provides a model for describing observations. The model is meant to provide a user-centric view point by emphasizing semantic of features in contrast to the sensor/process view of the same information which provides a more provider oriented viewpoint. The OM is used to develop specialized schemas and vocabularies for different application domains by building on semantics inherited from the OM.

In practice this means that any given producer of data (be it a single individual, a group working in a laboratory, or institution) will most likely be required to define their own application domain using the OM model, or they will need to locate a predefined one which matches the way their work is organized and conducted. Either way the result is that the OM model and documents it produces for a particular instance of sensor/instrument deployment is something that cannot be pre-configured into an SOS service.

It may be possible to generate template XML documents for each Observation (corresponding to each sos:ObservationOffering in the sos:Capabilities document) that can be used to create instance documents for the responses to sos:GetObservation requests.

Optional Operations

There are a number of optional operations (services) defined by the SOS specification. The specification organizes them into two groups:

Transaction Operations Profile (optional)

sos:RegisterSensor - Allows a client to register a new sensor system with the SOS.

sos:InsertObservation - Allows a client to insert new observations from a sensor system in to the SOS.

Enhanced Operations Profile (optional)

sos:GetObservationById - Returns an observation based on an identifier. The identifier may determined from any source, possible from the SOS response to an sos:InsertObservation command.

sos:GetResult - Allows a client to repeatedly obtain sensor data without having to send requests and receive responses that contain largely the same material with the exception of the time-stamps and sensor data content. This is accomplished by the client first sending a sos:getObservation request with the responMode="resultTemplate". The server will return a collection of Observation templates. The client is then free to send sos:GetResult requests using sos:ObservationTemplateId values gleaned from the Observation Templates.

sos:GetFeatureOfInterest - returns a GML feature instance corresponding to the FeatureOfInterestId submitted in the request

sos:GetFeatureOfInterestTime - Returns the time periods for which the SOS will return data for a given advertised feature of interest.

sos:DescribeFeatureType - Returns an XML schema for a specified GML feature advertised in the sos:Capabilities document.

sos:DescribeObservationType - Returns the XML schema that describes the Observation type that is returned for a particular phenomenon. This allows the SOS to list the set of Observation types that it can deliver (by default the value is "om:Observation").

sos:DescribeResultModel - Returns the schema for the result element that will be returned when the client asks for the given result model by the given ResultName.

Implementations

52North

52north has implemented an SOS. Their implementation uses PostGIS to store the data and the metadata used in generating the service responses. There are a couple of interesting things about their design: They have created a software framework for the server that handles all of the SOS procedural activities while factoring out the interface that provides the actual SOS documents internally. The documentation indicates that this was intended to allow developers to connect the framework to another data source (Other than their default PostGIS database). There is also another project at 52north called SOSFeeder which is a piece of software meant to provide ingest services for their SOS. The SOSFeeder can work on both push and pull relationships with the sensor data source.

• It may be possible to write a version of SOSFeeder that can pull data from a DAP data source.
• It might be possible to subclass their existing PGSQLDAOFactory and associated class to build a version of the DAO that retrieves data at request time from a DAP server for inclusion in the SOS documents.
• Some combination of the previous two might be required.