Vertical coordinate reference systems. was [Missing values in axis elements]

[GoogleCodeExporter]

Are missing values allowed in coordinate axis definitions?  

I suggest (Derrick) that we stick to the CF conventions of not allowing missing 
values in axis variables in order to maintain alignment and facilitate easier 
translation between the two formats.  

Before making a decision we should discuss the intent of the 9999 in the NDBC 
example below.  Is the vertical coordinate actually missing because of a 
failure?  Because it is unknown? 

See the altitude coordinate element in the following file.  
http://sdftest.ndbc.noaa.gov/sos/server.php?request=GetObservation&service=SOS&v
ersion=1.0.0&offering=urn:ioos:network:noaa.nws.ndbc:all&observedproperty=air_te
mperature&responseformat=text/xml;subtype=%22om/1.0.0%22&eventtime=2011-03-01T00
:00Z/2011-03-02T00:00Z

<swe:coordinate name="z">
<swe:Quantity definition="http://mmisw.org/ont/cf/parameter/altitude" 
axisID="h">
<swe:uom code="m"/>
<swe:value>9999</swe:value>
</swe:Quantity>
</swe:coordinate>

Original issue reported on code.google.com by dpsnowde...@gmail.com on 18 Apr 2012 at 3:34

[GoogleCodeExporter]

The 9999 z values in the NDBC SWE sample are there because we have not decided 
how to handle these yet.  The templates specify altitude above MSL.  However, 
some of our sensors require an elevation above surface/site elevation.  Do we 
convert all values to altitude above MSL for the z value and report the 
elevation above site level elsewhere?  Doesn't quite seem right, but I defer to 
the experts.  Thanks.

Original comment by mike.gar...@gmail.com on 18 Apr 2012 at 4:03

[GoogleCodeExporter]

I'm not sure what you mean by "The templates specify altitude above MSL".   I 
see the example referencing a CRS identified by 

http://www.epsg-registry.org/indicio/query?request=GetRepositoryItem&id=urn:ogc:
def:crs:EPSG::4979 

which looks to be the WGS 84 reference frame.  The descriptive text specifies, 
"Used by the GPS satellite navigation system." which is not the same as height 
of MSL.  Mike, where did you come up with the notion that the templates 
*specify* MSL.  

I don't believe we want to specify exactly which datum people must use in all 
cases, but we do want to specify how the datum a data provider chooses is 
referenced online and encoded in the file.

That said, what is the best datum for a buoy?  The email thread below has some 
information and the URL below that has more background info.  
http://lists.opengeospatial.org/pipermail/sensorml/2006-April/000116.html
http://www.usna.edu/Users/oceano/pguth/website/so432web/e-text/NIMA_datum/VERTIC
AL%20DATUMS.htm

Original comment by dpsnowde...@gmail.com on 19 Apr 2012 at 12:59

[GoogleCodeExporter]

http://code.google.com/p/ioostech/source/browse/trunk/templates/1.0/Point/point.
xml

And in the snippet in this issue.  The z value is defined as 
http://mmisw.org/ont/cf/parameter/altitude which is meters above MSL.

Original comment by mike.gar...@gmail.com on 19 Apr 2012 at 1:06

[GoogleCodeExporter]

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 1:57

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Is this how we would specify the station location/elevation and sensor 
elevation in SWE?  This is for winds at 45001 which is located at 48.06N 87.78W 
and is 183 meters above sea level.  The wind sensor is mounted 5 meters above 
the surface.

<swe:field name="location">
  <swe:Vector definition="http://www.opengis.net/def/property/OGC/0/PlatformLocation" localFrame="STATION_FRAME" referenceFrame="http://www.opengis.net/def/crs/EPSG/0/4979">
    <swe:coordinate name="lat">
      <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/latitude" axisID="Lat">
        <swe:uom code="deg"/>
        <swe:value>48.06</swe:value>
      </swe:Quantity>
    </swe:coordinate>
    <swe:coordinate name="lon">
      <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/longitude" axisID="Long">
        <swe:uom code="deg"/>
        <swe:value>-87.78</swe:value>
      </swe:Quantity>
    </swe:coordinate>
    <swe:coordinate name="z">
      <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/altitude" axisID="h">
        <swe:uom code="m"/>
        <swe:value>183</swe:value>
      </swe:Quantity>
    </swe:coordinate>
  </swe:Vector>
</swe:field>
<swe:field name="sensorElevation">
  <swe:Vector definition="???" referenceFrame="STATION_FRAME">
    <swe:coordinate name="z">
      <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/height" axisID="h">
        <swe:uom code="m"/>
        <swe:value>5</swe:value>
      </swe:Quantity>
    </swe:coordinate>
  </swe:Vector>
