search

valentinedwv / ioostech

Automatically exported from code.google.com/p/ioostech
0 stars 0 forks source link

Representing FeatureType in SWE output #21

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Currently in two places, we should choose which is recommended (which is picked 
up by parsers).

I prefer the first since it keeps the SWE elements the same between all 
FeatureTypes

1)
<om:featureOfInterest>
  <gml:FeatureCollection>
    <gml:metaDataProperty>
      <gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">timeSeries</gml:name>
    </gml:metaDataProperty>
    <gml:location>
      ...
    </gml:location>
  </gml:FeatureCollection>
</om:featureOfInterest>

2)
<om:result>
  <swe:DataStream definition="timeSeries">
  ...
</om:result>

Original issue reported on code.google.com by wilcox.k...@gmail.com on 5 Jun 2012 at 5:53

GoogleCodeExporter commented 8 years ago 
Based on the templates I'd been working with, I thought #1 was already the 
consensus. I agree with your suggestion to go with #1, in general. But an issue 
I just noticed is cases when the response includes >1 feature types (eg, 
timeseries, timeseries profile).

It looks like we can handle such complex cases via a gml:featureMembers child 
of gml:FeatureCollection, which in turn can have >=1 gml:FeatureCollection 
children, one per CF feature type. eg:

<om:featureOfInterest xlink:href="ID_1">
  <gml:FeatureCollection>
    ...
    <gml:featureMembers>
      <gml:FeatureCollection>
        <gml:metaDataProperty>
          <gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">timeSeries</gml:name>
        </gml:metaDataProperty>
        ...
      </gml:FeatureCollection>
      <gml:FeatureCollection>
        <gml:metaDataProperty>
          <gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">timeSeriesProfile</gml:name>
        </gml:metaDataProperty>
        ...
      </gml:FeatureCollection>
    </gml:featureMembers>
  </gml:FeatureCollection>
</om:featureOfInterest>

That's ugly and verbose, but legal, and keeps all that "feature" information 
within om:featureOfInterest, which makes a lot of sense. But then we'll need to 
have a way to link each swe:DataChoice/swe:item with a gml:FeatureCollection. A 
gml:FeatureCollection gml:id attribute convention seems workable.

So, for the simple and most common case of a response with a single feature 
type looks like this:
<om:featureOfInterest xlink:href="ID_1">
  <gml:FeatureCollection>
    ...
    <gml:featureMembers>
      <gml:FeatureCollection>
        <gml:metaDataProperty>
          <gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">timeSeries</gml:name>
        </gml:metaDataProperty>
        ...
      </gml:FeatureCollection>
    </gml:featureMembers>
  </gml:FeatureCollection>
</om:featureOfInterest>

Original comment by emilioma...@gmail.com on 6 Jun 2012 at 3:00

GoogleCodeExporter commented 8 years ago 
We shouldn't be combining different feature types in a single om:Observation 
block

Adopting #1 is my vote

Original comment by wilcox.k...@gmail.com on 12 Jun 2012 at 2:37

GoogleCodeExporter commented 8 years ago 
This issue is linked to Issue 20 
(http://code.google.com/p/ioostech/issues/detail?id=20), and much of the meaty 
discussion on this issue took place there. Refer to it for more details.

Since no one (myself included) has presented and defended a clearly better 
alternative, and it's been a week, we'll go with the proposal described by Kyle 
and elaborated on by Shane: 

In GetObservation responses, each unique CF feature type 
(discrete-sampling-geometries) will be encoded in a separate 
om:member/om:Observation block that may contain multiple stations. Conversely, 
all stations corresponding to one feature type will be returned in a single 
om:member/om:Observation block.

This decision only impacts "network" offerings, as they are the only request 
type that may return multiple stations (features), with the potential to span 
all 3 CF feature types.

The encoding of the reference to the CF feature type will be done within 
/om:ObservationCollection/om:member/om:Observation/om:featureOfInterest/gml:Feat
ureCollection, as follows:
<gml:metaDataProperty>
    <gml:name codeSpace="http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html#discrete-sampling-geometries">timeSeries</gml:name>
</gml:metaDataProperty>

In addition to not having come up with obviously better alternatives, this 
scheme is intended to broadly align with the separation of feature types in CF, 
without the awkward, inconvenient restrictions found in a CF netcdf file, which 
can not mix feature types.

Still, we're likely to face some challenges. Beyond any parsing issues, I see 
the following issues:
- No single block will represent the temporal span, geographical bounding box, 
and set of observed properties returned by the request.
- Platforms that include both profile ocean data (eg, depth profilers or 
moorings with sensors at many depths) and weather sensors can't be neatly 
categorized as just "timeSeriesProfile" feature type; the weather sensors may 
be more naturally represented as a timeSeries feature type.

We haven't explored timeSeries profiles and trajectories extensively, so all 
the implications are not obvious yet. But we'll probably have to be a bit 
flexible with this rule, specially when deciding whether a platform is a 
timeSeriesProfile vs. a plain timeSeries with multiple sensors; the boundary 
between those two will be fuzzy.

Original comment by emilioma...@gmail.com on 20 Jun 2012 at 3:43

GoogleCodeExporter commented 8 years ago 
"This decision only impacts "network" offerings, as they are the only request 
type that may return multiple stations (features), with the potential to span 
all 3 CF feature types."

I don't think that is correct, A user can request multiple offerings that are 
not part of any 'network' offering.  They can be of any featuretype, and the 
server will need to know to split them into multiple om:Observation blocks.

Other than the above comment: +1 for running with this

Original comment by wilcox.k...@gmail.com on 21 Jun 2012 at 2:42

GoogleCodeExporter commented 8 years ago 
Ah, I was overlooking the possibility of a request for multiple offerings. 
Thanks for pointing it out.

I'm not sure that that's actually been supported in the past, but if the SOS 
specs say that multiple-offerings requests should be supported, that's that.

Hopefully these comments here will be enough documentation for other server 
developers (Kyle and others?) to keep this case in mind. For client developers, 
there are no special issues.

Original comment by emilioma...@gmail.com on 21 Jun 2012 at 7:15

GoogleCodeExporter commented 8 years ago 
Issue 6 has been merged into this issue.

Original comment by emilioma...@gmail.com on 30 Jun 2012 at 2:16

GoogleCodeExporter commented 8 years ago 
For reference, my original statement about network offerings (see Comment 3) 
turned out to be true: "This decision only impacts "network" offerings, as they 
are the only request type that may return multiple stations (features), with 
the potential to span all 3 CF feature types." We've clarified that only one 
offering parameter is allowed, but multiple procedure parameters can be 
requested. See the discussion in Issue 26.

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