Issue 53 in ioostech: SWE Templates without OM wrappers

[ioos...@googlecode.com]

Status: Accepted
Owner: dpsnowde...@gmail.com
Labels: Milestone-Release1.0 Type-Review Priority-High

New issue 53 by dpsnowde...@gmail.com: SWE Templates without OM wrappers
http://code.google.com/p/ioostech/issues/detail?id=53

There are several templates in the Milestone 1.0 directory which have SWE-
as the prefix to the file name. Each of these files begin with the root
element
<swe2:DataStream
xmlns:swe2="http://www.opengis.net/swe/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/swe/2.0
http://schemas.opengis.net/sweCommon/2.0/swe.xsd">

These files don't have the
<om:ObservationCollection/om:member/om:Observation element.

I'm assuming this is done just to remove potentially redundant information
from the templates as we deliberate over some of the finer details of the
swe2 encoding that is a child of the om:Observation element. Correct me if
I'm wrong please....

Under that assumption I'm not sure I see the need for the
http://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SWE-MultiStation-TimeSeries-MultiSensor.xml
example. I thought that the om:Observation was going to represent samples
from one platform (akak station) and that the means by which we provide
multiple stations is just to add multiple Observations to the
ObservationCollection.

Is there a need for encoding multiple stations in swe2 using DataChoice
that I'm missing? Are you suggesting this as an alternative or as a better
encoding scheme? I think we need to get down to one template for each of
the major use cases.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ioos...@googlecode.com]

Comment #1 on issue 53 by sh...@axiomalaska.com: SWE Templates without OM
wrappers
http://code.google.com/p/ioostech/issues/detail?id=53

Regarding the SWE-* files, see David's comment in
GO-Station-SingleFT-timeSeries-MultiSensor.xml:

<!-- ===========================================================
om:result (THE "DATA" BLOCK)
=========================================================== -->
<om:result>

<!-- This block can contain any of the various example SWE Result blocks
defined in the -->
<!-- Milestone 1.0 templates as appropriate to the data described above
-->

</om:result>

For Observation level grouping, the decision at the Baltimore meeting was
to have a single feature type per Observation block, which implies the need
for multiple stations in a single Observation.

[ioos...@googlecode.com]

Comment #2 on issue 53 by emilioma...@gmail.com: SWE Templates without OM
wrappers
http://code.google.com/p/ioostech/issues/detail?id=53

Just seconding what Shane said:
For Observation level grouping, the decision at the Baltimore meeting was
to have a single feature type per Observation block, which implies the need
for multiple stations in a single Observation.

We went further than that. We discussed this throughout 2012. I suspect
there's a closed Issue or two (plus email list threads) that addressed
this. My recollection was that in the end we were all pretty comfortable
that there were no troubling issues remaining, related to this approach.
Some inline comments on the template
GO-Station-SingleFT-timeSeries-MultiSensor.xml make references to
multi-station ("Network") responses.

A fully fleshed out GO-Network-SingleFT-timeSeries-MultiSensor.xml template
might be useful, though, for clarity; or one that couples with a SWE
multistation-multisensor template.

[ioos...@googlecode.com]

Comment #3 on issue 53 by dpsnowde...@gmail.com: SWE Templates without OM
wrappers
http://code.google.com/p/ioostech/issues/detail?id=53

I see that there is a conclusion that confirms what Emilio and Shane both
said,
https://code.google.com/p/ioostech/wiki/SOSGuidelines#Representing_feature_type_in_GetObservation

I suppose I didn't think through the implications. My interpretation of
Shane's comment

> For Observation level grouping, the decision at the Baltimore meeting was

> to have a single feature type per Observation block, ...

was that we would not mix classes of featureTypes in the same
om:Observation e.g. no profiles mixed with trajectories. Within an
om:Observation block we have included

<om:procedure>
<om:observedProperty>
<om:featureOfInterest>
in addition to the om:result.

Within featureOfInterest we have a reference to the class of featureTypes
via <gml:metaDataProperty> AND we have the specific location of an instance
of one of those featureTypes in the <gml:location> element. The
om:featureOfInterest is further specified by
<gml:name>urn:ioos:station:wmo:41001</gml:name>. So, if we include
multiple platforms/stations inside the SWE block we need to address that in
the rest of the om:Observation. This seems like a misuse of the
featureOfInstance; is it a class or is it an instance? I think it's an
instance.

Similarly, the fact that there is only one procedure referenced in the
om:Observation implies that the data in the om:result block was generated
by a single process described by a single procedure. I know that
theoretically we have a network procedure but those network procedure
documents are created a priori and aren't dynamically generated as a result
of a query. Consider the use case where you ask the server for temperature
and salinity data in a bounding box that encompasses an NDBC buoy and a
regional buoy. There will be no procedure that describes the combination
of those two platforms.

Finally, this doesn't seem like a big change to me. What is the harm in
encoding the NDBC buoy in one om:Observation block and the regional buoy in
the next block?

[ioos...@googlecode.com]

Comment #4 on issue 53 by sh...@axiomalaska.com: SWE Templates without OM
wrappers
http://code.google.com/p/ioostech/issues/detail?id=53

We need to get a multi-station GO-* template with O&M uploaded to show an
example, but om:procedure and om:observedProperty can both have multiple
values to accomodate multiple procedures (stations) and their observed
properties. Multi-station om:featureOfInterest blocks become
gml:MultiPoints, with each station having a constituent gml:Point.

There's nothing in O&M which restricts us to a single station. If we encode
each station in its own Observation, we'll have huge responses for bounding
box GetObs requests that encompass large numbers of stations as we
replicate all the O&M overhead for each station. It's true that it would be
simpler, but at the meeting we wrung our hands over saving a few characters
in each line of the swe:values block instead of just going with the
straight CSV output, so I was under the impression that our objective has
always been concision over simplicity. That's not meant as an enthusiastic
endorsement of that position, just an observation.

[ioos...@googlecode.com]

Comment #5 on issue 53 by stu3b3: SWE Templates without OM wrappers
http://code.google.com/p/ioostech/issues/detail?id=53


Now that the template names have been finalized lets revisit this issue and
see if we can close it. If we need to add a complete OM example including
multiple stations and multiple feature types with consistent data I would
be glad to do it.

David

[ioos...@googlecode.com]

Updates:
Status: Done

Comment #6 on issue 53 by dpsnowde...@gmail.com: SWE Templates without OM
wrappers
http://code.google.com/p/ioostech/issues/detail?id=53

(No comment was entered for this change.)