</swe:field>

What is the definition value for the sensorElevation Vector?

Original comment by mike.gar...@gmail.com on 24 Apr 2012 at 2:42

[GoogleCodeExporter]

Not sure whether this is wrong or right yet, but here's another alternative to 
consider from oostethys.org.
EPSG references instantatneous seal level, so it seems most appropriate for 
buoys floating on the water surface.  A drawback of this reference frame is 
that there is no way to convert it to other reference frames.  Also, it's not 
exactly correct for instruments below a buoy which are more accurately measured 
as a distance along a cable and not as a distance below the sea surface.  These 
differ because the cables under a slack line buoy doesn't hang straight down 
but follows a catenary. Nevertheless, this seems to fit.  Some questions remain 
wrt putting it all together.

         <swe:field name="Depth">
            <!--EPSG 5113 stands for sea level -->
            <swe:Quantity definition="http://mmisw.org/ont/cf/parameter/depth" referenceFrame="urn:ogc:def:crs:EPSG:6.15:5113">
               <swe:uom code="m"/>
            </swe:Quantity>
         </swe:field>

FWIW--
While they are using netCDF/DAP in favor or SWE, OceanSITES has adopted the 
EPSG 5113 vertical CRS as their choice for metadata inside their netcdf files, 
www.oceansites.org/docs/oceansites_user_manual_version1.2.doc

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 3:45

• Changed title: Vertical coordinate reference systems. was [Missing values in axis elements]

[GoogleCodeExporter]

Issue 13 has been merged into this issue.

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 3:47

[GoogleCodeExporter]

Meant to add this link to oostethys.

http://www.oostethys.org/best-practices/verticalcrs

Original comment by dpsnowde...@gmail.com on 24 Apr 2012 at 3:48

[GoogleCodeExporter]

I'd prefer to keep this in the GML and use a 3D projection such as EPSG:4979.  
This will keep it consistent with the DescribeSensor output at the sensor level.

<om:featureOfInterest>
  <gml:FeatureCollection>
    ...
    <gml:location>
      <gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4979">
        <gml:pos>30.04 -80.55 183</gml:pos>
      </gml:Point>
    </gml:location>
  </gml:FeatureCollection>
</om:featureOfInterest>

Original comment by wilcox.k...@gmail.com on 5 Jun 2012 at 6:00

[GoogleCodeExporter]

Keeping location in GML with a 3D projection as Kyle suggests seems like a sane 
and concise solution. We still need to address the degenerate trajectory case, 
though, and how to represent height above surface. Mike's approach in comment 5 
seems like a good approach there.

My additional question: in cases where the sensor is stationary can we pull 
height above surface out of the result block and represent it in the overhead 
metadata? Or maybe it should just be left in the DescribeSensor sml?

Original comment by sh...@axiomalaska.com on 8 Jun 2012 at 4:14

[GoogleCodeExporter]

I think we're coming to a solution and it looks like a combination of Mike (5) 
and Kyle (9). Here are two proposals.

I'm not sure I understand Kyle's comment about being consistent with the 
DescribeSensor.  See 
https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/DS
-Station-timeSeries.xml#218 for a discussion on only using lat/lon, not z in 
the station position description.  I think the rationale may have had something 
to do with the difficulty of specifying the vertical reference frame in a way 
that would apply to every sensor.  Perhaps we should adopt this initially for 
the om:featureOfInterest block as well???  So, my first recommendation would be 
to go with only lat/lon descriptions of _station_ in the feature of interest.  
This gives us some flexibility and prevents us from misusing a CRS reference 
inadvertently.  Also, the lat/lon/z information will be repeated in the 
om:result section anyway.  There, the z can be handled independently so that we 
have a correct z axis definition.

-OR-

If we include depth/altitude of the_station_ in the featureOfInterest as 
described in comment 9, then we may need to face the fact that one CRS doesn't 
work for all use cases.  For the case of a moored buoy or shore station I think 
comment 9 and comment 5 work.  We are equating foi with _station_ in our 
current usage and in the reference frame described by epsg 4979 the _station_ 
is at those horizontal coordinates and is 183 meters above the ellipsoid.  In 
4979 the vertical datum is the WGS84 ellipsoid which in my limited 
understanding, seems to be the one most used by GPS devices.  If Mike can 
verify that WGS84 is the ellipsoid that is used in positioning NDBC stations 
then we are OK.  If not, this may be still be good enough for buoys and shore 
stations. WGS-84 is not mean or instantaneous sea level so it doesn't work to 
describe the vertical coordinate of any sensor mounted on a station, especially 
those underwater. 

