Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with IOOS SOS DescribeSensor requests (IoosSweSos.metadata()) #23

Closed
emiliom opened this issue Feb 12, 2014 · 3 comments
Closed

Comments

@emiliom
Copy link
Contributor

emiliom commented Feb 12, 2014

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#L14

Besides 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.

@daf
Copy link
Member

daf commented Feb 12, 2014

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.

@kwilcox
Copy link
Member

kwilcox commented Feb 12, 2014

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)!

@daf
Copy link
Member

daf commented Feb 12, 2014

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.

@daf daf closed this as completed in fc0e152 Mar 8, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants