Support WaterML 2.0

[rsignell-usgs]

Excerpted from the Ulmo package issue by @jirikadlec2
https://github.com/twdb/ulmo/issues/77,
but would be great if supported by OWSLib:

"It would be nice to support WaterML 2.0 in ulmo. WaterML 2 is a xml format for hydrologic data and it is an official standard of the OGC:
http://www.opengeospatial.org/standards/waterml

I think it's OK if only the getValues() method with an url parameter is supported.

An example WaterML 2.0 request is here:
http://data.fmi.fi/fmi-apikey/1cb8a6f3-d8f4-4ae7-8fc3-0b9449683cfb/wfs?request=getFeature&storedquery_id=fmi::observations::weather::timevaluepair&fmisid=101152&starttime=2013-08-01T00:00:00Z&endtime=2013-08-05T00:00:00Z&timestep=60&parameters=temperature

(this is a time-series of air temperature at a station in Finland)

[domlowe]

Hi,

Note that the example request given returns data according to the INSPIRE atmospheric features schema. Only part of this response is WaterML (the om:result uses the WaterML Timeseries type).

Cheers,
Dom

From: Rich Signell [mailto:notifications@github.com]
Sent: Tuesday, 18 March 2014 12:24 PM
To: geopython/OWSLib
Subject: [OWSLib] Support WaterML 2.0 (#131)

Excerpted from the Ulmo package issue by @jirikadlec2https://github.com/jirikadlec2
twdb/ulmo#77https://github.com/twdb/ulmo/issues/77,
but would be great if supported by OWSLib:

"It would be nice to support WaterML 2.0 in ulmo. WaterML 2 is a xml format for hydrologic data and it is an official standard of the OGC:
http://www.opengeospatial.org/standards/waterml

I think it's OK if only the getValues() method with an url parameter is supported.

An example WaterML 2.0 request is here:
http://data.fmi.fi/fmi-apikey/1cb8a6f3-d8f4-4ae7-8fc3-0b9449683cfb/wfs?request=getFeature&storedquery_id=fmi::observations::weather::timevaluepair&fmisid=101152&starttime=2013-08-01T00:00:00Z&endtime=2013-08-05T00:00:00Z&timestep=60&parameters=temperature

(this is a time-series of air temperature at a station in Finland)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/131.

[tomkralidis]

FYI @allixender may have comments here / might be working on something.

[allixender]

Hi all,

well, yes I was looking into that. but I got side tracked. I might not
really deliver anything useful anytime soon. sorry, also the GSoC topic
fell out of scope :-( Too busy with studies stuff.

Alex

Am 19/03/2014 1:27 p.m., schrieb Tom Kralidis:

FYI @allixender https://github.com/allixender may have comments here /
might be working on something.

—
Reply to this email directly or view it on GitHub
#131 (comment).

[peterataylor]

Hi guys,

I’d been thinking about WaterML2.0 support for a while, and I had a chat with Dom about it (we are now colleagues since his move down under). He gave me a few pointers on OWSLib background, so this prompted me to take a start. Here is some of the stuff I’ve got working (https://github.com/peterataylor/OWSLib):

• Main classes for decoding get_observation responses from SOS: https://github.com/peterataylor/OWSLib/blob/master/owslib/swe/observation/observation.py. This has classes for parsing OM_Observation and WaterML2.0 responses from SOS.
• Working doctests for decoding both OM_Observation (measurement) and WaterML2 time series: https://github.com/peterataylor/OWSLib/blob/master/tests/doctests/sos_20_timeseries_decoder_ioos.txt. This one uses an IOOS SOS instance.
• Added doctests calling SOS2.0 instances at 52North, includes waterml2 requests. But these don't parse the get_observation responses yet (it was my starting point for getting the calls setup):
  • https://github.com/peterataylor/OWSLib/blob/master/tests/doctests/sos_20_52n_geoviqua.txt
  • https://github.com/peterataylor/OWSLib/blob/master/tests/doctests/sos_20_52N_demo.txt (this one times out a bit)

There was a small fix required to get the get_observation call to work in the existing sos200.py file (peterataylor@909a1c2). Not sure if this was a service implementation quirk; needs testing on other SOS 2.0 implementations.

Further things to look at:

• Supporting domain-range encoding of WaterML2.0 (example call in the IOOS doctest)
• More separation of SOS and WaterML2 parsing
• Add support for GetFeatureOfInterest SOS call (typically passes back an SF_SpatialSamplingFeature, or a WaterML2 MonitoringPoint).
• Other WML2 types (monitoring point, observation process, collections etc.) - these are not encoded by the SOS at the moment.

Let me know if any comments.

Cheers,
Pete.

[tomkralidis]

@peterataylor thanks, impressive work here! I wonder whether we should move the waterml2 things in https://github.com/peterataylor/OWSLib/blob/master/owslib/swe/observation/observation.py to https://github.com/geopython/OWSLib/tree/master/owslib/waterml ? Having said this, would like to hear others' comments.

[peterataylor]

Thanks Tom.

Yes agree with your comment, and I had considered the waterml package. One thing we need to look at is the various parts of these packages (I was alluding to this in the second point above).

The current waterml package is actually a combination of WaterML1.0/1.1 and the WaterOneFlow web service. The observation package I've added has these parts:

• Support for Observations & Measurements types (only currently the measurement OM_Observation);
• Support for the WaterML2.0 result types (Timeseries)
• Support for handling the SOS2.0 GetObservation responses.

These could be split accordingly. Where you might have:

Response handler moves into SOS200.py, which would use types from both O&M.py (or something similar) and waterml2.py. That way we can add further types for WaterML2.0, O&M, as well as handling other responses from SOS2.0, e.g. GetFeatureOfInterest.

This would then allow the WaterML2.0 and O&M packages to be used with other services, in the same way there is a SWE common package (common.py). E.g. if you need to parse a WFS that returns O&M and/or WaterML2.0.

I'll have a look, but also happy to take on any suggestions..

[peterataylor]

Hi Tom,

I've refactored the packages to better suit their scope and improves the modularity a little. Here's a short summary:

• om.py - handles O&M types. New classes:
  • OM_Observation - handles base level O&M observation properties, with a result property that will vary depending on the type of observation
  • OM_MeasurementObservation - specialised OM_Observation that has a Measurement result (value + uom)
• waterml2.py - handles WaterML2.0 types. New classes:
  • Timeseries, MeasurementTimeseries, TimeValuePair, TVPMetadata, TVPMeasurementMetadata, MeasurementTimeseriesDomainRange - types to support timeseries. Not all implemented at this stage, but enough to parse results from SOS2.0 instances, specifically the 52North implementations.
  • MeasurementTimeseriesObservation - specialised OM_Observation that has a time-series as a result.
• sos200.py - added:
  • SOSGetObservationResponse - container for OM_Observation objects that result from a get_observation call to a SOS.
  • ObservationDecoder - decoder class to handle different OM_Observation types. Currently supports OM_MeasurementObservation & MeasurementTimeseriesObservation.

The main test I've added shows basic usage.

[tomkralidis]

cc @kwilcox @peterataylor nice work here on the restructuring, makes sense. Any chance you can link up the tests to the docs (or augment the docs directly)? Please submit a PR when this is good to go.

[mullenkamp]

Hi, has @peterataylor 's work been integrated?

[peterataylor]

Hi @mullenkamp - yes it got merged in a while back by @kwilcox, see c73c06e.

[mullenkamp]

Thanks. I was only asking because this issue is still opened, but (as you said) it looked like it got implemented.

[cehbrecht]

If I understand correctly this issue is closed by PR #241 since version 0.12.0. I close it now.