Also, include the coordinates as swe data elements in the result.  This 
conforms with our conceptual map to the CF feature types.  We just factor them 
out as Mike showed in comment 5.  I think the difference is that we wouldn't 
want to include the station elevation above sea level there, only the sensor 
height.  I think the definition of an anchor point or STATION_FRAME makes that 
explicit.  

This definitely doesn't answer the question on gliders and other mobile 
platforms.  I don't know if we can answer this generally until we have a glider 
template.     

Original comment by dpsnowde...@gmail.com on 3 Jan 2013 at 5:06

[GoogleCodeExporter]

Hi Folks

I have been working on resolving the reference frame problem posed by this 
issue. 

After doing some considerable research I have found a workable solution to 
propose to the group. The discussion above found the correct pieces - the 
EPSG4326 and EPSG 5113 CRS's but what is needed for the SWE Vector 
referenceFrame is a Compound Coordinate Reference System (CCRS) defined in GML. 
This allows the complete specification of a 3D CRS which has WGS 84 as the 
horizontal reference frame for latitude and longitude, and has Instantaneous 
Water Level as the vertical reference:
https://gist.github.com/dstuebe/4771961#file-go-station-singleft-timeseries-mult
isensor-xml-L149

With that reference frame, defining the Location Vector for the platform 
becomes straightforward:
https://gist.github.com/dstuebe/4771961#file-go-station-singleft-timeseries-mult
isensor-xml-L189

While it is possible to use the SWE LocalFrame to define a complete reference 
frame for each sensor, I don't think that is necessary or advisable for IOOS 
buoy data. Just specifying a height or depth with the sensor observations 
should be sufficient.
https://gist.github.com/dstuebe/4771961#file-go-station-singleft-timeseries-mult
isensor-xml-L247

This approach should be easily extensible to other features types like 
trajectories for moving platforms which are referenced to water level. It would 
even be possible to define pressure coordinates in a rigorous manner. 

Please comment on the proposed ObservationCollection in the gist links. If no 
one has registered further suggestions or complaints by next week I will close 
the issue and make all the other location elements consistent with this 
solution.

Regarding the original question: 
"Are missing values allowed in coordinate axis definitions?"

The use case described (missing coordinates because the vertical axis is 
undefined) is no longer relevant, however missing coordinates in other contexts 
may still arise. I suggest we close this issue and open a new more specific 
question when we find such a case.

Here are links to some of the reading I did during my research:
GML 3.2.1 Spec: 
https://www.dropbox.com/s/uxibxsucezqjccy/07-036_Geography_Markup_Language_GML_V
3.2.1.pdf
SWE Common Spec: 
https://www.dropbox.com/s/rhd90bzbfb8imd9/08-094r1_SWE_Common_Data_Model_2.0_Sub
mission_Package.pdf
EPSG User Guide: https://www.dropbox.com/s/77tnbjeancvz4xo/epsg_user_guide.pdf

David

Original comment by stu3b3 on 12 Feb 2013 at 8:02

[GoogleCodeExporter]

Hi David,

Thanks for this thorough work.  I think we're ready to move beyond this very 
soon.  One question comes to mind.  Is it implied that the PlatformFrame forms 
a right handed coordinate frame?  In the sensor data you wrote z=5 for the air 
temperature sensor but I didn't see any place where poitive 5 is defined to be 
up.  If it is the case that a right handed coordinate system is the default, is 
there a place to over ride this as is done in CF  with the positive_direction 
attribute?  With the vast majority o our data being underwater it seems more 
convenient to be able to define a convention so that we can encode depths with 
positive values.  

Maybe it is as simple as using 

                        <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/depth" referenceFrame="#PlatformFrame">

                          <swe2:uom code="m"/>

                          <swe2:value>5</swe2:value>

                        </swe2:Quantity>
instead of 
                        <swe2:Quantity definition="http://mmisw.org/ont/cf/parameter/height" referenceFrame="#PlatformFrame">

                          <swe2:uom code="m"/>

                          <swe2:value>5</swe2:value>

                        </swe2:Quantity>

That seems a little fragile though.  There is an example of using depth instead 
of height a little further down in the file but that is also encoded as 
positive values.  Does using two different vocabulary terms for defining the 
vertical axis seem difficult or potentially error prone for client developers?

Thanks again.

Derrick

Original comment by dpsnowde...@gmail.com on 13 Feb 2013 at 8:19

[GoogleCodeExporter]

