pyoos, and clean-ups / fixes to the IOOS SOS Milestone 1 GetObservation XML templates

4 views
Skip to first unread message

Emilio Mayorga

unread,
Jan 21, 2014, 9:31:30 PM1/21/14
to ioostech_dev, Dan Ramage
I've been using pyoos to start examining the IOOS SOS Milestone 1 XML template files we built last year, specially the GetObservation responses. To do this, I manually merged the OM & SWE templates, OM-GetObservation.xml and SWE-MultiStation-TimeSeries.xml, to run a first battery of tests. You can find the merged and slightly tweaked version here:
https://raw2.github.com/ioos/ioossos2kml/master/SWETesting/OM-GetObservation-SWE-MultiStation-TimeSeries.xml

I've found issues with the templates, specially inconsistencies in the information present in OM-GetObservation.xml vs SWE-MultiStation-TimeSeries.xml. In particular, the number of procedures and stations (gml:location Point children) was different, even the latitude and longitude coordinates for the two common stations were different. The om:result block has 3 stations, but the om:member/om:Observation "metadata" block (outside om:result) only lists two stations in om:procedures and gml:location; urn:ioos:station:wmo:41003 is missing.

** I've created a new version that corrected these errors and made a few other small tweaks:
https://raw2.github.com/ioos/ioossos2kml/master/SWETesting/OM-GetObservation-SWE-MultiStation-TimeSeries-Corrected.xml

More generally, with the OM-GetObservation and SWE templates having been developed separately for the last several months of template development, I imagine other inconsistencies will be found. In addition, having merged files that represent complete GetObservation responses is really handy for client software testing and assessments.

** Should we create one complete, merged template file for each SWE template, ensuring that it's internally consistent?

One additional small issue is that for multi-station responses, there's no human-friendly description present for each station ("feature" or "location"). Only the station urn's are present, in addition to the gml:description corresponding to each entire om:member/om:Observation block (ie, all station data of the same FeatureType). I haven't yet tested if a gml:description can be legally added where it's useful.

Later, I can create specific issues on the ioostech Google Code site, but wanted to raise this as a broader discussion first.

** If anyone is curious about pyoos parsing of the corrected MultiStation-TimeSeries template, here's my IPython notebook on Wakari:
https://www.wakari.io/sharing/bundle/emayorga/pyoos1_test_3
I'll create one or more cleaner and better annotated notebooks later this week, and follow up on the pyoos list. There are some issues with pyoos parsing of these templates that I'll discuss there, and try to fix if possible.

BTW, I'm doing most of this pyoos work with SECOORA's Dan Ramage, with help from Dave Foster (ASA) and Rich Signell, and previously from Kyle Wilcox.

Cheers,
-Emilio

Reply all
Reply to author
Forward
0 new messages