Introduction to OGC SWE and SOS

Daniel Nüst

Institute for Geoinformatics, University of Münster, Germany.



The sos4R package provides simple yet powerful access to OGC Sensor Observation Service instances. The package supports both encapsulation and abstraction from the service interface for novice users as well as powerful request building for specialists. sos4R is motivated by the idea to close the gap between the Sensor Web and tools for (geo-)statistical analyses. It implements the core profile of the SOS specification and supports temporal, spatial, and thematical filtering of observations.

This document introduces core concepts of OGC, SWE, and SOS standards.

The package is published under GPL 2 license within the geostatistics community of 52°North Initiative for Geospatial Open Source Software.

If you are familiar with the OGC SOS standard specification, know how to use content assist in your favourite R editor, and you do not need to extend the functionality of sos4R, then take a look at the “Quickstart” vignette and get started straightaway.

Terms and Definitions

The OGC has a particular set of well-defined terms that might differ from usage of words in specific domains. The most important are as follows and are based on

A more extensive discussion is available in the the O&M specification (Cox, 2007). The Annex B of that document contains the examples of applying some terms to specific domains, aerosol analysis and earth observations.

A very good and extensive introduction into the whole field of SWE, including its history, and an analysis of the current state of the art and future developments is provided in Bröring (2011).

Supported Implementations

sos4R supports the core profile of the SOS specification. But the possible markups for observations is extremely manifold due to the flexibility of the O&M specification. Sadly, there is no common application profile for certain types of observations, like simple measurements.

Therefore, the undocumented profile of the 52°North SOS implementation was used as a guideline. It is not documented outside of the source code. Observations returned by instances of this implementation are most likely to be processed out of the box.

In the author’s experience, OOSThetys SOS implementations utilise the same or at least very similar profile, so responses of these service instances are probably parsed without further work as well.

An incomplete list of **tested services} can be found in package documentation. Please share your experiences with other SOS implementations with the developers and users of sos4R.