DescribeSensor - Standardize location/position representations

[GoogleCodeExporter]

Can we either use the <sml:positions>, <sml:position>, or <sml:location> 
element, rather than mix and match the three?

I think it might be a good idea to abstract all of the FeatureTypes into a 
<sml:positions> element.  May be a bit more verbose, but the standardization 
will help.

<sml:location>: 
http://sdftest.ndbc.noaa.gov/sos/server.php?request=DescribeSensor&service=SOS&v
ersion=1.0.0&outputformat=text/xml;subtype=%22sensorML/1.0.1%22&procedure=urn:io
os:station:wmo:41012

<sml:position>: 
http://sdftest.ndbc.noaa.gov/sos/server.php?request=DescribeSensor&service=SOS&v
ersion=1.0.0&outputformat=text/xml;subtype=%22sensorML/1.0.1%22&procedure=urn:io
os:station:wmo:48900

<sml:positions>: 
http://sdftest.ndbc.noaa.gov/sos/server.php?request=DescribeSensor&service=SOS&v
ersion=1.0.0&outputformat=text/xml;subtype=%22sensorML/1.0.1%22&procedure=urn:io
os:station:wmo:52402

Original issue reported on code.google.com by wilcox.k...@gmail.com on 31 May 2012 at 7:10

[GoogleCodeExporter]

Good catch. These 3 cases apparently represent 3 different situations:

1. wmo:41012. A simple station with one fixed point location. It uses 
sml:location:
  <sml:location>
    <gml:Point gml:id="STATION-LOCATION-41012" srsName="urn:ogc:crs:epsg::4326">
      <gml:coordinates>30.04 -80.55</gml:coordinates>
    </gml:Point>
  </sml:location>
BTW, gml:coordinates is "deprecated in GML Version 3.1.0", and apparently 
should be replaced with gml:pos

2. wmo:52042. A DART buoy moored on deep water. The sensor at the bottom of the 
water column is assigned its own lat-lon location, different from the 
buoy/transmitter, so it uses sml:positions:
/sml:positions/sml:PositionList/sml:position[name="stationPosition"]
  /swe:Position/swe:location
  /swe:Vector[gml:id="STATION_LOCATION" definition="urn:ogc:def:property:OGC:location"]
