I came across a very interesting white paper (to be published by the OGC in the current EarthCube development) by Ben Domenico today that does not use the term reproducible research, but pretty much talks about it in the realm of using the web for interactive scientific publications. It has some good arguments and many links to other resources – one of them the SOS, but also ERDDAP or Dryad, to name just two.

I think there are some great opportunities here to use sos4R in a web environment that I’d really like to explore, i.e. integration with RServe and/or WPS. More on that in the future!

Abstract: Imagine a scientific environment in which authors create online publications that allow readers to access, analyze, and display the data and processes discussed in the publication.Â Rudimentary examples of such documents can already be cobbled together using existing technological tools in conjunction with the appropriate interface standards. Working together, the science, technology and publishing communities can build on these foundations to develop sophisticated cyber- and organizational infrastructure that will revolutionize how scientists and science educators interact with one another and with the general public.Â Â The idea is simple: the reader of a publication will have access not only to the datasets under discussion but also to the processes used by the author to carry out the analysis and display of those datasets. The reader will be able to repeat the experiment as it is published, or perform related experiments by using different datasets or different processes.

This post is not about sos4R, but about an exciting project of some colleagues of mine here at ifgi. And in the (remote?) future, I think sos4R and this particular project can work together very interestingly!

I’m talking about the ifgicopter, a Mikrocopter platform equipped with a variety of sensors like a camera (for automated aerial photography) and in-situ sensors – the latter being a very interesting data source. The goal is to load a GPS track into the device which then automatically follows this path and takes photos or collects other data, of which some will be instantaneously published via the usual suspects of SWE services, SES and SOS. Of course they have a lot more ideas for the future…

In my opinion this would be a great use-case to test out the usability and show the power of an R package to query a sensor observation service, as the regular updates require repeated querying for new data. I expect that highly reusable R code can be very effective to create the same graphics again and again with constantly updated data.

What is KVP – encoding? An OGC forum entry gives an answer, and Wikipedia gives somebackground. But what is it for the Sensor Observation Service? Well, first of all it is a promised, but undocumented feature! Why is it a promise? Because it is mentioned in section 8.1 of the SOS specification:

Clauses 8, 9, and 10 define the XML encodings for SOS operations. Clause 11 defines the KVP form of each of the operations.

But if you look in the contents section, there simply is not clause 11!

Luckily some people noticed. Eventually, the folks from the OOSTethys project created a best practice documentation of a key value pair encoding for the core SOS operations, which is also implemented by the 52Â° North SOS: http://www.oostethys.org/best-practices/best-practices-get. The website explains well the background (HTTP, GET et cetera) and the specifications they rely on.

Does it work? To simply receive a capabilities document from a sensor observation service that supports GET and key-value pairs (like the 52Â° North SOS), just do the following in R:

After the last post about data processing, I will not work much further on inserting data into the ClimateSOS – even so, there are plenty of features of interest and observations, really enough data for testing.

However, I’d like to save and share the current state with some example documents:

The current Capabilities are quite large already, due to the relatively many features. The division into offerings seemed to have worked well:Read the rest of this entry »

Herein we describe a framework and encoding for measurements and observations. This is required specifically for the Sensor Observation Service and related components of an OGC Sensor Web Enablement capability, and also for general support for OGC compliant systems dealing in technical measurements in science and engineering.

The aim is to define a number of terms used for measurements, and the relationships between them. […] The scope covers observations and measurements whose results may be quantities, categories, temporal and geometry values, coverages, and composites and arrays of any of these.

But how does this relate to sos4R?

Well, as mentioned above, the SOS requires some kind of schema to communicate the markup/encoding of the observations and measurements it stores. So I have to deal with O&M (the common shorthand for the specification) two times: First, when I feed my SOS instance through the transactional profile. An example of a measurement is as follows: Read the rest of this entry »

It’s time now to introduce the second basic element (the first being R) of the sos4R project: the OGC Sensor Observation Service. Instead of going deeply into the specification, I just like to cite some paragraphs from the specification document and elaborate myself more about what I use and the utilized implementation.

What is the SOS?

A Sensor Observation Service provides an API for managing deployed sensors and retrieving sensor data and specifically â€œobservationâ€ data. Whether from in-situ sensors (e.g., water monitoring) or dynamic sensors (e.g., satellite imaging), measurements made from sensor systems contribute most of the geospatial data by volume used in geospatial systems today.