Folks,
I'd like to see if we can move forward on concrete proposal for how to
handle vertical coordinate systems. Maybe we could mimic how ESRI,
probably the largest vendor of geospatial software does it:
(lifted from
http://resources.arcgis.com/en/help/main/10.1/index.html#//003r00000015000000)
---------------------------------------begin esri
text---------------------------
A gravity-related VCS will include a vertical datum as part of its
definition. An example is shown below:
VERTCS["National_Geodetic_Vertical_Datum_1929",VDATUM["NGVD_1929"],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0],UNIT["Meter",1.0]]
A spheroidal VCS defines heights that are referenced to a spheroid of
a geographic coordinate system. A Global Positioning System (GPS) unit
natively reports heights relative to the World Geodetic System of 1984
(WGS84) ellipsoid. An onboard geoid model (discussed below) in the GPS
unit converts the ellipsoidal heights to gravity-related elevations. A
spheroidal height is a geometry quantity and does not have a physical
sense, as a geographic coordinate system's spheroid may fall above or
below the actual earth surface. Spheroidal heights for an area may not
reflect movement due to gravity, that is, the flow of water. Water can
run uphill when working with spheroidal heights.
A VCS with heights or depths that are referenced to the spheroid will
include a datum, rather than a vertical datum, definition. An example
is shown below:
VERTCS["WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0],UNIT["Meter",1.0]]
-------------------------------------end of esri
text-----------------------------
In CF, we have some of these parameters of the vertical coordinate
system specified with the "units" and "positive" attributes. And we
already have "add_offset" that could be used for the vertical shift.
So that just leaves the geoid-based "Vertical Datum" or spheroid-based
"Datum", where the spheroid can be specified with parameters.
Jonathan, would this address your concerns?
Thanks,
Rich
On Wed, Feb 19, 2014 at 4:16 AM, Jonathan Gregory
<j.m.gregory at reading.ac.uk> wrote:
> Dear John and Jim
>
> Thanks for your comments. John, I agree with your classification. I think the
> concepts to which we give standard names are really quite simple. They are
> distances above or below a reference surface (i.e. a surface which is a 2D
> function of geographical position). The distance is signed and we consistently
> use "height" to mean positive up and "depth" to mean positive down. It appears
> from Jim's email that orthometric, geodetic and geometric indicate which
> reference surface is being used. Hence we don't need those words, because
> they are redundant if we say explicitly which surface is being used. I think it
> is better to be explicit because it's more self-describing, which is a
> principle of CF metadata. However, it would be useful to mention these words in
> the definitions of the standard names as additional information to relate the
> standard names to other terminology.
>
> Therefore I don't think there is anything incorrect in the existing standard
> names, actually. However if they are potentially misleading (in case users
> don't read the definitions) we can consider clarifying them. That's what I
> meant in my previous email. In particular, we could rename altitude as
> height_above_geoid, using aliases. There are 14 standard names which use the
> word altitude, all meaning height_above_geoid. Is that worth doing or not?
>
> My own opinion is that there is no need to rename plain "height" or "depth"
> (without "above_X" or "below_X") which are defined to mean relative to the
> surface. There is also no need to rename plain "surface" i.e. the bottom of the
> atmosphere, which is used in dozens or hundreds of existing standard names in
> that sense.
>
>> in answer to your question about geoids, WKT has a clause ?VERT_CS? where a vertical datum is defined. A geoid is, in most cases, realized as a lat/lon grid in one or more files (often tiled), and is only identified by name.
>
> Thanks. Yes, I appreciate it can only be identified by name, because it is
> a non-mathematical 2D dataset, unlike the ellipsoid, which is a 2D function of
> position specified by a couple of parameters. So your answer suggests that
> WKT does not indicate whether the vertical datum includes a geoid definition or
> not. Is that right? It just gives a name, and the user or the software has to
> know whether this name implies a particular geoid, or is only a reference
> ellipsoid. Correct?
>
> Best wishes and thanks
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
Received on Tue Mar 11 2014 - 06:12:09 GMT
