Multiple procedures in GetObs from request with multiple station offerings

[GoogleCodeExporter]

Shane pointed out recently that we need to accommodate GetObservation requests 
that may list multiple station offerings (as opposed to a network offering that 
encompasses multiple stations). Some decisions have already been made to 
accommodate such cases.

But there's one thorny problem that I can't find a solution for. Currently, 
since offerings and procedures are essentially identical in our IOOS SOS usage, 
the station is represented in an om:procedure element:
<om:procedure xlink:href="urn:ioos:station:wmo:41001"/>
See the GetObs template for more context:
http://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/GO-
Station-SingleFT-timeSeries-MultiSensor.xml

A request for multiple station offerings should return multiple procedure 
elements, right? But apparently that's illegal (Oxygen gives me a validation 
error).

What do we do?

Plan B, if there are no good solutions and no burning need, is to *not* support 
requests with multiple offerings...

Original issue reported on code.google.com by emilioma...@gmail.com on 25 Jun 2012 at 11:00

[GoogleCodeExporter]

Here is the link we discussed today:

http://trac.osgeo.org/mapserver/ticket/2248

Original comment by abir...@gmail.com on 3 Jul 2012 at 7:01

[GoogleCodeExporter]

As we discussed during the telecon on July 3rd, <om:procedure> differs from 
<sos:procedure>.

Here is what http://schemas.opengis.net/om/1.0.0/observation.xsd schema has for 
<om:procedure>:

<element name="procedure" type="om:ProcessPropertyType">
  <annotation>
   <documentation>
     The procedure is the description of a process used to generate the result. 
     It must be suitable for the observed property. NOTE: At this level we do not
     distinguish between sensor-observations, estimations made by an observer, or
     algorithms, simulations, computations and complex processing chains.
   </documentation>
  </annotation>
</element>

Note that the schema does not provide any info on cardinality of the element. 
Judjing by Oxygen reaction on a second <om:procedure> element as well as on a 
complete absence of it, I would assume that no cardinality info means 
minOccurs=1; maxOccurs=1 by default. It may be confirmed by observing the UML 
diagram on page 12 of the OGC 07-022r1 "O&M - Part 1 - Observation schema" spec 
- it clearly indicates cardinality 1 for <procedure> element.

On the contrary, http://schemas.opengis.net/sos/1.0.0/sosGetObservation.xsd 
schema provides explicit cardinality info on <sos:procedure> element as follows:

