Use gml:location/gml:MultiPoint to represent GetObs response location metadata

[GoogleCodeExporter]

Previously we had largely focused on using gml:location/gml:Point to represent 
the GetObs response location metadata, at least for single-station responses.

As we have embraced the use of network offerings with multi-station responses, 
gml:location/gml:Point will not be sufficient.

I propose to always use gml:location/gml:MultiPoint instead, even in the simple 
case of a single station response. The single-station degenerate case will look 
like this:
<gml:location>
  <gml:MultiPoint srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
    <gml:pointMembers>
      <gml:Point>
        <gml:pos>34.7 -72.73</gml:pos>
      </gml:Point>
    </gml:pointMembers>
  </gml:MultiPoint>
</gml:location>

Additional stations are represented with additional gml:Point elements. Simple.

This gml:location block will be found within the 
om:featureOfInterest/gml:FeatureCollection block, as was done in the first 
template drafts from Kyle. Together with Issues 21 & 27, this rounds out the 
coherent treatment of om:featureOfInterest as the single container for all 
geospatial and feature-type response metadata (ie, information that's outside 
the om:result block). See the current GetObs template:
http://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/GO-
Station-SingleFT-timeSeries-MultiSensor.xml

Note two potential issues:

1. For multi-station responses, the gml:boundedBy will describe the envelope 
rectangle and gml:location the individual station points. But individual points 
will not be linked to station id's. I don't see that as a problem. That level 
of detail is what the *data* block is for. Providing the collection of points 
in the metadata block is informative without being excessively detailed.

2. For trajectory feature-type responses, gml:MultiPoint will obviously not 
work. We'll have to come up with a more appropriate geometry. That can be 
addressed in a separate Issue. gml:MultiPoint will take care of the two other 
CF feature types we're supporting, timeSeries and timeSeriesProfile.

Original issue reported on code.google.com by emilioma...@gmail.com on 26 Jun 2012 at 5:40

[GoogleCodeExporter]

As Alex noted on comments on the ioostech_dev list, gml:location was deprecated 
at GML 3.1.0. An alternative that fills the same role is needed. Please provide 
suggestions!

I'm adding this comment so it's documented here on the Issue itself, for 
reference and documentation.

Original comment by emilioma...@gmail.com on 27 Jun 2012 at 3:08

[GoogleCodeExporter]

Just a brief comment that after discussions over email and a conference call on 
July 3rd, we've come to agree that gml:location is the best compromise solution 
we've identified. I'll flesh this out later, point to relevant ioostech_dev 
email threads, and write up the resolution of this Issue.

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

[GoogleCodeExporter]

The original proposal to use 
om:featureOfInterest/gml:FeatureCollection/gml:location/gml:MultiPoint
in GetObservation is adopted. 

The use of gml:location was "deprecated" in GML 3.1.0. However, we could not 
find a clear replacement that's valid in GML 3.1.1, likely to stay through GML 
3.2.1 and beyond, and not much more complex than the gml:location structure. 
gml:location has the additional, pragmatic advantage of allowing for an 
identical location encoding in GetObservation (gml:location) and DescribeSensor 
(sml:location).

Alex Birger did extensive research on the OGC status of gml:location and 
possible alternatives (THANKS!). His findings and recommendations are found on 
the ioostech_dev list at:
https://groups.google.com/d/topic/ioostech_dev/L7Dr5G0uBbE/discussion
To summarize, from his messages: "The 'deprecated' status does not necessarily 
prohibit the usage of element, it just does not recommend to use it.... All in 
all, I believe that keeping <gml:location> for now would be the right move. It 
is by far the simplest way to present station locations, and the word 
'location' speaks for itself. I don't think that anything so simple and visual 
can replace it."

We also adopted Alex's suggestion to use gml:name elements to associate the 
station id urn with the station coordinate.

gml:location/gml:MultiPoint will be used for all timeSeries and 
timeSeriesProfile stations, even in the simple case of a single station 
response. The single-station degenerate case will look like this:
<gml:location>
  <gml:MultiPoint srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
    <gml:pointMembers>
      <gml:Point>
        <gml:name>urn:ioos:station:wmo:41001</gml:name> 
        <gml:pos>34.7 -72.73</gml:pos>
      </gml:Point>
    </gml:pointMembers>
  </gml:MultiPoint>
</gml:location>

Additional stations are represented with additional gml:Point elements.

For trajectory feature types, the appropriate gml geometric primitive hasn't 
been decided yet. The recommendation will be discussed and settled in Issue 19.

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

• Changed state: Done