use of vector m_type (num_types > 1) in oostethys_sos.cgi

[Emilio Mayorga]

Hi Jeremy,

One issue I've run into with oostethys_sos.cgi is multi-value
measurements. I'm using a 2-value vector m_type for current velocity,
and was planning to do the same for wind velocity and possibly another
m_type. But the SOS server code has no mechanism to pull out the 2nd
value from that vector. I've looked through your version of that code,
Xiaoyan's, and also your difSOS.cgi, and none of them seem to handle
vector m_types; Eric's original code uses a SQL view, so it's
impossible to see whether something is going on in that view.

Am I missing something? Do you use vector m_types at all in your Xenia
instances? I see two options: drop the use of vector measurements, or
figure out a way to turn the vector m_types into separate scalar
m_types, on the fly (via SQL statements or in the Perl code).

Thanks!

-Emilio

[Jeremy Cothran]

Hi Emilio,

I believe the way Eric's hash is currently set up for oostethys_sos.cgi , if multiple rows are given with the same elevation, then it will describe and list the results correctly.  I don't think that multiple observations at differing elevations are returned by the hash correctly at this time(Eric please correct me if I'm wrong regarding that).

So the simplest trick I think would be in regards to vectors(same elevation) to match with Eric's existing hash is to create separate SQL resultsets(multiple SQL queries varying by each scalar component of the vector (m_value,m_value_2,...) and let the hash associate these by time/location in the final output.

Does that make sense?  Copying Eric in case he has thoughts about changing the oostethys_sos.cgi script regarding vectors or multiple observations at varying elevations.

Thanks

Jeremy

[Emilio Mayorga]

Thanks, Jeremy. The first issue you discuss doesn't appear to be a
problem. Most of the data I'm dealing with are CTD casts -- multiple
depths, several observed properties per observation "event"
(location-depth-datetime event). I haven't seen any problems with
this.

I'll wait to see what Eric has to say about the second issue, vector
(multi-component) observations. It sounds like you're not handling
these. Thanks for the suggestion.

Cheers,

-Emilio

[Emilio Mayorga]

Hi Eric & Jeremy,

Thanks for your input. Some comments below, but first this: Eric,
would you prefer that I cc the OOSTETHYS list for this sort of
question? It's at the intersection of the Xenia RDB and
oostethys_sos.cgi, so I wasn't sure.

> The resultset for the following query shows nulls for certain columns:
> <swe:values>A01,2009-05-01T12:00:00Z,42.5222511291504,-70.5682830810547,-3,10.710000038147,
> A01,2009-05-01T12:00:00Z,42.5222511291504,-70.5682830810547,1,,8.3100004196167
> A01,2009-05-01T12:00:00Z,42.5222511291504,-70.5682830810547,2,,8.25459671
> A01,2009-05-01T12:00:00Z,42.5222511291504,-70.5682830810547,20,,4.2020001411438</swe:values>
>
> http://www.gomoos.org/cgi-bin/sos/V1.0/oostethys_sos.cgi?request=GetObservation&service=SOS&version=1.0.0&responseFormat=text%2Fxml%3B%20subtype%3D%22om%2F1.0%22&offering=A01&observedProperty=http%3A%2F%2Fmmisw.org%2Fcf%23air_temperature,http%3A%2F%2Fmmisw.org%2Fcf%23sea_water_temperature

Having nulls for this particular request seems natural. Maybe a better
question would be, should a more explicit representation of nulls be
encoded (does O&M/SWE provide one), or is this good enough?

>>> I believe the way Eric's hash is currently set up for oostethys_sos.cgi ,
>>> if multiple rows are given with the same elevation, then it will describe
>>> and list the results correctly.  I don't think that multiple observations at
>>> differing elevations are returned by the hash correctly at this time(Eric
>>> please correct me if I'm wrong regarding that).
>>

>> I think you are wrong regarding this.  observedProperties at multiple
>> elevations are handled. GoMOOS Buoy A01 has an ACDP which reports currents
>> every 4 meters down to the bottom.  When a request is for
>> direction_of_sea_water_velocity the query returns values for all depths and
>> since each record is keyed by depth all the values are returned.  E.g.

Yes, I don't see any problems at all with this issue, in my own
implementation and in looking at the code.

>>> So the simplest trick I think would be in regards to vectors(same
>>> elevation) to match with Eric's existing hash is to create separate SQL
>>> resultsets(multiple SQL queries varying by each scalar component of the
>>> vector (m_value,m_value_2,...) and let the hash associate these by
>>> time/location in the final output.
>>

>> The above facts raise a couple of possible approaches.  In fact I agree
>> with Jermey's approach above.  I would modify the SQL for that special case
>> of vector quantities.  Or modify the code to calculate a single value for
>> current direction.
>> But I think you may have success by defining special offerings in your
>> configuration file.  Define one offering for both the x  and y components of
>> your vector: direction_of_sea_water_velocity_north and
>> direction_of_sea_water_velocity_east.
>>
>> Then the request could be formulated as
>> observedProperty=x_component,y_component.
>>
>> I do agree that the whole script could be improved for handling vector
>> type measurements.

Thanks for the comments & suggestions from both of you. This still
raises the question for me of whether storing some measurements as
vectors is more trouble than it's worth. I'm still at a stage where I
can change this if I want to.

Note that I also would need to modify the code of the GetCapabilities
and DescribeSensor request so they identify and return the second
component of vector measurements as an available observedProperty.
BTW, I'm pulling the observedProperty list from a query to the
database, not a configuration file.

I'll report back when I make progress on this. Thanks again for your help!

-Emilio

[Jeremy Cothran]

Hi Emilio and Eric,

My bad, in looking at the resultset again more carefully, I see that it is reporting differing values at differing elevations - will post Eric's earlier email/correction to the xeniava group.

>This still raises the question for me of whether storing some measurements as
vectors is more trouble than it's worth.

The vector stuff is the exceptional case for most of what I've worked with so I'd say in general it's easier to store/push it as a scalar and decompose to vector on the fly as needed.

Thanks

Jeremy

[jcothran]

Hi Emilio,

>I believe the way Eric's hash is currently set up for oostethys_sos.cgi , if multiple rows are given with the same elevation, then it will describe and list the results correctly. I don't think that multiple observations at differing elevations are returned by the hash correctly at this time(Eric please correct me if I'm wrong regarding that).

I think you are wrong regarding this. observedProperties at multiple
elevations are handled. GoMOOS Buoy A01 has an ACDP which reports
currents every 4 meters down to the bottom. When a request is for
direction_of_sea_water_velocity the query returns values for all
depths and since each record is keyed by depth all the values are
returned. E.g.

http://tinyurl.com/co6hby
http://www.gomoos.org/cgi-bin/sos/V1.0/oostethys_sos.cgi?REQUEST=GetObservation&offering=A01&observedProperty=direction_of_sea_water_velocity

This request can also be modified to handle multiple
observedProperties occuring at the same elevation (depth) e.g.
observedProperty=direction_of_sea_water_velocity,sea_water_speed. E.g.
http://tinyurl.com/dayvgw
http://www.gomoos.org/cgi-bin/sos/V1.0/oostethys_sos.cgi?REQUEST=GetObservation&offering=A01&observedProperty=direction_of_sea_water_velocity,sea_water_speed

>So the simplest trick I think would be in regards to vectors(same elevation) to match with Eric's existing hash is to create separate SQL resultsets(multiple SQL queries varying by each scalar component of the vector (m_value,m_value_2,...) and let the hash associate these by time/location in the final output.

The above facts raise a couple of possible approaches. In fact I

agree with Jeremy's approach above. I would modify the SQL for that

special case of vector quantities. Or modify the code to calculate a
single value for current direction.
But I think you may have success by defining special offerings in your
configuration file. Define one offering for both the x and y
components of your vector: direction_of_sea_water_velocity_north and
direction_of_sea_water_velocity_east.

Then the request could be formulated as
observedProperty=x_component,y_component.

I do agree that the whole script could be improved for handling vector
type measurements.

On Apr 30, 6:36 pm, Jeremy Cothran <jeremy.coth...@gmail.com> wrote:
> Hi Emilio,
> I believe the way Eric's hash is currently set up for oostethys_sos.cgi , if
> multiple rows are given with the same elevation, then it will describe and
> list the results correctly.  I don't think that multiple observations at
> differing elevations are returned by the hash correctly at this time(Eric
> please correct me if I'm wrong regarding that).
>
> So the simplest trick I think would be in regards to vectors(same elevation)
> to match with Eric's existing hash is to create separate SQL
> resultsets(multiple SQL queries varying by each scalar component of the
> vector (m_value,m_value_2,...) and let the hash associate these by
> time/location in the final output.
>
> Does that make sense?  Copying Eric in case he has thoughts about changing
> the oostethys_sos.cgi script regarding vectors or multiple observations at
> varying elevations.
>
> Thanks
> Jeremy
>