Archives for category: Implementation

Yesterday I successfully requested a time series from the WeatherSOS service! The code below shows how that works: First requesting the data (including using some help-functions to create time interval and access the features of the SOS), second plotting it using R’s plot function.

weathersos = SOS("")
go.offering = sosOfferings(weathersos)[[4]] # ATHMOSPHERIC_TEMPERATURE
go.observedProperty = sosObservedProperties(weathersos)[[4]] # temperature urn
go.eventTime3 = sosCreateEventTime(sosCreateTimePeriod(sos = weathersos, begin = as.POSIXct("2010-09-16 18:00"), end = as.POSIXct("2010-09-20 18:00")))

obs3 <- getObservation(sos = weathersos,observedProperty = list(go.observedProperty),
procedure = list(sosProcedures(weathersos)[[1]]), eventTime = go.eventTime3, offering = go.offering@id)

# heureka!

summary(obs3@result) # finally!
plot(x = obs3@result[["Time"]], y = obs3@result[["urn:ogc:def:property:OGC::Temperature"]],
type = "l", main = "Temperature in Münster", xlab = "Time", ylab = "Temperature (°C)")

This is quite a milestone for the project, and a good start in this week. For today, spatial queries and testing (also other SOS instances) are on the agenda.

Oh, those wonderful four words every Java programmer knows so well :-). Defining a constant, never to be changed and accessible from everywhere. A powerful tool, if used right and with care! But how can I do such a thing in R? Is there a common pratice to do this?

Well, if you don’t know, you must ask and you shall be answered: Duncan Murdoch replied:

If they are constants, you won’t need to use <<- or assign() to change them:  just define them at top level in one of the source files for your package.

Simpler than I thought, and more elegant.

I use this method for setting package wide names for the operations, connections method names, character encoding, as well as namespace attributes so far. All of these are used to switch between different cases at some point in the code, so their correctness is important which makes the single point of change very useful.

See the class Constants.R, excerpt below:

sosService <- "SOS"
sosNamespacePrefix <- "sos"
sosGetCapabilitiesName <- "GetCapabilities"
sosDescribeSensorName <- "DescribeSensor"

# [...]

.sosConnectionMethodGet <- "GET"
.sosConnectionMethodPost <- "POST"

These constants are then used for example in the main request function and encoding functions:

if(sos@method == .sosConnectionMethodGet) {
.kvpEncoding = .encode(request, verbose)

# [...]


# [...]

sosEncodeRequestXMLGetObservation_1.0.0 <- function(obj) {
.xmlDoc <- xmlNode(name = sosGetObservationName,
namespace = sosNamespacePrefix,
namespaceDefinitions = c(.sosNamespaceDefinitionsAll,
attrs=c(.xsiSchemaLocationAttribute, service = obj@service,
version = obj@version))

# required and optional are mixed as schema requires a particular order:
.offering <- xmlNode(name = "offering", namespace = sosNamespacePrefix,
.xmlDoc <- addChildren(node = .xmlDoc, .offering)
#  [...]

The “namespace” attribute should not be highlighted in the code, I’m sorry about that (because of a lack of alternatives I’m using C++ syntax highlighting).

Date and time parsing is never fun. Two sides claim to use ISO 8601, but they just don’t work together out of the box. In my case, I get times from the SOS like this:


A ‘T’ shows when the time starts after the date, the seconds are including milliseconds, and the time zone is shown at the end, it’s plus 2 hours from UTC time. Can I convert this to an R time object like POSIXct easily? No. For example, as.POSIXct expects a space between date and time – so much for ISO 8601 compatibility… but never mind, the function strptime allows to convert a string to a time object based on a given format. One could also use other packages like chron as dicussed here. But I figured out something else, see the code and comments below:

Read the rest of this entry »

Let me show you how I implemented the exchangeability of parsing and encoding functions for advances users: So the question to me really was: How can I (as a user) write my own functions and replace the existing one for encoding and decoding?

Lucky for me, this is very easy in R as one can just insert function names as arguments and use the arguments to call the respective function. No implementing interfaces and loading classes at runtime, dear Java folk!

So I created simple lists with the names of (my default) parsing and encoding functions together with accessor functions in the class Defaults.R. In the excerpt below you can see the list and function for SOS parsers. Read the rest of this entry »

From the beginning of sos4R I had to struggle with difficulties in two areas (amongst others): generality and flexibility/versions.

Generality and Specifications. I implement a client for a web service. But the SOS specification does not come as a single document, because it references other specifications, most importantly for me up to now: OWS Common, a specification for common operations among OGC web services; the often mentioned Observations & Measurements. And then there are GML, SensorML and SWE Common.

So how do I represent this division in the code? And do I represent it at all? Read the rest of this entry »

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 »