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.
The Open Geospatial Consortium (OGC) is an organisation which provides standards for handling geospatial data on the internet, thereby ensuring interoperability.
The Sensor Observation Service (SOS)} is such a standard and provides a well-defined interface for data warehousing of measurements and observations made by all kinds of sensors.
This vignette describes the classes, methods and functions provided by
sos4R to request these observations from a SOS.
Providing data via web services is more powerful than local file copies (with issues like being outdated, redundancy, \ldots).
Flexible filtering of data on the service side reduces download size.
That is why SOS operations can comprise flexible subsetting in temporal, spatial and thematical domain.
"Get measurements from sensor urn:mySensor:001 for the time period from 01/12/2010 to 31/12/2010 where the air temperature below zero degrees".
In general, the SOS supports different methods of requesting data, so called bindings: (i) Key-value-pair (KVP) binding using HTTP GET as defined in the OOSTethys best practice document (this best-practice paper takes the place of a section in the specification that was left out by mistake; it is well established and (loosely) followed by several SOS implementations), (ii) XML, or plain old XML (POX) using HTTP POST as defined in the standard document with requests encoded in eXtensible Markup Language (XML), and (iii) SOAP (Simple Object Access Protocol). All bindings can return responses using different encodings, but most common are XML documents.
Other OGC Standards that are referenced and used, by the SOS standard are as follows.
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 https://en.wikipedia.org/wiki/Sensor_Observation_Service.
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).
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
Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.