Section 2: Sensor Observation Service Tutorial Introduction

2.1 Discussion of Tutorial Use

This tutorial aims at introducing the OGC Sensor Observation Service (SOS) as a means for providing sensor data in an interoperable manner. This tutorial puts the primary focus on the data provider perspective. Consequently the use cases presented later on deal with the publication of sensors, observation data and legacy sensor data archives. This section continues with a brief introduction of the general concepts and ideas behind the SOS. After this, the two use cases this tutorial deals with are introduced. These are:

• Publishing sensors and sensor data: How to submit measured data and information about a specific sensor (sensor metadata) to a SOS?
• Publishing legacy sensor data sets using an import tool: How can the publication of already available sensor data (i.e. contained in comma-separated values (CSV) files) be facilitated through SOS import tools?

<<Prev T.O.C Next>>

2.2 The Sensor Observation Service

The OGC Sensor Observation Service (SOS) is a core element of the OGC Sensor Web Enablement (SWE) framework. It enables the access to observations from sensors and sensor systems based on standardised data formats and interfaces. The SOS makes use of the following two data models:

• Observations & Measurements (O&M): Modelling sensor observations and encoding them in XML
• Sensor Model Language (SensorML): Modelling sensors and sensor systems for providing relevant metadata

In order to provide access to sensor observation data and related information, the SOS offers several operations.

The most important ones are:

• GetCapabilities, for requesting a self-description of a SOS instance
• GetObservation, for requesting sensor observations encoded in O&M
• DescribeSensor, for requesting information about the sensor itself encoded using SensorML
• RegisterSensor, for connecting new sensors with the SOS
• InsertObservation, for inserting new observations for previously registered sensors
• GetFeatureOfInterest, for requesting the GML encoded representation of the feature that is the target of an observation

From a data provider perspective, especially the RegisterSensor and InsertObservation operations are important. They allow the interoperable publishing of sensor data on the Web. Consequently a strong focus of this tutorial will be put on these two operations.

2.3 How Interoperability is Improved Through the Use of the Sensor Observation Service

Sensors and sensor networks deployed in practice are very heterogeneous, the may include

• In-situ measurement stations (e.g. weather station)
• Remote sensing devices (e.g. satellites)
• Human observers (e.g. citizens reporting dirt on the street through a smart phone application)
• Mobile sensors (e.g. sensors mounted on cars)
• Stationary sensors (e.g. air quality measurement stations)
• Models calculating/estimating values for a specific location (e.g. weather forecasts)
• ...

This non-exclusive list illustrates the broad range of sensors types, semantic sensor abstractions, and procedures that are used in practice. In addition, there is a large number of sensor manufacturers which offer each a range of different sensor types. As a result, there are many mechanisms, interfaces, data formats and protocols for accessing the data observed by these sensors. This makes it a cumbersome task to integrate the measurements of such sensors into application systems: each time a new sensor shall be integrated into an application it must be made sure that the application supports the protocol of the sensors. Often this leads to significant implementation work which needs to be done. For each sensor type and each application that shall use this sensor type, implementation work might be necessary.
To overcome this issue, the OGC Sensor Web Enablement (SWE) framework was developed which enables the integration of sensors and sensor data into spatial data infrastructures by providing an abstraction layer. This means that the SWE framework abstracts from the specific protocols of each single sensor type. Instead the SWE specifications provide common interfaces and data models for any type of sensors, independently of the specific sensors.
Currently several initiatives dealing with the specification of domain specifc SWE profiles are ongoing (e.g. WaterML 2.0 as an O&M profile for the hydrology domain). Such profiles are intended to increase the interoperability within certain thematic domains. As there are often diffent types of concepts that need to be supported such profiles help to increase the interoperability. However, the basic concepts introduced in this tutorial can easily be transferred to a broad range of application domains.

2.4 References to Associated Videos, Books, and Other Resources

The following resources can be used for gaining further insight into the OGC SOS interface:

• Geonovum Sensor Web Tutorial: http://geostandards.geonovum.nl/index.php/5_Sensor_Web_Enablement
• Bröring, A.; Echterhoff, J.; Jirka, S.; Simonis, I.; Everding, T.; Stasch, C.; Liang, S.; Lemmens, R. New Generation Sensor Web Enablement. Sensors 2011, 11, 2652-2699: http://www.mdpi.com/1424-8220/11/3/2652/
• EO2HEAVEN (the project that supported the creation of this tutorial): http://www.eo2heaven.org/
• ... if you have further useful material, please add it here

The following SOS implementations support the transactional operations of the OGC SOS standard and can thus be used for the use cases described in this tutorial:

• 52°North Sensor Observation Service: http://52north.org/sos
• ... if you are aware of further implementations working together with this tutorial, please insert them here

<<Prev T.O.C Next>>