<element name="procedure" type="anyURI" minOccurs="0" maxOccurs="unbounded">
  <annotation>
   <documentation>
     Index of a particular sensor if offering procedure is a Sensor Array. 
     Allows client to request data from one or more sensors in the array. 
     The size of the array should be specified in the selected offering
     capabilities. This is to support scenarios with sensor grids 
     (we don't want to have one offering for each sensor in that case).
     Note that sensorML can describe Sensor Arrays too. 
   </documentation>
  </annotation>
</element>

It is obvious that there may be many <sos:procedure> elements. However, 
<sos:procedure> is allowed by OGC SOS spec only in GetObservation request, and 
the response to a GetObservation request is an O&M Observation, an element in 
the
Observation substitution group, or an ObservationCollection, where 
<om:procedure> has to be used.

All in all, the use of <sos:procedure> instead of <om:procedure> seems to be 
wrong, and wpuldn't resolve the issue. It looks like the only way is to use 
<om:member>/<om:Observation> structure per station.

Original comment by abir...@gmail.com on 6 Jul 2012 at 5:29

[GoogleCodeExporter]

Thank you, Alex. Very useful background. I hadn't realized that the procedure 
element in GetCapabilities was sos:procedure while the one in GetObservation 
was om:procedure. This makes more sense now.

Using one <om:member>/<om:Observation> structure per station seems like an 
excessively complex and verbose solution to this issue, though clearly it does 
look like the most schema-compliant one we've identified.

I'm working on comments on this issue right now. I thought we had a reasonable 
solution from the conference call, in using multiple station id urn's in the 
GetObservation om:procedure, like this:
<om:procedure xlink:href="urn:ioos:station:wmo:41001 
urn:ioos:station:wmo:41002"/>

But I've found an inconsistency that I will describe soon.

Original comment by emilioma...@gmail.com on 6 Jul 2012 at 6:21

[GoogleCodeExporter]

Some background discussions, before I make a proposed solution (or two choices) 
in a separate comment:

We discussed this issue extensively at the July 3 conference call. OGC has 
inconsistent information on whether multiple om:procedure elements can be 
listed within an om:ObservationCollection/om:member/om:Observation block. An 
OGC document (Alex and Shane had the exact reference and page #) gives examples 
showing >1 om:procedure element. As Alex points out above, the cardinality is 
not listed in the schema but other evidence makes it fairly clear that only one 
om:procedure is allowed per om:Observation block.

We also clarified that a GetObs request must include one, and *only* one, 
offering, but can include multiple procedures. Since IOOS SOS common practice 
has been that offerings and procedures are effectively identical, in the past 
we haven't really used procedure parameters in the requests (they've been 
redundant) and typically have conflated offerings with procedures. For example, 
in GetCapabilities, we've agreed that the sos:ObservationOffering element for a 
network offerings will have one sos:procedure element with xlink:href="<NETWORK 
ID URN>" (the individual station procedures encompassed by the network offering 
will be obtained via a DescribeSensor request; see Issue 23 
[http://code.google.com/p/ioostech/issues/detail?id=23], now closed).

Some additional things that have become clear, from the conference call and 
follow ups:
- The only way to request or potentially obtain multiple stations is by using a 
"network" offering.
- The individual station id urn's will be listed as gml:name elements in 
om:featureOfInterest/gml:FeatureCollection/gml:location; of course, they're 
also listed in the om:result data block.
- We decided earlier that each om:Observation element will serve as a grouping 
of all stations of the same feature type (See Issue ).
- A network offering request may or may not include a procedure parameter 
(procedure parameters are optional in a GetObs request).

It follows that the response should be very similar or identical for all 
network offering requests, regardless of whether a procedure parameter was 
passed or not. In both cases, the network offering urn should be shown 
somewhere, for reference; and om:procedure should contain all the station-id 
urn's for stations included in the response.

I've investigated a few options. See the next comment.

Original comment by emilioma...@gmail.com on 6 Jul 2012 at 8:05

[GoogleCodeExporter]

There are two parts to this proposal; the two *options* are in part #2.

1. Since the network offering urn should be shown somewhere, for reference, I 
propose that it be displayed just once, outside the om:Observation elements, as 
the content of a /om:ObservationCollection/gml:name element. That way it 
applies to all om:Observation elements. For station offerings, 
/om:ObservationCollection/gml:name could show the station urn; Alternatively 
this element could be dropped for station offerings, but it seems better to 
include it for more predictable client parsing.
For /om:ObservationCollection/om:member/om:Observation/gml:name, I suggest 
something like this naming pattern:
<OFFERING ASSET URN>-<FEATURE TYPE>
eg: <gml:name>urn:ioos:network:noaa.nws.ndbc:all-timeSeries</gml:name>

2. The single om:procedure element will list all the station urn's 
corresponding to the om:Observation feature type. I see two options for doing 
this:
  a. The kludgy option we settled on at the call, referenced by Alex in a URL on Comment 1, is to include all the urn's in xlink:href attribute string, as a space-delimited list making up a single string. eg:
  <om:procedure xlink:href="urn:ioos:station:wmo:41001 urn:ioos:station:wmo:41002"/>
  That could become a hairy xlink:href string for lots of stations (say, >100)! But it's a simple XML element.
  b. Break out station urn's into individual XML elements within om:procedure. Here's the simplest validated structure I've come up with:
    <om:procedure>
      <om:Process>
        <gml:member xlink:href="urn:ioos:station:wmo:41001" />
        <gml:member xlink:href="urn:ioos:station:wmo:41002" />
      </om:Process>
    </om:procedure>
  This is more verbose than Option a, but a bit less kludgy. For a single station, the same structure could be used, but with only one gml:member.

Actually, there's a third, kludgier option ("2.c"): Include the simple 
om:procedure element but with dummy xlink:href content. For network offerings, 
the individual station urn's will already be listed in both 
/om:ObservationCollection/om:member/om:Observation/om:featureOfInterest/gml:Feat
ureCollection/gml:location
and
/om:ObservationCollection/om:member/om:Observation/om:result/swe:DataStream

Comments, votes??

Original comment by emilioma...@gmail.com on 6 Jul 2012 at 8:31

[GoogleCodeExporter]

I like option 2b more as it seems to be the most harmonious and easy to read, 
and it allows the use of the same structure regardless of number of stations. 

Option 2a, actually, can be used for various number of stations as well, so 
it's OK too. However, it becomes unreadable ("hairy") with relatively small 
number of stations (that is the only real drawback that I can see), and it just 
looks worse...

Original comment by abir...@gmail.com on 6 Jul 2012 at 9:32

[GoogleCodeExporter]

Thanks for your comments, Alex.

Since there are no other comments, we're going with option 2b. See Comment 5 
for a complete description of the approach to be used. This has already been 
implemented in the latest version of the GetObservation Milestone1.0 template.

Original comment by emilioma...@gmail.com on 11 Jul 2012 at 2:42

[GoogleCodeExporter]

Original comment by emilioma...@gmail.com on 11 Jul 2012 at 2:42

• Changed state: Done