Extending sos4R and advanced configuration

mySOS <- SOS(url = "http://sensorweb.demo.52north.org/52n-sos-webapp/service/pox",
             binding = "POX", dcpFilter = list("POX" = "/pox"))

Changing Handling Functions

The flexibility of the specifications that model the markup requests and responses, especially the observation encoding, is too high to handle all possible cases within sos4R. Thus an equally flexible mechanism for users to adopt the steps of encoding and decoding documents to their needs is needed.

The process of data download comprises

  1. building the request,
  2. encoding the request,
  3. sending encoded request and receiving response,
  4. decoding the responses, and
  5. applying the correct R data type to the respective data values.

This can be seen as a fixed, ordered workflow a user has to follow where each step build upon the input of the previous. To ensure flexibility within these steps of the workflow but also to maximize reusability of existing functionality, a mechanism to exchange the functions that are used in these steps is provided.

Step 1, the building of requests, is the assembly of the request parameters passed to the sos4R functions into an R object. It is documented in section GetObservation. Step 3, the sending receiving of documents to respectively from a service, does not need to be changed directly but the user, who only can configure the binding.

The remainder of this document explains how to configure steps 2 (encoding), 4 (decoding) and 5 (data parsing) of the process.

Include and Exclude Own Functions

The functions used in the exchangeable steps are organized in lists. To base your own list of functions on the existing ones, thereby not having to start from scratch, you can combine the default list of functions with your own. Use the following functions:

To add your own function, simply add it as a named argument. You can add as many as you like in the ... parameter. If a function with that identifier already exists in the default list it will be replaced by your function. For further adjustments you can explicitly include and exclude functions by identifier. Please be aware that inclusion is applied first, then exclusion. It is also important that you also have to include that functions you just added manually!

Examples of function list generation with parsing functions:

