Prototype WaterML2 Documents using the present generic ODM services.
links to xml output are in table 3 urls
Information in the WaterML 2 will often be followed by reference (click below to get a larger image)
In the present service, the site is a feature of interest (ideally retrieved from WFS), and the observed property is a link to the waterml variable description (any form is ok, an HTML page would be another possible place to point it.) Images of XML
In this prototype, REST endpoint that use parameters names matching the WaterOneFlow names is presented. This is for simplicity of comprehension. The same codebase is used, so only the limited set of WaterOneFlow filters is supported ( outline below in table 2). This provided insight into how we map from the present WaterOneFlow services to the future, and where the issues in the services are found (Table 1).
table 1: SOS Features
| SOS Verb||WOF 1.1 method||Generic Endpoint||Note |
|GetCapabilties (offerings)||~GetSiteInfo for every site|| || Not Implemented. Offering ~ series ||
|DescribeSensor||Variable+Method(+site)|| ||Not Implemented. No direct way to get list methods via wateroneflow. Methods liked to values, although series could be used |
|GetFeature ||GetSite||waterml2.svc/featureOfInterest?location=USU:USU-LBR-Mendon|| Optional, but featureOfInterest referenced from WaterML2 returned by getObservation. Ideally in a WFS||
| (observed property)||Variable||waterml2.svc/observedProperty?variable=USU:USU3|| referenced from WaterML2 returned by getObservation ODM variable. At present ANY format ||
|GetDataAvailability||HIS Central GetSeries(filters) ||SOS Extension. Not Yet Implemented |
|GetResourceByID (other resources)|| HIS Controlled Vocabularies ||not an SOS service. Request defined in Web Services Common|
A issue with the present Sensor Observation Service specification is that the GetCapabilities contains offering. An offering is ~ a series. So when you call GetCapabilities, you would get all series. This works for small sources, but for large sources, it would mean parsing 1000's to millions of series just to use the service. Unlike using a WFS, there is no filtering on GetCapabilities. Workaround are to implement the GetDataAvailability.
table 2: Query Parameters
| Parameter||values||featureofinterest||observedProperty||GetResourceByID (TBD) |
|location||X ||x|| |
|variable||X || || X||X|
|startDate||X || || |
|endDate||X || || |
|resource|| || || ||X|
These examples use the generic web services and little bear river database, so any data found at this wateroneflow endpoint can be represented in WaterML2.
Improve procedure inline procedure to full specification
- Make feature of interest, and observedProperty resolvable (aka xlink:href="http://hydro10.sdsc.edu/LBRSDSC/waterml2/waterml2.svc/featureOfInterest?location=USU-LBR-Paradise")
- implement resource endpoints (controlled vocabulary terms)
- implement translation from CUAHSI CV to WaterML best practices
- 8.6.5 Data type.
- statistical details need to go to the procedure
- 8.6.4 Data quality.
- 22.214.171.124.1 phenomenaDictionary
- 126.96.36.199.2 qualifierDictionary
- 188.8.131.52.3 qualityDictionary
- (procedure endpoint?)
- fix aggregationPeriod
- add metadata elements
- rework county/state to reference ISO