SWE Templates without OM wrappers

[Google Code Exporter]

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.

Original issue reported on code.google.com by [e-mail] on 5 Mar 2013 at 6:13

[Google Code Exporter]

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.

Original comment by [e-mail] on 5 Mar 2013 at 6:37

[Google Code Exporter]

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.

Original comment by [e-mail] on 5 Mar 2013 at 6:46

[Google Code Exporter]

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? 

Original comment by [e-mail] on 5 Mar 2013 at 7:49

[Google Code Exporter]

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.

Original comment by [e-mail] on 5 Mar 2013 at 8:36

[Google Code Exporter]

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

Original comment by stu3b3 on 1 May 2013 at 8:46

[Google Code Exporter]

Original comment by [e-mail] on 11 Jul 2013 at 8:09

• Changed state: Done