parsers <- SosParsingFunctions(
    "ExceptionReport" = function() {
        return("Got Exception!")
    include = c("GetObservation", "ExceptionReport"))
parsers <- SosParsingFunctions(
        "ExceptionReport" = function() {
            return("Got Exception!")
        include = c("GetCapabilities"))

The following snipped shows how to remove a large part of parsers using exclude and then prints the names of the remaining ones.

parsers <- SosParsingFunctions(
        exclude = names(SosParsingFunctions())[5:29])


The current list of a connection's encoders can be accessed with


A complete list of the existing encoders names:


Here the idea of organizing the encoding functions becomes clear: One base encoding function is given, which is a generic method that must exist for all elements that need to be encoded.

myPostEncoding <- function(object, sos, verbose) {
# Connection will not be established because of mising objects
mySOS2 = SOS(sosUrl(mySOS),
    encoders = SosEncodingFunctions("POST" = myPostEncoding))

Encoding functions can be overridden for many specific objects. The signature of the encoding function consists of the object, obj, a SOS object, sos, and the optional verbose parameter.


A useful example can be overriding the encoding method for time classes (POSIXt) as presented below -- see the demo southesk for the application of this code.

setMethod(f = "encodeXML",
  signature = signature(obj = "POSIXt", sos = "SOS"),
    def = function(obj, sos, verbose) {
      if(verbose) cat("Using my own time encoding... ")

      # time zone hack to fix that the time format option
      # %z does not work on windows machines:
      .time <- obj + 11 * 60 * 60 # add 11 hours
      formatted <- strftime(x = .time,
        format = sosTimeFormat(sos))
      formatted <- paste(formatted,
        "+11:00", sep = "") # append 11:00

      if(verbose) cat("Formatted ", toString(obj),
        " to ", formatted, "\n")

All later calls for encoding any classes with time will then reference this newly defined method. Be aware that this changes the encoding globally, in contrast to converters and parsers which can be changed for every instance of class SOS.


The terms parsing and decoding are used as synonyms for the process of processing an XML document to create an R object. XML documents are made out of hierarchical elements. That is why the decoding functions are organized in a listed, whose names are the XML elements' names it parses.

The current list of a connection's parsers can be accessed with the following function.


A complete list of the elements with existing encoders is shown below. These are not only names of XML elements, but also MIME types. Here the idea of organizing the encoding functions becomes clear: For every XML element or document type that must be parsed there is a function given in the list.


Parser selection can also be based on the mimeType of the returned document. Please be aware that this also can be a problem if you want to exchange a parse by operation name, which is done after switching the function based on the mime type. In other words, the exchange by operation name only works if the response type is as expected.

If you want to replace only selected parsers use the include parameter as described above. You can also base your own parsing functions on a variety of existing parsing functions. For example you can replace the base function for om:ObservationCollection, element name ObservationCollection, but still use the parsing function for om:Observation within your own function if you include it in the parser list. The existing parsing functions are all named in the pattern parse<ElementName>(). Please be aware that some parsers require a parameter sos of class SOS upon which they might rely for example for formatting information, and some also have verbose (type logical). In case of "unused arguments" errors, please try different signatures.

# Create own parsing function:
myER <- function(xml, sos, verbose) {
myParsers <- SosParsingFunctions("ows:ExceptionReport" = myER)
exceptionParserSOS <- SOS(url = "http://sensorweb.demo.52north.org/52n-sos-webapp/service/pox",
                          parsers = myParsers,
                          binding = "POX", useDCPs = FALSE)
# Triggers exception:
erroneousResponse <- getObservation(exceptionParserSOS,
                                    #verbose = TRUE,
                                    offering = sosOfferings(exceptionParserSOS)[[1]],
                                    observedProperty = list("Bazinga!"))

To disable all parsing, you can use the function SosDisabledParsers(). This effectively just "passes through"" all received data because the list returned by the function only contains the top-most parsing functions for SOS operations and exception reports.


This is also the recommended way to start if you want to set-up your own parsers (given you have responses in XML) and an alternative to debugging if you want to inspect responses directly.

The next example shows how the response (in this case the request is intentionally incorrect and triggers an exception) is passed through as an object of class xml_document:

disabledParserSOS <- SOS(sosUrl(mySOS),
                         parsers = SosDisabledParsers(),
                         binding = sosBinding(mySOS),
                         dcpFilter = mySOS@dcpFilter)
unparsed <- getObservation(disabledParserSOS,
                           offering = sosOfferings(disabledParserSOS)[[1]],
                           observedProperty = list("Bazinga!"))
# (Using XML functions here for accesing the root of a
# document and the name of an element.)

Data Converters

A list of named functions to be used by the parsing methods to convert data values to the correct R type, which are mostly based on the unit of measurement code.

The conversion functions always take two parameters: x is the object to be converted, sos is the service where the request was received from.

The available functions are basically wrappers for coercion functions, for example as.double(). The only method exploiting the second argument is the one for conversion of time stamps which uses the time format saved with the object of class SOS in a call to strptime.

value <- 2.0
value.string <- sosConvertString(x = value, sos = mySOS)

value <- "2.0"
value.double <- sosConvertDouble(x = value, sos = mySOS)

value <- "1"
value.logical <- sosConvertLogical(x = value, sos = mySOS)

value <- "2010-01-01T12:00:00.000"
value.time <- sosConvertTime(x = value, sos = mySOS)

The full list of currently supported units can be seen below. It mostly contains common numerical units which are converted to type double.


The current list of a SOS connection's converters can be accessed with


The following connection shows a typical workflow of connecting to a new SOS for the first time, what the errors for missing converters look like, and how to add them to the SOS connection.

testsos <- SOS("http://sensorweb.demo.52north.org/52n-sos-webapp/sos/pox", binding = "POX", dcpFilter = list("POX" = "/pox"))
testsosoffering <- sosOfferings(testsos)[["http___www.52north.org_test_offering_1"]]
testsosobsprop <- sosObservedProperties(testsosoffering)[1]
getObservation(sos = testsos, offering = testsosoffering, observedProperty = testsosobsprop)

Looking at the raw response data gives us a hint at a suitable type.

getObservation(sos = testsos, offering = testsosoffering, observedProperty = testsosobsprop,
               inspect = TRUE)

Converters may be matched by XML properties swe:Quantity[@definition] or swe:uom[@code].

testconverters <- SosDataFieldConvertingFunctions(
  # one of the following would suffice
  "test_unit_1" = sosConvertDouble,
    "http://www.52north.org/test/observableProperty/1" = sosConvertDouble

testsos <- SOS("http://sensorweb.demo.52north.org/52n-sos-webapp/sos/pox", binding = "POX", dcpFilter = list("POX" = "/pox"),
               dataFieldConverters = testconverters)
testsosoffering <- sosOfferings(testsos)[["http___www.52north.org_test_offering_1"]]
data <- getObservation(sos = testsos, offering = testsosoffering, observedProperty = testsosobsprop)

Then retrieve the data with the correct type.


The metadata of the observed property is also accessible.


Warnings may also include messages if no converter is available for a unit of measurement, for example:

In .valParser(values = obj[[sweValuesName]], fields = .fields,  ... :
                No converter for the unit of measurement  S/m  with the definition  http://mmisw.org/ont/cf/parameter/conductivity ! Trying a default, but you can add one when creating a SOS using SosDataFieldConvertingFunctions().
In .valParser(values = obj[[sweValuesName]], fields = .fields,  ... :
                No converter found! Skipping field Conductivity
No converter found! Skipping field http://mmisw.org/ont/cf/parameter/conductivity
No converter found! Skipping field S/m

This shows warnings about unknown units of measurement and a swe:Quantity element (which describes a numeric field) without a given unit of measurement (which it should have as a numeric field). The next example creates conversion functions for these fields and repeats the operation.

myConverters <- SosDataFieldConvertingFunctions(
    "S/m" = sosConvertDouble,
            = sosConvertDouble)

Exception Handling

When working with sos4R, two kinds of errors must be handled: service exceptions and errors within the package. The former can occur when a request is invalid or a service encounters internal exceptions. The latter can mean a bug or illegal settings within the package.

To understand both types of erroneous states, this sections explains the contents of the exception reports returned by the service and the functionalities to investigate the inner workings of the package.

OWS Service Exceptions

The service exceptions returned by a SOS are described in OGC Web Services Common (Whiteside, 2007) clause 8. The classes to handle the returned exceptions in sos4R are OwsExceptionReport, which contains a list of exception reports, and OwsException, which contains slots for the parameters exception text(s), exception code, and locator. These are defined as follows and can be implementation specific.

The standard exception codes and meanings are accessible by calling the following function.

response <- try(getObservationById(sos = mySOS,
                                   observationId = ""))

The exception is also stored in the response object.


Try the sos4R package in your browser

Any scripts or data that you put into this service are public.

sos4R documentation built on July 9, 2020, 5:07 p.m.