5.4.1 Sensor Observation Service

From Geostandards

Jump to: navigation, search



Contents

Overview

The goal of the Sensor Observation Service (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. SOS leverages the O&M specification for modeling sensor observations and the SensorML specification for modeling sensors and sensor systems (sensor metadata). An SOS organizes collections of related sensor system observations into Observation Offerings. An Observation Offering is also analogous to a 'layer' in Web Map Service because each offering is intended to be a spatially and/or thematically non-overlapping group of related observations. The approach of the SWE specifications 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 O&M and SensorML to provide specialized operation signatures for observation data.

Operations

The SOS interface comprises of four profiles:

core profile

The core profile covers the mandatory operation, that have to be implemented by each SOS. The operations of the core profile build up the fundamental functionality of a SOS

GetCapabilities

The GetCapabilites operation allows for the identification of available sensor data, filter capabilities, and supported operations. The structure and syntax follows the specification from OWS Common.


GetObservation

The GetObservation operation provides access to sensor data encoded usually compliant to the O&M specification. It supports comprehensive spatial, temporal and thematic filter criteria.

example request:

  <?xml version="1.0" encoding="UTF-8"?>
  <GetObservation xmlns="http://www.opengis.net/sos/1.0" 
  xmlns:ows="http://www.opengis.net/ows/1.1" 
  xmlns:gml="http://www.opengis.net/gml" 
  xmlns:ogc="http://www.opengis.net/ogc" 
  xmlns:om="http://www.opengis.net/om/1.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sos/1.0 
  http://schemas.opengis.net/sos/1.0.0/sosGetObservation.xsd" 
  service="SOS" version="1.0.0">
     <offering>ATMOSPHERIC_TEMPERATURE</offering>
     <observedProperty>urn:x-ogc:def:property:OGC::Temperature</observedProperty>
     <featureOfInterest>
        <ogc:BBOX>
           <ogc:PropertyName>urn:ogc:data:location</ogc:PropertyName>
           <gml:Envelope srsName="urn:ogc:def:crs:EPSG:4326">
              <gml:lowerCorner>0.0 0.0</gml:lowerCorner>
              <gml:upperCorner>60.0 60.0</gml:upperCorner>
           </gml:Envelope>
        </ogc:BBOX>
     </featureOfInterest>
     <responseFormat>text/xml;subtype="om/1.0.0"</responseFormat>
  </GetObservation>

example response

DescribeSensor

The DescribeSensor operation returns metadata of the sensors contained in the SOS instance. The response format is usually SensorML.

transactional profile

The transactional profile comprises of optional operations for feeding the SOS with sensor metadata and observations:

RegisterSensor

This operation allows to register new sensors at a SOS instance. Therefore a SensorML document is submitted to the SOS containing the metadata of the sensor to be registered. The SOS returns an identifier for the newly registered sensor which can later be used for inserting observations of this sensor.

example request

example response:

  <?xml version="1.0" encoding="UTF-8"?>
  <sos:RegisterSensorResponse 
  xmlns:sos="http://www.opengis.net/sos/1.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://www.opengis.net/sos/1.0 
  http://schemas.opengis.net/sos/1.0.0/sosAll.xsd">
     <sos:AssignedSensorId>
     urn:ogc:object:feature:OSIRIS-HWS:a1ef1094-c201-4f9f-8f2e-0ff97bf65f03
     </sos:AssignedSensorId>
  </sos:RegisterSensorResponse>

InsertObservation

The InsertObservation operation enables the insertion of new observations. The identifier obtained by an earlier registerSensor request as well as an O&M document containing the observations are submitted to the SOS. The SOS returns an identifier that can be used for referring to the observation; for example in an GetObservationById request.

example request:

  <?xml version="1.0" encoding="UTF-8"?>
  <InsertObservation 
   xmlns="http://www.opengis.net/sos/1.0"
   xmlns:ows="http://www.opengis.net/ows/1.1"
   xmlns:ogc="http://www.opengis.net/ogc"
   xmlns:om="http://www.opengis.net/om/1.0"
   xmlns:sos="http://www.opengis.net/sos/1.0"
   xmlns:sa="http://www.opengis.net/sampling/1.0" 
   xmlns:gml="http://www.opengis.net/gml" 
   xmlns:swe="http://www.opengis.net/swe/1.0.1" 
   xmlns:xlink="http://www.w3.org/1999/xlink" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="http://www.opengis.net/sos/1.0 
   http://schemas.opengis.net/sos/1.0.0/sosInsert.xsd 
   http://www.opengis.net/om/1.0 
   http://schemas.opengis.net/om/1.0.0/extensions/observationSpecialization_override.xsd 
   http://www.opengis.net/sampling/1.0 
   http://schemas.opengis.net/sampling/1.0.0/sampling.xsd" 
   service="SOS" version="1.0.0">
     <AssignedSensorId>
      urn:ogc:object:feature:OSIRIS-HWS:a1ef1094-c201-4f9f-8f2e-0ff97bf65f03
     </AssignedSensorId>
     <om:Measurement>
        <om:samplingTime>
           <gml:TimeInstant>
              <gml:timePosition>2008-10-14T00:09:53+02:00</gml:timePosition>
           </gml:TimeInstant>
        </om:samplingTime>
        <om:procedure 
         xlink:href="urn:ogc:object:feature:OSIRIS-HWS:a1ef1094-c201-4f9f-8f2e-0ff97bf65f03"/>
        <om:observedProperty xlink:href="urn:x-ogc:def:property:OGC::RelativeHumidity"/>
        <om:featureOfInterest>
           <sa:SamplingPoint 
            gml:id="urn:ogc:object:feature:OSIRIS-HWS:a1ef1094-c201-4f9f-8f2e-0ff97bf65f03" 
            xsi:type="ns:SamplingPointType" 
            xmlns:ns="http://www.opengis.net/sampling/1.0" 
            xmlns:gml="http://www.opengis.net/gml">
              <gml:name>roof of the ifgi</gml:name>
              <sa:sampledFeature 
               xlink:href="urn:ogc:object:feature:OSIRIS-HWS:hygrometera1ef1094-c201-4f9f-8f2e-0ff97bf65f03"/>
              <sa:position>
                 <gml:Point srsName="urn:ogc:def:crs:EPSG:4326">
                    <gml:pos>52.07349 9.42125</gml:pos>
                 </gml:Point>
              </sa:position>
           </sa:SamplingPoint>
        </om:featureOfInterest>
        <om:result uom="%" 
        xlink:href="urn:x-ogc:def:uom:OGC:percent" >41</om:result>
     </om:Measurement>
  </InsertObservation>

example response:

  <?xml version="1.0" encoding="UTF-8"?>
  <sos:InsertObservationResponse xmlns:sos="http://www.opengis.net/sos/1.0">
    <sos:AssignedObservationId>o_97845</sos:AssignedObservationId>
  </sos:InsertObservationResponse>

enhanced profile

The enhances profile provides additional operations for accessing geometries and observations

GetResult

The GetResult operation provides an efficient mechanism to repeatedly request sensor data. It is a short-cut for the GetObservation operation avoiding the transmission of huge XML documents.

GetFeatureOfInterest

This operation provides access to a detailed description of the feature of interest associated with an observation.

GetFeatureOfInterestTime

The GetFeatureOfInterestTime operation provides access to the time where observations are available for a certain feature of interest. It returns rime periods for which data is available for specific feature of interest.

DescribeFeatureType

The DescribeFeatureType operation returns the the XML schema for the specified GML feature type that is advertised in the capabilities document.

DescribeObservationType

This operation provides access to the XML schema that describes the observation type that is returned for a particular phenomenon. This is needed for specialized observation types.

DescribeResultModel

The DecribeResultModel operation provides access to the XML schema for the result element that will be returned when the client asks for a certain result model.

GetObservationById

The GetObservationById operation provides access to observations based on an identifier obtained by the client prior to invoking the operation.

entire profile

A SOS which supports all operations implements the entire profile.

Concept of Operation

Consumer Perspective

A sensor data consumer is interested in retrieving observation data from one or more SOS instances. In general two different approaches can be distinguished:

  • sensor-centric view, where the consumer is already aware of the existence of certain sensors and is interested in observations from those sensors.
  • observation-centric view, where the consumer is interested in observations from a particular geographic area and certain phenomenon, but he is not aware of any sensors a-priori.

In both cases the general way of retrieving observations from a SOS instance would look like follows:

As a first step the consumer will search within a catalog in order to discover available SOS instances. The catalog returns the URL of the SOS instance, thus the consumer can bind to the SOS instance. The consumer then performs service-level discovery on the SOS instance by means of the GetCapabilities operation. The SOS instance returns a service description (capabilities document) with information about the supported operations and served data sets (observation offerings). In the next step the consumer invokes the DescribeSensor operation in order to retrieve detailed sensor metadata in SensorML for sensors advertised in the capabilities document. The consumer requests the feature of interest by means of the GetFeatureOfInterest operation and calls the GetFeatureOfInterestTime operation to get information about the time periods for which observations are available. Finally, the consumer calls the GetObservation operation to retrieve observations from the SOS instance.

Sequence diagram showing the consumer perspective of a SOS

Data Producer Perspective

In general data producers will be software entities running on platforms to which the sensors are attached. The producers have just enough processing power to generate XML documents that can be posted to a SOS instance implementing the transactional SOS. The operator of the sensor will establish the link between the data producer and the SOS-T. As a first step the data producer will invoke the RegisterSensor operation. This is used to inform the SOS-T about the new sensor and the type of observation the sensor will provide. The SOS-T instance returns a sensorID which will be used for the subsequent calls to the InsertObservation operation. The data producers uses the InsertObservation operation in order to feed the SOS-T instance with new observations from the registered sensor.

Sequence diagram showing the data producer perspective for a SOS
previous 5 Sensor Web Enablement next
Personal tools