Needless to say, we have never discussed a case like this. The use of 
swe:Vector and swe:coordinate elements makes this fundamentally different and 
more complex/verbose than using sml:location (#1 above).

3. wmo.48900. This is glider, so the location is bound to be trickier; should 
it be a trajectory? NDBC is representing it with the actual, timestamped 
trajectory, using sml:location and a swe data block. Having the actual 
trajectory in the SensorML seems to me like overkill and maybe misplaced. I may 
be wrong, but I view the SensorML as more static information. The trajectory 
itself could be treated as an observable to be accessed via GetObservation. But 
I don't think we've talked much about SensorML for gliders.

My preference in all cases would be for simplicity (hence I like Case #1) and 
common representations. I'm not sure what to suggest to unify these 3 cases, 
but it's clear that they're currently way too divergent. I also would like to 
see consistency (for ease of parsing) with spatial representations in 
GetObservation; currently for a point, we have in 
/om:ObservationCollection/om:member/om:Observation/om:featureOfInterest/gml:Feat
ureCollection :

  <gml:location>
    <gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
      <gml:pos>32.5 -78.5</gml:pos>
    </gml:Point>
  </gml:location>

That's pretty similar to Case #1, so I like that. But BTW, gml:location is 
apparently "deprecated in GML Version 3.1.0".

Kyle, what do you suggest?

Original comment by emilioma...@gmail.com on 1 Jun 2012 at 11:51

[GoogleCodeExporter]

Original comment by emilioma...@gmail.com on 2 Jun 2012 at 12:14

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by emilioma...@gmail.com on 4 Jun 2012 at 3:59

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

I wasn't getting notifications, will look at this soon

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

[GoogleCodeExporter]

Kyle & Mike (and others): Any comments on this? We currently don't have a 
proposal per se, just my partial suggestion. So, more input is needed.

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

[GoogleCodeExporter]

sml:location within DescribeSensor
gml:location within GetObservation

The contents of these two blocks will be IDENTICAL between DescribeSensor and 
GetObservation responses.

Original comment by wilcox.k...@gmail.com on 3 Jul 2012 at 7:21

[GoogleCodeExporter]

Darn -- I had typed up a long comment here, and lost it! So, briefly:
- We've agreed (specially at the July 3rd conference call) That the location 
block in both DescribeSensor and GetObservation should be limited to contain 
only "geospatial", lat-lon / Y-X information; this lets us use EPSG 4326 for 
most, if not all cases.
- Z information will be encoded in the sensor-specific blocks.
- Issue 28, http://code.google.com/p/ioostech/issues/detail?id=28 is very 
relevant to this point. We've agreed that the use of gml:MultiPoint is a 
reasonable, general solution to meet all platforms or data collection systems 
that may be viewed as point-based from a geospatial, XY perspective. That 
includes simple platforms with sensors at a fixed depth, CTD's, depth 
profilers, and platforms with sensors at several elevations/depths.
- Kyle is looking into an appropriate gml primitive for trajectories. From a 
quick look, I think gml:LineString seems to meet that need.

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

[GoogleCodeExporter]

Just when I had finalized and completed Issue 28, I discover that sml:location 
does not allow gml:MultiPoint like gml:location does !! gml:Point would still 
be in line with what we discussed on the July 3rd conference call (ie, show a 
single *station* point lat-lon location for timeSeries and timeSeriesProfile 
station assets), but the sml:location encoding would be different from the 
GetObservation gml:location encoding -- breaking the goal we had (see Comment 6 
from Kyle).

Suggestions??

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

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Wow, that's a bummer... I briefly looked through the SensorML spec, and I 
haven't seen an easy way out. I believe it is a natural constraint - (1) 
<sml:location> is a part of description of a single station (<sml:System>), and 
(2) each station/system may have a set of sensors, and all of them are defined 
in <sml:components> element. In case of multiple points in <sml:location> 
element the meaning of both <sml:System> and <sml:components> elements becomes 
uncertain (not clear which station it should be attributed to). 

So, I can think of at least 3 options here:

(1) forget about that ambitious goal, and reconcile to 2 different blocks for 
GetObservation and DescribeSensor seeking consolation just in use of a common 
element <location> in both.

(2) get rid of the station location description in DescribeSensor altogether - 
the station is defined by its ID/name anyway, and its exact geographical 
position may be obtained via GetCapabilities or GetObservation request, so 
there will not be any real harm done.

(3) remove <sml:location>, and replace it with something canonical like the 
following block:

        <sml:System>
            <gml:description>STATION DESCRIPTION</gml:description>
            <gml:name>urn:ioos:station:wmo:41001</gml:name>
            <gml:boundedBy>
                <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                    <gml:lowerCorner>34.7 -72.73</gml:lowerCorner>
                    <gml:upperCorner>34.7 -72.73</gml:upperCorner>
                </gml:Envelope>
            </gml:boundedBy> 

Although it seems bulky and not as visual as <sml:location>, it is formally 
right and always will be...

Original comment by abir...@gmail.com on 11 Jul 2012 at 5:10

[GoogleCodeExporter]

Thanks for the research and options, Alex.

I was leaning towards the argument you make, that it's a natural constraint 
that DescribeSensor returns a single station description. But we also have 
DescribeSensor responses for network procedures, which would have multiple 
stations. We had earlier agreed to have network DescribeSensor responses be 
very minimal, mainly having components that point to the individual station 
procedures. We didn't specifically talk then about what should be done with 
sml:location for network procedures, but the gml:MultiPoint made good sense 
(just as it does in GetObservation).

Regarding your options, I definitely don't like #2. We've moved in the 
direction of using DescribeSensor to provide a good (but not too huge) 
"metadata" response of very useful information. A station DescribeSensor 
response w/o geographical position would be crippled, and GetCapabilities and 
GetObservation are potentially too much overhead just to get that information.

#1 is what we're facing. The only option I can see for maintaining consistency 
within the location blocks across GetCapabilities and GetObservation is to 
backtrack from my suggestion to use gml:MultiPoint even for single-point 
responses; instead, use gml:Point for single-station GetObservation offering 
requests, and gml:MultiPoint for network offerings (for timeSeries and 
timeSeriesProfile). At least that retains consistency for station responses, at 
the cost of slightly more varied responses in GetObservation. But with this 
scheme, I don't know what a useful location response should be for a network 
procedure. A bounding box makes sense then, like your #3.

Hmm...

Original comment by emilioma...@gmail.com on 11 Jul 2012 at 8:46

[GoogleCodeExporter]

Using gml:Point for single procedure (station/sensor) GetObservation responses 
to match DescribeSensor's sml:location seems reasonable to me. Although it 
would have been consistent, using gml:MultiPoint for a single station always 
seemed a little odd to me. Also using gml:Envelope for network DescribeSensor 
responses seems like a good approach. Server implementations can include each 
station's location in child components if they choose, and clients can still 
get each child's location from its own DescribeSensor response.

Original comment by srstcl...@gmail.com on 18 Jul 2012 at 12:10

[GoogleCodeExporter]

More than anything I think we need to adopt a solution in the very short term, 
with the knowledge that we may revisit it in future milestones (especially as 
the standards groud shifts underneath us).

Original comment by srstcl...@gmail.com on 18 Jul 2012 at 12:11

[GoogleCodeExporter]

So...apparently there is a schema element name conflict in sml:System. 
sml:System is a descendant of sml:AbstractDerivableComponent, which has an 
sml:location element. However, sml:AbstractDerivableComponent is a descendant 
of gml:AbstractFeatureType which has gml:location. This causes a known issue 
when working with the SensorML schema in Java (at least using xmlbeans and 
Xerces):

https://wiki.52north.org/bin/view/SensorWeb/SensorML
http://sensorapp.net/?p=71

Whether this is a schema oversight, an xmlbeans bug, or both, it's currently a 
roadblock for me. We've reverted back to using sml:position in the 52n 
implementation for now. sml:positions is also available. Is the group willing 
to abandon sml:location?

Original comment by sh...@axiomalaska.com on 29 Aug 2012 at 6:51

[GoogleCodeExporter]

This will be a major bummer, to have fundamentally different location metadata 
representations in GetObservation and DescribeSensor. Also, for trajectory 
feature types, it looked like we could use sml:location/gml:LineString, but the 
encoding for sml:position would be pretty brutal -- basically a SWE Common data 
block (there are still open issues about what geographical representation 
should be used for trajectory "metadata" location, but that's for another time).

Is there no other solution that's not too painful and allows us to retain 
sml:location? I know it sounds like there isn't, but it doesn't hurt to 
insist...

Original comment by emilioma...@gmail.com on 30 Aug 2012 at 9:43

[GoogleCodeExporter]

After much suffering I think I found a way around this issue. Working on 
getting the 52n xml schema libs patched now. I'm going to mark this as Done.

Original comment by sh...@axiomalaska.com on 5 Sep 2012 at 1:01

• Changed state: Done

[GoogleCodeExporter]

I assume you're saying you found a way to keep using sml:location after all, 
avoiding the validation issues you were running into in the 52North stack. Can 
you confirm? A Yes is all that's needed, unless it's a No ...

Original comment by emilioma...@gmail.com on 5 Sep 2012 at 8:14

[GoogleCodeExporter]

Yep.

Original comment by sh...@axiomalaska.com on 5 Sep 2012 at 9:21