Closed emiliom closed 10 years ago
Looks like I need to add the same block of code I put in the collect method. We've also addressed the disparity in ncsos so that should be the same output as 52N.
This part of Pyoos was written before any SOS servers adopted the new SensorML outputFormat (text/xml;subtype="sensorML/1.0.1/profiles/ioos_sos/1.0"
). I would just change this hardcoded value to the new acceptable outputFormat and call it a day.
The collect method should also use a hardcoded responseFormat (text/xml;subtype="om/1.0.0/profiles/ioos_sos/1.0"
). Allowing variations will just encourage servers to do whatever works. This will force them to follow the spec (and also break many servers that are out there now, because the templates were wrong for months)!
Agree, just wanted to keep things working for current installs of ncsos considering we just fixed it there too. Maybe keep the workaround but issue a strong warning.
Finally got around to testing IOOS SOS DescribeSensor requests. It looks like this is done via IoosSweSos.metadata, which should accept a required procedure argument and possibly an optional outputFormat argument.
But outputFormat is being hardwired to a specific string (
text/xml;subtype="sensorML/1.0.1"
); see: https://github.com/asascience-open/pyoos/blob/master/pyoos/collectors/ioos/swe_sos.py#L14Besides the problem with hard-wiring, that string doesn't match the outputFormat value used in the 52North IOOS SOS end point, which looks more correct to me (except possibly for the blank space after the semi-colon):
text/xml; subtype="sensorML/1.0.1/profiles/ioos_sos/1.0"
I also tested against an ncSOS endpoint. I got no result (or error), but haven't investigated why.