observedProperty question

[dan]

I've noticed there are 3 forms the observedProperty response from an SOS server can be, using water_temperature as an example:
water_temperature
http://mmisw.org/ont/cf/parameter/water_temperature
urn:ioos:sensor:org.secoora:carocoops.cap2.buoy:water_temperature

I am not sure if the last one is a valid server response, however I do know PyOOS will create a list of observed_properties in this manner if the server has the first format of simply water_temperature.

WHile testing my endpoint: http://129.252.139.124/thredds/sos/carocoops.cap2.buoy.nc, I used the urn:ioos:sensor:org.secoora:carocoops.cap2.buoy:water_temperature as the variable I was interested in when I built the filter.
I ran .collect() that resulted in a server exception of: "Internal Error in creating output for GetObservation request - java.lang.NullPointerException"

The POST url was:
http://129.252.139.124/thredds/sos/carocoops.cap2.buoy.nc?%27eventTime=2014-01-16T03:14:29Z&service=SOS&offering=urn:ioos:station:org.secoora:carocoops.cap2.buoy&request=GetObservation&version=1.0.0&responseFormat=text/xml;schema=%22om/1.0.0/profiles/ioos_sos/1.0%22&observedProperty=urn:ioos:sensor:org.secoora:carocoops.cap2.buoy:water_temperature

If I remove the urn:ioos:sensor:org.secoora:carocoops.cap2.buoy: prefix, and issue the same POST in the browser, I get a valid response:
http://129.252.139.124/thredds/sos/carocoops.cap2.buoy.nc?%27eventTime=2014-01-16T03:14:29Z&service=SOS&offering=urn:ioos:station:org.secoora:carocoops.cap2.buoy&request=GetObservation&version=1.0.0&responseFormat=text/xml;schema=%22om/1.0.0/profiles/ioos_sos/1.0%22&observedProperty=water_temperature

When I build a .filter( variables=[]), should I use the entries from the observed_properties list on an offering? If so, is the prefix pyoos adds a bug?


Dan

[dan]

Scratch that, it looks like the URN prefix is coming from the ncSOS server after all. 
I was looking in the ALL offering. Appears this is a server issue.


Dan

[Dave Foster]

I took a look at the GetCapabilities that server responds with - it does indeed have the urn: style syntax, which is what I’d expect it to respond to, but yeah I also get the NullReference problem.  I think this is more of an ncSOS issue than a pyoos one - there’s no transformation going on in pyoos.

However, you can simply use the shorthand version in your filter in pyoos and have it work.

Also, I released an RC8 version of ncSOS this week that solves the next bug you’re going to run into - it responds with a typo <DataReocrd> that OWSLib will choke on.

--
You received this message because you are subscribed to the Google Groups "pyoos" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyoos+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dave Foster]

If you wouldn’t mind adding an ncSOS issue for the inconsistency, that would be great.

thanks!

dave

[Dan Ramage]

I can do that, just point me to  where.

Dan

[Dave Foster]

github.com/asascience-open/ncsos/issues

[Emilio Mayorga]

I'm not sure I'm following everything, but regarding this:

> I've noticed there are 3 forms the observedProperty response from an SOS server can be, using water_temperature as an example:
water_temperature
http://mmisw.org/ont/cf/parameter/water_temperature
urn:ioos:sensor:org.secoora:carocoops.cap2.buoy:water_temperature

The second form is the preferred, probably required form in IOOS SOS v1.0/Milestone 1:
http://code.google.com/p/ioostech/wiki/ControlledVocabularies

It's possible pyoos may accept in some cases the simplified first form, for user convenience, but I don't know this for a fact.

The third form is illegal in IOOS SOS v1.0/Milestone 1.

> When I build a .filter( variables=[]), should I use the entries from the
> observed_properties list on an offering? If so, is the prefix pyoos adds a bug?

Yes, the observed_properties list on an offering must be valid options for the variables filter. If that's not the case, it's always the server's fault. But pyoos should *ideally* return a gracious and helpful error/warning message.

Cheers,

-Emilio

[Dan Ramage]

Emilio,

I think I sussed out what is going on. The URN: response is being added by the ncSOS server, at first I thought pyoos was doing that. I've added an issue over here: https://github.com/asascience-open/ncSOS/issues/107

According to the wiki documentation the observedProperty should be an MMI url.  

Dan

From: Emilio Mayorga <emilio...@gmail.com>
Date: Thu, 16 Jan 2014 09:31:40 -0800
To: <py...@googlegroups.com>
Subject: Re: observedProperty question