Archives for posts with tag: O&M

I revisited my proposal again today and went through all my plans today to create a revised, reasonable, achievable list of remaining tasks. This article is a sum-up of the decisions I made, but I still have to discuss those with my advisers.

Use Cases: I haven’t done anything for the use cases yet, but I am of the opinion that testing my software with actual use cases is crucial because that is what I want people to do with sos4R: do their actual analyses with data requested from a SOS. I went through the documentation and publications of those packages and decided to do the analyses listed below:

I will not use the spatstat package any more, as I realized I don’t have an appropriate dataset (i.e. spatial point patterns).

Functionality: I explicitly listed some functions, some of which are implemented already, but most of them are not. I’ll go through them in detail: Read the rest of this entry »

The main component of sos4R will be the encoders and decoders for the request and responses that are sent to respectively received from the SOS. The SOS uses Observations & Measurements as the format to communicate the stored observations. But since O&M is a very broad specification, it is necessary to define a certain subset which is supported by sos4R. On top of that, the software structure will make the decoders for these elements easily interchangeable.

We (me and my supervisors) had some discussions around this “subset”. Although we decided that the process of specifying something like that is not in the scope of sos4R (hence the focus lies in the exchangeability of the XML parsers), I do not want to loose the time I spent thinking about this. So I created a document describing such a subset as an O&M Profile for Simple Spatio-Temporal Observations. Read the rest of this entry »

The Observations&Measurements model is part of the OGC’s Sensor Web Enablement activity. Excerpt from the specification document:

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 »