http://mmisw.org/ont/cf/parameter/depth is defined as distance below the surface
http://mmisw.org/ont/cf/parameter/height is defined as distance above the 
surface

I searched for a term that would account for positive above surface and 
negative below surface... but I came up with nothing.  I think we have to use 
both, depending on where the sensor/station is.  'height' is positive up and 
'depth' is positive down.

Original comment by wilcox.k...@gmail.com on 13 Feb 2013 at 8:29

[GoogleCodeExporter]

How about just using one vertical axis (height or depth but not both) and the 
sensors above (or below) the surface are just encoded with negative values?  It 
seems fragile to have the client responsible for determining the semantics of 
the axis vocabulary.  Maybe there is no other way.

Original comment by dpsnowde...@gmail.com on 13 Feb 2013 at 9:11

[GoogleCodeExporter]

+1 for Derrick's suggestion. 
That was my thought exactly. The CF standard name definitions for height and 
depth don't seem to preclude negative values; I interpret them as establishing 
the orientation of the z axis.
It's also easier from a client perspective to deal with a single vertical axis 
type.

Original comment by emilioma...@gmail.com on 13 Feb 2013 at 9:16

[GoogleCodeExporter]

I think that the David’s suggestion looks great, and I fully support it with 
Derrick’s refinement of the height/depth use case. Couple of comments to 
David’s XML:

1. The use of “#” in front of the names is inconsistent - 
“IOOS_Buoy_CRS” vs. “#IOOS_Buoy_CRS”. On the other hand, 
"#PlatformFrame" seems OK. 
2. The “Coordinate Reference System Definition - Recommended Practice” at 
http://www.ihsenergy.com/epsg/guid5.pdf and OGC 05-011 “Recommended XML/GML 
3.1.1 encoding of common CRS definitions” at 
http://portal.opengeospatial.org/files/?artifact_id=8837 contain a lot to read 
on the CRS types and encodings. The OGC 05-011 is actually a package that 
includes also UML diagrams, schemas and encoding samples.
Although the OGC 05-011 was deprecated, and its content was covered (in full??) 
by the OGC 08-015r2 “The OpenGIS® Abstract Specification Topic 2: Spatial 
referencing by coordinates” and OGC GML v3.2.1 Encoding Standard, it still is 
a very good reading anyway because it was written for GML 3.1.1 (which is in 
use for Milestone 1.0), and it has a lot of info in one place.

Original comment by abir...@gmail.com on 13 Feb 2013 at 10:22

[GoogleCodeExporter]

Just for reference, to go back to Derrick's Comment #11 discussion on the 
om:featureOfInterest block in the GetObs template: Yes, going with "only 
lat/long descriptions of _station_ in the feature of interest" was exactly the 
intent, and resulted from some discussions last year (I think there's an issue 
and/or list thread out there that discusses this, but I didn't look). That was 
done precisely b/c, to again borrow Derrick's words, "This gives us some 
flexibility [....]  Also, the lat/lon/z information will be repeated in the 
om:result section anyway.  There, the z can be handled independently so that we 
have a correct z axis definition." The goal then was to let 
om:featureOfInterest serve as a broader description of *planar* (X-Y) station 
location (or multi-station locations, in the case of a Network procedure), a 
kind of high-level metadata; the detailed and specific reference frame 
information is left to om:result, which is able to be sensor-specific.

Original comment by emilioma...@gmail.com on 14 Feb 2013 at 9:03

[GoogleCodeExporter]

Original comment by dpsnowde...@gmail.com on 19 Feb 2013 at 7:43

[GoogleCodeExporter]

Many thanks to Alex Birger for finding the existing Vertical CRS.

An example SWE response with discussion of the application of the CRS can be 
found here:
https://code.google.com/p/ioostech/source/browse/trunk/templates/Milestone1.0/SW
E-SingleStation-TimeSeries-SingleSensor.xml

It references the IOOS Buoy CRS which is defined here:
https://code.google.com/p/ioostech/source/browse/trunk/IoosCRS/IoosBuoyCRS.xml

Currently hosted form this google code repository, this should eventually be 
moved to a more appropriate repository. 

Original comment by stu3b3 on 1 Mar 2013 at 3:55

[GoogleCodeExporter]

Need to wrap this up this week for Milestone 1.0

Please make comments by close of business Thursday. 
We will be finalizing the draft templates for Milestone 1.0 on Friday unless 
someone asks to stop the presses.

David

Original comment by stu3b3 on 4 Mar 2013 at 6:31

[GoogleCodeExporter]

Closing this issue. Thanks everyone.

Original comment by stu3b3 on 11 Mar 2013 at 1:39

• Changed state: Fixed