Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Jonathan,

Quite right.  Even longitude and latitude depend on the choice of datum, 
whether that be an ellipsoid or a geoid.

To add to the fun, you can have mixed mode coordinates, where the horizontal 
coordinates use one datum, and the vertical uses another (an extreme example is 
instantaneous water surface, where the vertical datum has no fixed relationship 
to the body of the Earth at all!)

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Mar 17, 2014, at 12:39 PM, Jonathan Gregory  
wrote:

> Dear Jim
> 
> Yes, I suppose you're right, on reflection. I was thinking of a situation in
> which you were interested in the ellipsoid only for the sake of a vertical
> datum, rather than as a horizontal datum (which is its usual purpose in
> grid_mapping). However, I now understand from the discussion and explanations
> from Jon Blower why you cannot actually refer heights to a vertical datum
> without implying a particular latitude-longitude coordinate system. So the
> existing grid_mapping_name of latitude_longitude will be appropriate if you
> want to identify the geoid or ellipsoid as a vertical datum, I agree.
> 
> My understanding is now that the height is taken perpendicular to the surface,
> and the lat-lon is defined on the surface, so the lat-lon of the point whose
> height is being measured depends on the choice of surface. Please correct me
> if that's not right.
> 
> Cheers
> 
> Jonathan
> 
>> I thought this was already defined.  In the second paragraph of section 5.6, 
>> it says that if you aren?t specifying a projected coordinate system (or, I 
>> assume, a Cartesian coordinate system such as ECF), then use the name 
>> ?latitude_longitude?.  I haven?t noticed anything we?ve talked about that 
>> would invalidate this usage.  We are talking about adding vertical datum 
>> specifications and such as further attributes to the variable, but even 
>> latitude and longitude values can shift depending on the ellipsoid and/or 
>> geoid being used, so these should specified even when there is no projected 
>> coordinate system.
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Jim

Yes, I suppose you're right, on reflection. I was thinking of a situation in
which you were interested in the ellipsoid only for the sake of a vertical
datum, rather than as a horizontal datum (which is its usual purpose in
grid_mapping). However, I now understand from the discussion and explanations
from Jon Blower why you cannot actually refer heights to a vertical datum
without implying a particular latitude-longitude coordinate system. So the
existing grid_mapping_name of latitude_longitude will be appropriate if you
want to identify the geoid or ellipsoid as a vertical datum, I agree.

My understanding is now that the height is taken perpendicular to the surface,
and the lat-lon is defined on the surface, so the lat-lon of the point whose
height is being measured depends on the choice of surface. Please correct me
if that's not right.

Cheers

Jonathan

> I thought this was already defined.  In the second paragraph of section 5.6, 
> it says that if you aren?t specifying a projected coordinate system (or, I 
> assume, a Cartesian coordinate system such as ECF), then use the name 
> ?latitude_longitude?.  I haven?t noticed anything we?ve talked about that 
> would invalidate this usage.  We are talking about adding vertical datum 
> specifications and such as further attributes to the variable, but even 
> latitude and longitude values can shift depending on the ellipsoid and/or 
> geoid being used, so these should specified even when there is no projected 
> coordinate system.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Hedley, Mark]

I agree; I don't see a need for a 'null'

I think the currently available grid mapping types will be fit for the vertical 
datum purposes so far discussed

mark


From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Jim Biard 
[jbi...@cicsnc.org]
Sent: 14 March 2014 19:12
To: CF metadata
Subject: Re: [CF-metadata] Vertical datums (again)

Jonathan,

I thought this was already defined.  In the second paragraph of section 5.6, it 
says that if you aren’t specifying a projected coordinate system (or, I assume, 
a Cartesian coordinate system such as ECF), then use the name 
“latitude_longitude”.  I haven’t noticed anything we’ve talked about that would 
invalidate this usage.  We are talking about adding vertical datum 
specifications and such as further attributes to the variable, but even 
latitude and longitude values can shift depending on the ellipsoid and/or geoid 
being used, so these should specified even when there is no projected 
coordinate system.

Is there something I’m missing?

Grace and peace,

Jim

<http://www.cicsnc.org/>Visit us on
Facebook<http://www.facebook.com/cicsnc>Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC<http://cicsnc.org/>
North Carolina State University<http://ncsu.edu/>
NOAA's National Climatic Data Center<http://ncdc.noaa.gov/>
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org<mailto:jbi...@cicsnc.org>
o: +1 828 271 4900





On Mar 14, 2014, at 2:21 PM, Jonathan Gregory 
mailto:j.m.greg...@reading.ac.uk>> wrote:

Dear Jim

Given what you say, what would you suggest for the grid_mapping_name when the
grid_mapping supplies only the figure of the Earth and does not specify any
transformation of coordinate systems?

I agree that grid_mapping is itself an unsatisfactory name, which reflects
the purpose we had in mind when it was first introduced, subsequently
generalised. In the data model we can (and indeed we propose to) call it
something else. We could change its name in the convention but we'd have to
retain the old one too for backward compatibility, I'd argue, and I would
feel it's not worth the effort. It's more important to describe clearly what
it does in principle.

Best wishes and thanks

Jonathan


- Forwarded message from Jim Biard 
mailto:jbi...@cicsnc.org>> -

The contents of the grid_mapping variable are doing as much mapping when 
specifying a projected coordinate system as they are when specifying a 
geographic (i.e., lon/lat) coordinate system.  It is telling you how to 
understand the spatial coordinate information, particularly in relation to any 
other choice of coordinate system.  It has an unfortunate name, in that it 
leads us to think about it as ?the thing that tells me how I got from my X & Y 
coordinate variables to my lon & lat grids?.  When you have both X/Y 
coordinates and lon/lat auxiliary coordinates, the grid_mapping variable is 
actually telling you how to understand both.  There is really no such thing as 
a ?null mapping?.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Jonathan,

I thought this was already defined.  In the second paragraph of section 5.6, it 
says that if you aren’t specifying a projected coordinate system (or, I assume, 
a Cartesian coordinate system such as ECF), then use the name 
“latitude_longitude”.  I haven’t noticed anything we’ve talked about that would 
invalidate this usage.  We are talking about adding vertical datum 
specifications and such as further attributes to the variable, but even 
latitude and longitude values can shift depending on the ellipsoid and/or geoid 
being used, so these should specified even when there is no projected 
coordinate system.

Is there something I’m missing?

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Mar 14, 2014, at 2:21 PM, Jonathan Gregory  wrote:

> Dear Jim
> 
> Given what you say, what would you suggest for the grid_mapping_name when the
> grid_mapping supplies only the figure of the Earth and does not specify any
> transformation of coordinate systems?
> 
> I agree that grid_mapping is itself an unsatisfactory name, which reflects
> the purpose we had in mind when it was first introduced, subsequently
> generalised. In the data model we can (and indeed we propose to) call it
> something else. We could change its name in the convention but we'd have to
> retain the old one too for backward compatibility, I'd argue, and I would
> feel it's not worth the effort. It's more important to describe clearly what
> it does in principle.
> 
> Best wishes and thanks
> 
> Jonathan
> 
> 
> - Forwarded message from Jim Biard  -
> 
>> The contents of the grid_mapping variable are doing as much mapping when 
>> specifying a projected coordinate system as they are when specifying a 
>> geographic (i.e., lon/lat) coordinate system.  It is telling you how to 
>> understand the spatial coordinate information, particularly in relation to 
>> any other choice of coordinate system.  It has an unfortunate name, in that 
>> it leads us to think about it as ?the thing that tells me how I got from my 
>> X & Y coordinate variables to my lon & lat grids?.  When you have both X/Y 
>> coordinates and lon/lat auxiliary coordinates, the grid_mapping variable is 
>> actually telling you how to understand both.  There is really no such thing 
>> as a ?null mapping?.
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Jim

Given what you say, what would you suggest for the grid_mapping_name when the
grid_mapping supplies only the figure of the Earth and does not specify any
transformation of coordinate systems?

I agree that grid_mapping is itself an unsatisfactory name, which reflects
the purpose we had in mind when it was first introduced, subsequently
generalised. In the data model we can (and indeed we propose to) call it
something else. We could change its name in the convention but we'd have to
retain the old one too for backward compatibility, I'd argue, and I would
feel it's not worth the effort. It's more important to describe clearly what
it does in principle.

Best wishes and thanks

Jonathan


- Forwarded message from Jim Biard  -

> The contents of the grid_mapping variable are doing as much mapping when 
> specifying a projected coordinate system as they are when specifying a 
> geographic (i.e., lon/lat) coordinate system.  It is telling you how to 
> understand the spatial coordinate information, particularly in relation to 
> any other choice of coordinate system.  It has an unfortunate name, in that 
> it leads us to think about it as ?the thing that tells me how I got from my X 
> & Y coordinate variables to my lon & lat grids?.  When you have both X/Y 
> coordinates and lon/lat auxiliary coordinates, the grid_mapping variable is 
> actually telling you how to understand both.  There is really no such thing 
> as a ?null mapping?.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

The contents of the grid_mapping variable are doing as much mapping when 
specifying a projected coordinate system as they are when specifying a 
geographic (i.e., lon/lat) coordinate system.  It is telling you how to 
understand the spatial coordinate information, particularly in relation to any 
other choice of coordinate system.  It has an unfortunate name, in that it 
leads us to think about it as “the thing that tells me how I got from my X & Y 
coordinate variables to my lon & lat grids”.  When you have both X/Y 
coordinates and lon/lat auxiliary coordinates, the grid_mapping variable is 
actually telling you how to understand both.  There is really no such thing as 
a “null mapping”.

Grace and peace,

Jim 

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Mar 14, 2014, at 8:25 AM, David Hassell  wrote:

> Dear Jonathan,
> 
> I like the idea of name for a grid mapping that doesn't actually map,
> but suggest a name of "null_mapping" (instead of "null") to better
> indicate to humans that whilst the variable is not mapping, it is
> doing something.
> 
> All the best,
> 
> David
> 
>  Original message from Jonathan Gregory (02PM 11 Mar 14)
> 
>> Date: Tue, 11 Mar 2014 14:29:25 +
>> From: Jonathan Gregory 
>> To: cf-metadata@cgd.ucar.edu
>> User-Agent: Mutt/1.5.21 (2010-09-15)
>> Subject: Re: [CF-metadata] Vertical datums (again)
>> 
>> Dear David
>> 
>>> I'm a bit confused as to the use of these grid_mapping parameters with
>>> vertical coordinates - do we need new grid_mapping_names? I'm
>>> thinking, for example, of linking a geoid specification to a vertical
>>> "altitude" coordinate.
>> 
>> That's a good point, thanks. I was thinking of the grid_mapping as a place to
>> record the reference surface in the same way as it does for 
>> latitude_longitude,
>> which was added as a "null" horizontal mapping. No "mapping" is required for
>> the vertical coordinate; it just needs its reference surface (vertical datum)
>> to be more precisely specified than its geophysical description of "geoid" or
>> "reference_ellipsoid" alone, for some applications.
>> 
>> I'd like to suggest we add a new grid_mapping_name of "null" to Appendix F,
>> thus: "This grid_mapping does not imply any mapping of horizontal or vertical
>> coordinates. Its purpose is to describe the reference ellipsoid or the 
>> geoid."
>> No map parameters, no map coordinates.
>> 
>> I would further suggest that we make latitude_longitude an alias for null.
>> 
>> It might happen that a different reference ellipsoid is required for vertical
>> and horizontal coordinates. Thanks to Mark's accepted ticket 70, this will be
>> no problem; it allows there to be more than one grid_mapping, and the
>> grid_mapping attribute indicates which coordinate variable each is relevant 
>> to.
>> 
>> Best wishes
>> 
>> Jonathan
>> ___
>> CF-metadata mailing list
>> CF-metadata@cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> 
> 
> --
> David Hassell
> National Centre for Atmospheric Science (NCAS)
> Department of Meteorology, University of Reading,
> Earley Gate, PO Box 243,
> Reading RG6 6BB, U.K.
> 
> Tel   : +44 118 3785613
> E-mail: d.c.hass...@reading.ac.uk
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[David Hassell]

Dear Jonathan,

I like the idea of name for a grid mapping that doesn't actually map,
but suggest a name of "null_mapping" (instead of "null") to better
indicate to humans that whilst the variable is not mapping, it is
doing something.

All the best,

David

 Original message from Jonathan Gregory (02PM 11 Mar 14)

> Date: Tue, 11 Mar 2014 14:29:25 +
> From: Jonathan Gregory 
> To: cf-metadata@cgd.ucar.edu
> User-Agent: Mutt/1.5.21 (2010-09-15)
> Subject: Re: [CF-metadata] Vertical datums (again)
> 
> Dear David
> 
> > I'm a bit confused as to the use of these grid_mapping parameters with
> > vertical coordinates - do we need new grid_mapping_names? I'm
> > thinking, for example, of linking a geoid specification to a vertical
> > "altitude" coordinate.
> 
> That's a good point, thanks. I was thinking of the grid_mapping as a place to
> record the reference surface in the same way as it does for 
> latitude_longitude,
> which was added as a "null" horizontal mapping. No "mapping" is required for
> the vertical coordinate; it just needs its reference surface (vertical datum)
> to be more precisely specified than its geophysical description of "geoid" or
> "reference_ellipsoid" alone, for some applications.
> 
> I'd like to suggest we add a new grid_mapping_name of "null" to Appendix F,
> thus: "This grid_mapping does not imply any mapping of horizontal or vertical
> coordinates. Its purpose is to describe the reference ellipsoid or the geoid."
> No map parameters, no map coordinates.
> 
> I would further suggest that we make latitude_longitude an alias for null.
> 
> It might happen that a different reference ellipsoid is required for vertical
> and horizontal coordinates. Thanks to Mark's accepted ticket 70, this will be
> no problem; it allows there to be more than one grid_mapping, and the
> grid_mapping attribute indicates which coordinate variable each is relevant 
> to.
> 
> Best wishes
> 
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
David Hassell
National Centre for Atmospheric Science (NCAS)
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243,
Reading RG6 6BB, U.K.

Tel   : +44 118 3785613
E-mail: d.c.hass...@reading.ac.uk
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

Regarding how ESRI represents vertical CRSs:

When ESRI specifies a particular vertical datum and doesn’t specify the 
ellipsoid, it is because the specified vertical datum specifies the ellipsoid.  
 The fully realized definition still contains a specification of the ellipsoid 
that the geoid heights were measured against.  I don’t think we should overload 
the add_offset attribute to do anything besides its meaning for rescaling.

I’ll write more on this later, but there’s my quick $0.02 worth.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Mar 11, 2014, at 8:59 AM, Jonathan Gregory  wrote:

> Dear Rich
> 
> Thanks for keeping this going.
> 
>> 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.
> 
> In the agreed trac ticket 80
> https://cf-pcmdi.llnl.gov/trac/ticket/80
> we added several more attributes to grid mapping to describe reference
> surfaces in ways analogous to CRS WKT. We already have attributes to name
> and specify the reference ellipsoid (spheroid). As far as I can see, we need
> only to add an attribute of geoid_name to Appendix F to identify the geoid.
> Would that meet your requirement? Earlier discussions implied that CRS WKT
> does not have a way to name the geoid specifically.
> 
> Best wishes
> 
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear David

> I'm a bit confused as to the use of these grid_mapping parameters with
> vertical coordinates - do we need new grid_mapping_names? I'm
> thinking, for example, of linking a geoid specification to a vertical
> "altitude" coordinate.

That's a good point, thanks. I was thinking of the grid_mapping as a place to
record the reference surface in the same way as it does for latitude_longitude,
which was added as a "null" horizontal mapping. No "mapping" is required for
the vertical coordinate; it just needs its reference surface (vertical datum)
to be more precisely specified than its geophysical description of "geoid" or
"reference_ellipsoid" alone, for some applications.

I'd like to suggest we add a new grid_mapping_name of "null" to Appendix F,
thus: "This grid_mapping does not imply any mapping of horizontal or vertical
coordinates. Its purpose is to describe the reference ellipsoid or the geoid."
No map parameters, no map coordinates.

I would further suggest that we make latitude_longitude an alias for null.

It might happen that a different reference ellipsoid is required for vertical
and horizontal coordinates. Thanks to Mark's accepted ticket 70, this will be
no problem; it allows there to be more than one grid_mapping, and the
grid_mapping attribute indicates which coordinate variable each is relevant to.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[David Hassell]

Hello,

(Apologies if this has been covered way back in the e-mail traffic, or
I've misuderstood.)

I'm a bit confused as to the use of these grid_mapping parameters with
vertical coordinates - do we need new grid_mapping_names? I'm
thinking, for example, of linking a geoid specification to a vertical
"altitude" coordinate.

Thanks,

David

 Original message from Jonathan Gregory (12PM 11 Mar 14)

> Date: Tue, 11 Mar 2014 12:59:21 +
> From: Jonathan Gregory 
> To: cf-metadata@cgd.ucar.edu
> User-Agent: Mutt/1.5.21 (2010-09-15)
> Subject: Re: [CF-metadata] Vertical datums (again)
> 
> Dear Rich
> 
> Thanks for keeping this going.
> 
> > 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.
> 
> In the agreed trac ticket 80
> https://cf-pcmdi.llnl.gov/trac/ticket/80
> we added several more attributes to grid mapping to describe reference
> surfaces in ways analogous to CRS WKT. We already have attributes to name
> and specify the reference ellipsoid (spheroid). As far as I can see, we need
> only to add an attribute of geoid_name to Appendix F to identify the geoid.
> Would that meet your requirement? Earlier discussions implied that CRS WKT
> does not have a way to name the geoid specifically.
> 
> Best wishes
> 
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


--
David Hassell
National Centre for Atmospheric Science (NCAS)
Department of Meteorology, University of Reading,
Earley Gate, PO Box 243,
Reading RG6 6BB, U.K.

Tel   : +44 118 3785613
E-mail: d.c.hass...@reading.ac.uk
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Rich

Thanks for keeping this going.

> 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.

In the agreed trac ticket 80
https://cf-pcmdi.llnl.gov/trac/ticket/80
we added several more attributes to grid mapping to describe reference
surfaces in ways analogous to CRS WKT. We already have attributes to name
and specify the reference ellipsoid (spheroid). As far as I can see, we need
only to add an attribute of geoid_name to Appendix F to identify the geoid.
Would that meet your requirement? Earlier discussions implied that CRS WKT
does not have a way to name the geoid specifically.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Signell, Richard]

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#//003r001500)

---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
 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@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
___

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Helen

Thanks for your comments.

> Whilst it is true that the specifics of the geoid used (model, degree and 
> order of expansion etc) are important, simply being able to correctly 
> identify 'sea surface height above reference ellipsoid'  vs 'sea surface 
> height above geoid' gives us fundamentally different parameters (first is 
> approx = geoid height, second is dynamic topography)
> Hence even without the details of the geoid used, the very definition is 
> extremely important

That's good to know because it is consistent with the current approach in the
CF standard name table.

> There is a significant difference in that altitude is generally applied to 
> the height of the satellite above the reference ellipsoid - not the geoid - 
> so I would not like to see that alias be included.

Right. That is useful to know. It is a good argument for replacing altitude
with height_above_geoid (retaining altitude as an alias for the sake of
existing data) if it could be confused with height_above_reference_ellipsoid
(which is an existing standard name).

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Snaith, Helen M.]

Just a quick interjection from a primarily altimetric background.

These definitions seem to fit well with requirements for satellite altimetry 
measurements.

Whilst it is true that the specifics of the geoid used (model, degree and order 
of expansion etc) are important, simply being able to correctly identify 'sea 
surface height above reference ellipsoid'  vs 'sea surface height above geoid' 
gives us fundamentally different parameters (first is approx = geoid height, 
second is dynamic topography)

Hence even without the details of the geoid used, the very definition is 
extremely important

There is a significant difference in that altitude is generally applied to the 
height of the satellite above the reference ellipsoid - not the geoid - so I 
would not like to see that alias be included.

Helen

On 17 Feb 2014, at 21:10, John Graybeal 
mailto:john.grayb...@marinexplore.com>> wrote:

Simple terms like height, depth, and altitude are great for onboarding -- 
though complicated usage ('geoid must always be defined in the grid_mapping'), 
lessens the onboarding benefit. And if they are ambiguous, the long-term 
usability is affected. (See: sea_surface_temperature.)

I want a consistent approach that starts simple -- e.g., 'altitude' is an alias 
for geodetic distance above geoid, and if no particular geoid is specified, a 
default is assumed, perhaps carrying along explicit assumptions about the 
possible error bounds.

The basic concepts discussed so far seem to break down as:
  distance_[above | below]_[surface | geoid | ellipsoid | center],   # 
'distance' avoids loaded terms altitude, depth, etc.
with the possibility of a prefix like
 orthometric | geodetic | geocentric | geometric
and the need or possibility to specify additional parameters for at least some 
of these choices (ex: surface may default to the bottom of the atmosphere, but 
could be defined using any of the Sample Dimensions in the MetOcean graphic 
[1]).

It would be really useful if anyone could explain how the geoid is identified 
in CRS WKT.


Do you mean 'identified' or 'specified'? From Dru Smith's 1998 paper [2] -- it 
didn't look like an 'identifier' would be sufficient any time soon, or do we 
already have controlled terms for the various 'geoid candidates' that are out 
there?  (Note for non-experts like me: I found that Wikipedia's simple and 
specific definitions [3] bypass the problem of defining where 'the geoid' 
actually is.) It's hard to imagine that CF users will be in a position to 
provide those geoidal identification or specification details, though

John

[1] 
http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206
[2] http://www.ngs.noaa.gov/PUBS_LIB/EGM96_GEOID_PAPER/egm96_geoid_paper.html
[3] http://en.wikipedia.org/wiki/Geoid, 
http://en.wikipedia.org/wiki/Physical_geodesy

On Feb 17, 2014, at 09:50, Jonathan Gregory 
mailto:j.m.greg...@reading.ac.uk>> wrote:

Dear all

Thank you for clarifications and further information.

We used "altitude" for "height above geoid" because that's what it most
commonly means, I think. However, it's unclear. To avoid confusion, we could
rename altitude as height_above_geoid, using aliases. There are 14 standard
names which use the word altitude. Would that be worth doing?

Similarly, we could rename plain "height" as height_above_surface. There are
about 5 standard names which would be affected. Likewise (and relating also to
another thread), we could rename plain "depth" as depth_below_surface. There
are about 14 standard names using this word in that sense. Is this worthwhile,
or shall we continue with short words and rely on the definitions? Opinions
would be welcome.

It would be really useful if anyone could explain how the geoid is identified
in CRS WKT.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



This message (and any attachments) is for the recipient only. NERC is subject 
to the Freedom of Information Act 2000 and the contents of this email and any 
reply you make may be disclosed by NERC unless it is exempt from release under 
the Act. Any material supplied to NERC may be stored in an electronic records 
management system.
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Signell, Richard]

Although we've got plenty of food for thought already, here's an extra
helping:

How ESRI (arguably the largest purveyor of geospatial software, e.g. 10,000
users at their annual conference) handles vertical datums:
http://resources.arcgis.com/en/help/main/10.1/index.html#//003r001500

http://edndoc.esri.com/arcsde/9.3/api/japi/docs/com/esri/sde/sdk/pe/PeVertCS.html

-Rich


On Mon, Feb 17, 2014 at 4:10 PM, John Graybeal <
john.grayb...@marinexplore.com> wrote:

> Simple terms like height, depth, and altitude are great for onboarding --
> though complicated usage ('geoid must always be defined in the
> grid_mapping'), lessens the onboarding benefit. And if they are ambiguous,
> the long-term usability is affected. (See: sea_surface_temperature.)
>
> I want a consistent approach that starts simple -- e.g., 'altitude' is an
> alias for geodetic distance above geoid, and if no particular geoid is
> specified, a default is assumed, perhaps carrying along explicit
> assumptions about the possible error bounds.
>
> The basic concepts discussed so far seem to break down as:
>distance_[above | below]_[surface | geoid | ellipsoid | center],   #
> 'distance' avoids loaded terms altitude, depth, etc.
> with the possibility of a prefix like
>   orthometric | geodetic | geocentric | geometric
> and the need or possibility to specify additional parameters for at least
> some of these choices (ex: surface may default to the bottom of the
> atmosphere, but could be defined using any of the Sample Dimensions in the
> MetOcean graphic [1]).
>
> > It would be really useful if anyone could explain how the geoid is
> identified in CRS WKT.
>
>
> Do you mean 'identified' or 'specified'? From Dru Smith's 1998 paper [2]
> -- it didn't look like an 'identifier' would be sufficient any time soon,
> or do we already have controlled terms for the various 'geoid candidates'
> that are out there?  (Note for non-experts like me: I found that
> Wikipedia's simple and specific definitions [3] bypass the problem of
> defining where 'the geoid' actually is.) It's hard to imagine that CF users
> will be in a position to provide those geoidal identification or
> specification details, though
>
> John
>
> [1]
> http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206
> [2]
> http://www.ngs.noaa.gov/PUBS_LIB/EGM96_GEOID_PAPER/egm96_geoid_paper.html
> [3] http://en.wikipedia.org/wiki/Geoid,
> http://en.wikipedia.org/wiki/Physical_geodesy
>
> On Feb 17, 2014, at 09:50, Jonathan Gregory 
> wrote:
>
> > Dear all
> >
> > Thank you for clarifications and further information.
> >
> > We used "altitude" for "height above geoid" because that's what it most
> > commonly means, I think. However, it's unclear. To avoid confusion, we
> could
> > rename altitude as height_above_geoid, using aliases. There are 14
> standard
> > names which use the word altitude. Would that be worth doing?
> >
> > Similarly, we could rename plain "height" as height_above_surface. There
> are
> > about 5 standard names which would be affected. Likewise (and relating
> also to
> > another thread), we could rename plain "depth" as depth_below_surface.
> There
> > are about 14 standard names using this word in that sense. Is this
> worthwhile,
> > or shall we continue with short words and rely on the definitions?
> Opinions
> > would be welcome.
> >
> > It would be really useful if anyone could explain how the geoid is
> identified
> > in CRS WKT.
> >
> > Best wishes
> >
> > Jonathan
> > ___
> > CF-metadata mailing list
> > CF-metadata@cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> ___
> CF-metadata mailing list
> CF-metadata@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
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

John,

I like your idea of using distance to avoid automatic overloading of concepts!  
The problem with defining altitude as being an orthometric distance above the 
geoid is that neither satellite nor GPS vertical coordinates match this 
definition.  Similarly, height as “height above the surface” has an inherent 
problem with regard to CRSs, because none of them define the location of the 
bottom of the atmosphere.  This definition of height forces it to be a relative 
measurement that cannot be connected to a location on the Earth without a 
corresponding measurement of the vertical distance of the surface above/below a 
vertical datum.  Both of these terms are doomed by history to be ambiguous.  We 
can define them to be a particular thing, but existing uses might be in 
conflict with the new definitions.

Back to your suggested name format, I was wondering about the "above | below” 
part.  They look fine to me, but is anyone not OK with the idea that a negative 
distance above is below and vice versa?

Jonathan, 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.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 17, 2014, at 4:10 PM, John Graybeal  
wrote:

> Simple terms like height, depth, and altitude are great for onboarding -- 
> though complicated usage ('geoid must always be defined in the 
> grid_mapping'), lessens the onboarding benefit. And if they are ambiguous, 
> the long-term usability is affected. (See: sea_surface_temperature.)
> 
> I want a consistent approach that starts simple -- e.g., 'altitude' is an 
> alias for geodetic distance above geoid, and if no particular geoid is 
> specified, a default is assumed, perhaps carrying along explicit assumptions 
> about the possible error bounds. 
> 
> The basic concepts discussed so far seem to break down as: 
>   distance_[above | below]_[surface | geoid | ellipsoid | center],   # 
> 'distance' avoids loaded terms altitude, depth, etc.
> with the possibility of a prefix like
>  orthometric | geodetic | geocentric | geometric
> and the need or possibility to specify additional parameters for at least 
> some of these choices (ex: surface may default to the bottom of the 
> atmosphere, but could be defined using any of the Sample Dimensions in the 
> MetOcean graphic [1]).
> 
>> It would be really useful if anyone could explain how the geoid is 
>> identified in CRS WKT.
> 
> 
> Do you mean 'identified' or 'specified'? From Dru Smith's 1998 paper [2] -- 
> it didn't look like an 'identifier' would be sufficient any time soon, or do 
> we already have controlled terms for the various 'geoid candidates' that are 
> out there?  (Note for non-experts like me: I found that Wikipedia's simple 
> and specific definitions [3] bypass the problem of defining where 'the geoid' 
> actually is.) It's hard to imagine that CF users will be in a position to 
> provide those geoidal identification or specification details, though
> 
> John
> 
> [1] 
> http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206
> [2] http://www.ngs.noaa.gov/PUBS_LIB/EGM96_GEOID_PAPER/egm96_geoid_paper.html
> [3] http://en.wikipedia.org/wiki/Geoid, 
> http://en.wikipedia.org/wiki/Physical_geodesy
> 
> On Feb 17, 2014, at 09:50, Jonathan Gregory  wrote:
> 
>> Dear all
>> 
>> Thank you for clarifications and further information.
>> 
>> We used "altitude" for "height above geoid" because that's what it most
>> commonly means, I think. However, it's unclear. To avoid confusion, we could
>> rename altitude as height_above_geoid, using aliases. There are 14 standard
>> names which use the word altitude. Would that be worth doing?
>> 
>> Similarly, we could rename plain "height" as height_above_surface. There are
>> about 5 standard names which would be affected. Likewise (and relating also 
>> to
>> another thread), we could rename plain "depth" as depth_below_surface. There
>> are about 14 standard names using this word in that sense. Is this 
>> worthwhile,
>> or shall we continue with short words and rely on the definitions? Opinions
>> would be welcome.
>> 
>> It would be really useful if anyone could explain how the geoid is identified
>> in CRS WKT.
>> 
>> Best wishes
>> 
>> Jonathan
>> ___
>> CF-metadata mailing list
>> CF-metadata@cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> 
> 
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

__

Re: [CF-metadata] Vertical datums (again)

[John Graybeal]

Simple terms like height, depth, and altitude are great for onboarding -- 
though complicated usage ('geoid must always be defined in the grid_mapping'), 
lessens the onboarding benefit. And if they are ambiguous, the long-term 
usability is affected. (See: sea_surface_temperature.)

I want a consistent approach that starts simple -- e.g., 'altitude' is an alias 
for geodetic distance above geoid, and if no particular geoid is specified, a 
default is assumed, perhaps carrying along explicit assumptions about the 
possible error bounds. 

The basic concepts discussed so far seem to break down as: 
   distance_[above | below]_[surface | geoid | ellipsoid | center],   # 
'distance' avoids loaded terms altitude, depth, etc.
with the possibility of a prefix like
  orthometric | geodetic | geocentric | geometric
and the need or possibility to specify additional parameters for at least some 
of these choices (ex: surface may default to the bottom of the atmosphere, but 
could be defined using any of the Sample Dimensions in the MetOcean graphic 
[1]).

> It would be really useful if anyone could explain how the geoid is identified 
> in CRS WKT.


Do you mean 'identified' or 'specified'? From Dru Smith's 1998 paper [2] -- it 
didn't look like an 'identifier' would be sufficient any time soon, or do we 
already have controlled terms for the various 'geoid candidates' that are out 
there?  (Note for non-experts like me: I found that Wikipedia's simple and 
specific definitions [3] bypass the problem of defining where 'the geoid' 
actually is.) It's hard to imagine that CF users will be in a position to 
provide those geoidal identification or specification details, though

John

[1] 
http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206
[2] http://www.ngs.noaa.gov/PUBS_LIB/EGM96_GEOID_PAPER/egm96_geoid_paper.html
[3] http://en.wikipedia.org/wiki/Geoid, 
http://en.wikipedia.org/wiki/Physical_geodesy

On Feb 17, 2014, at 09:50, Jonathan Gregory  wrote:

> Dear all
> 
> Thank you for clarifications and further information.
> 
> We used "altitude" for "height above geoid" because that's what it most
> commonly means, I think. However, it's unclear. To avoid confusion, we could
> rename altitude as height_above_geoid, using aliases. There are 14 standard
> names which use the word altitude. Would that be worth doing?
> 
> Similarly, we could rename plain "height" as height_above_surface. There are
> about 5 standard names which would be affected. Likewise (and relating also to
> another thread), we could rename plain "depth" as depth_below_surface. There
> are about 14 standard names using this word in that sense. Is this worthwhile,
> or shall we continue with short words and rely on the definitions? Opinions
> would be welcome.
> 
> It would be really useful if anyone could explain how the geoid is identified
> in CRS WKT.
> 
> Best wishes
> 
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Signell, Richard]

It looks like the OGC Met-Ocean Domain Working Group has also been
thinking about this:

http://external.opengeospatial.org/twiki_public/MetOceanDWG/MetOceanWMSBP20120206

This doc is two years old, so I'll ask Jeff DLB if he can summarize
for the list what they came up with.

-Rich

-R

On Mon, Feb 17, 2014 at 12:50 PM, Jonathan Gregory
 wrote:
> Dear all
>
> Thank you for clarifications and further information.
>
> We used "altitude" for "height above geoid" because that's what it most
> commonly means, I think. However, it's unclear. To avoid confusion, we could
> rename altitude as height_above_geoid, using aliases. There are 14 standard
> names which use the word altitude. Would that be worth doing?
>
> Similarly, we could rename plain "height" as height_above_surface. There are
> about 5 standard names which would be affected. Likewise (and relating also to
> another thread), we could rename plain "depth" as depth_below_surface. There
> are about 14 standard names using this word in that sense. Is this worthwhile,
> or shall we continue with short words and rely on the definitions? Opinions
> would be welcome.
>
> It would be really useful if anyone could explain how the geoid is identified
> in CRS WKT.
>
> Best wishes
>
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@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
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear all

Thank you for clarifications and further information.

We used "altitude" for "height above geoid" because that's what it most
commonly means, I think. However, it's unclear. To avoid confusion, we could
rename altitude as height_above_geoid, using aliases. There are 14 standard
names which use the word altitude. Would that be worth doing?

Similarly, we could rename plain "height" as height_above_surface. There are
about 5 standard names which would be affected. Likewise (and relating also to
another thread), we could rename plain "depth" as depth_below_surface. There
are about 14 standard names using this word in that sense. Is this worthwhile,
or shall we continue with short words and rely on the definitions? Opinions
would be welcome.

It would be really useful if anyone could explain how the geoid is identified
in CRS WKT.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Eizi TOYODA]

erent geophysical quantities. Conversion between them is possible
> but
> it is a non-trivial operation involving geophysical data. Similarly
> conversion
> is possible between altitude and geopotential height but they are different
> geophysical quantities with different standard names.
>
> The geoid and reference ellipsoid definition, however, are fine in the grid
> mapping, because they do not define the geophysical quantity. They just
> make
> it numerically precise.
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from Jim Biard  -
>
> From: Jim Biard 
> Date: Tue, 11 Feb 2014 13:51:56 -0500
> To: CF metadata 
> X-Mailer: Apple Mail (2.1827)
> CC: Karl Taylor 
> Subject: Re: [CF-metadata] Vertical datums (again)
>
> Karl,
>
> My point is that putting the reference surface in the standard name
> (potentially) proliferates standard names for things that (like
> temperatures in different units) are not different except for their
> reference frame.  I agree that we don?t want to put the datum information
> in the units, but the place for this sort of information already exists -
> it?s the grid_mapping variable.  We don?t have the appropriate attributes
> defined yet, but that is where the information should go.  The definition
> of the standard name can state a requirement for the information to present
> in a grid_mapping variable.  I thought that the point of standard names was
> to assist in identifying variables that are of the same kind or class, and
> that the goal was to avoid putting implementation details into
> standard_names.  By tacking on CRS details, it seems to me that we are
> moving away from that goal.
>
> Grace and peace,
>
> Jim
>
> Visit us on
> Facebook Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
>
>
>
>
> On Feb 11, 2014, at 1:44 PM, Karl Taylor  wrote:
>
> Hi all,
>
> for temperature, the units imply a zero point, but for height they don't.
>  For time, we specifically include the zero point in the units (e.g., "days
> since 20010101") and we also distinguish among various calendars with the
> "calendar" attribute.  For height I wouldn't advocate that approach, but
> rather the already proposed hybrid approach:  the standard name (roughly)
> specifies the reference surface, which can then be more precisely defined
> in another place (e.g., within the grid_mapping).
>
> best regards,
> Karl
>
>
>
>
> On 2/11/14, 10:05 AM, Jim Biard wrote:
>
> Hi.
>
> It seems to me that tacking on a description of the datum in the standard
> name isn?t a good plan.  It creates a linkage between standard names and
> grid mappings / WKT blocks.  The nature of the height of the sea surface is
> not altered by the choice of datum.  The values will be different,
> depending on what sort of height, but you can (most of the time!) translate
> heights from one CRS to another.  It is definitely more complicated, but
> tacking on a datum description appears to me to be akin to having different
> standard names for ?temperature_in_C? and ?temperature_in_K?.  If you have
> properly specified your CRS, the question of where the zero in your height
> scale is located is completely unambiguous.
>
> Grace and peace,
>
> Jim
>
> Visit us on
> Facebook Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
>
>
>
>
> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory 
> wrote:
>
> Dear Rich
>
> Thanks for the detailed explanation (and analogy) of why it's useful
> to tack on the "_above_geoid" or "_above_ellipsoid" or
> "_above_tidal_datum" to the standard-name.
>
> So we do that and then specify the geoid, ellipsoid or tidal datum
> elsewhere in the grid_mapping variable, right?
>
>
> Yes, that is the way we've been proceeding up to now. In fact we do not
> have
> any stdnames yet referring to tidal datum, but you're welcome to propose
> them
> if they're needed now, of course.
>
> geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
> ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
> tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc
>
>
> Thanks for these useful lists! I would tend to think that we should
> give different standard names for the various different t

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

So, I went through and looked more closely at the standard name table, and I 
have a few comments.  But first, the results of some googling that I did.

When you look at the geodesy literature, there are multiple kinds of heights.  
Geoidal height is the height of a point on a geoid relative to a reference 
ellipsoid.  Geodetic height is the height of a point on the surface relative to 
a reference ellipsoid.  Orthometric height is the height of a point on the 
surface relative to a reference geoid.  Geodesists also use the word elevation 
when referring to geodetic or orthometric heights.  They don’t usually talk 
about heights above the surface, but that’s not their area of interest.  I 
found that in meteorology, geometric height (as opposed to geopotential height) 
appears to be what geodesists call orthometric height, or height relative to a 
geoid.  I also discovered that in aviation, they often use height to mean 
“height above the surface”, and altitude to mean “height above the vertical 
reference”.

In addition to all of the above, I found that there appears to be no consensus 
on specific meanings for height, elevation, and altitude.  Height appears to be 
generally accepted (outside of aviation) as any measure of vertical distance.  
Elevation and altitude both tend to be heights measured relative to a reference 
surface.  Geodesists use the three terms interchangeably.  Because the word 
height does not usually invoke any particular reference frame, it is mostly 
used with qualifiers (orthometric, above sea level, etc).

In CF, the standard name table has defined altitude and height.  Height is 
defined to be "height above the surface”.  Not my preference, but it’s a done 
deal.  Altitude is defined as orthometric height.  It uses the word 
“geometric”, which seems to be the way meteorologists tend to refer to it.  We 
then have a lot of qualified height names, some of which are themselves 
definitions of measures from geodesy, some of which use height in the sense of 
“height above the surface”, and some of which use height in the sense of 
“height above a vertical reference”.  Interestingly, we don’t have standard 
names “elevation” or “height_above_geoid”.  This all makes sense for a system 
that appears to have grown from one where vertical datums weren’t really 
considered (horizontal ones, either!), into one where questions of reference 
frames have become more important.

Given all the confusion of usage both within CF and in the community at large, 
I guess there’s no reason not to continue to proliferate height qualifiers in 
standard names.  We already have several.

I’d be interested to know how often people have used the standard name “height” 
to mark vertical coordinates, when the values they have almost certainly are 
not “height above the surface”.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 12, 2014, at 11:42 AM, Jonathan Gregory  
wrote:

> Dear Jim
> 
> I think the same as Karl. The reason is that I regard height above geoid and
> height above reference ellipsoid as different geophysical quantities, as are
> height above bedrock (the example I gave in an earlier email, to Rich) and
> height (in the sense of the CF standard_name table i.e. above the ground). If
> I am standing on the summit of Mount Everest, the height above ground of
> my crampons is about 0 m, but their altitude is about 8848 m. In fact in your
> email you referred to them as different "sorts" of height. That sounds to me
> like different geophysical quantities. Conversion between them is possible but
> it is a non-trivial operation involving geophysical data. Similarly conversion
> is possible between altitude and geopotential height but they are different
> geophysical quantities with different standard names.
> 
> The geoid and reference ellipsoid definition, however, are fine in the grid
> mapping, because they do not define the geophysical quantity. They just make
> it numerically precise.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from Jim Biard  -
> 
>> From: Jim Biard 
>> Date: Tue, 11 Feb 2014 13:51:56 -0500
>> To: CF metadata 
>> X-Mailer: Apple Mail (2.1827)
>> CC: Karl Taylor 
>> Subject: Re: [CF-metadata] Vertical datums (again)
>> 
>> Karl,
>> 
>> My point is that putting the reference surface in the standard name 
>> (potentially) proliferates standard names for things that (like temperatures 
>> in different units) are not different except for their reference frame.  I 
>> agree that we don?t want to put the datum information in the units, but the 
&

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Karl

> I seem to recall that the normal to a geoid surface does not in
> general point in the same direction as the normal to the ellipsoid
> surface at the same place.  If that is true, would that be added
> justification for giving different standard names to heights
> relative to those surfaces?

Jim made a related useful comment the other day:

> The heights above
> the datum can be orthometric (normal to the datum surface at the point) or
> geodetic (normal to the ellipsoid).  If your vertical datum is an ellipsoid,
> then the two types of heights are the same.  If you are using a
> non-ellipsoidal vertical datum, you are probably going to report orthometric
> heights ...
> orthometric (normal to the geoid), geodetic (normal to the ellipsoid), and
> geocentric (relative to the ellipsoid, but not normal to it).

"Geometric" is also used but not in Jim's list.

I wasn't aware of this kind of distinction and I suppose that relevant
standard_names should say orthometric_height, geodetic_height, etc. instead
of height, for use in cases where the distinction is important. Presumably
so far no-one has required this additional precision.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Karl Taylor]

Dear all,

(I'm not positive about this, but)
I seem to recall that the normal to a geoid surface does not in general 
point in the same direction as the normal to the ellipsoid surface at 
the same place.  If that is true, would that be added justification for 
giving different standard names to heights relative to those surfaces?


Karl

On 2/12/14, 10:01 AM, Jonathan Gregory wrote:

Dear Ethan, Balaji et al.

No-one is suggesting having different standard names for different geoids or
different reference ellipsoids, as far as I know. We agree that the identity of
the geoid etc. belongs in the grid mapping. The distinction of standard names
is for different geophysical quantities. The distinction of what is truly
different is blurred, but we have to make black-and-white choices. The one
which we make in many existing CF standard names is that if quantities refer
to different geophysically defined surfaces that makes them different geo-
physical quantities. I think that's a useful distinction for a data-analyst.
Geoid, reference ellipsoid, surface (i.e. bottom of the atmosphere), bedrock
(bottom of atmosphere, sea or ice sheet, whichever is lowest) and mean sea
level are all different geophysical concepts, aren't they. In my opinion,
primarily as a scientist analysing data, heights referring to these various
references are not the same geophysical quantity, and I expect them to have
different standard names. That is the approach we have followed in naming
quantities up to now.

I agree with Balaji to the extent that the standard name is not a complete
characterisation of a quantity. There is other CF metadata. Especially, there
are coordinates. The height of cloud can be specified by coordinates, which
avoids the needs for more standard names, is more precise and much more
flexible. I regard cloud amount on any level as the same geophysical quantity
(while acknowledging that different cloud microphysics is at work, of course)
and so I am happy for clouds at various heights to be distinguished by
coordinates. The same is the reason why we have a standard_name for
air_temperature, but we don't have one for "surface air temperature", since
the extra precision can be supplied by a coordinate of height. This is another
blurred distinction, I realise, but I think it works quite well in practice.

Cheers

Jonathan

- Forwarded message from Ethan Davis  -


Date: Wed, 12 Feb 2014 10:43:46 -0700
From: Ethan Davis 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Vertical datums (again)

Hi all,

I agree with Jim on this. The grid_mapping, rather than the standard
name, is the appropriate place for this information. Just as it is for
"latitude" and "longitude (and X and Y). We don't have "latitude-wgs84"
or "latitude-airy-1830".

Ethan

On 2/11/2014 11:51 AM, Jim Biard wrote:

Karl,

My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like
temperatures in different units) are not different except for their
reference frame.  I agree that we don?t want to put the datum
information in the units, but the place for this sort of information
already exists - it?s the grid_mapping variable.  We don?t have the
appropriate attributes defined yet, but that is where the information
should go.  The definition of the standard name can state a requirement
for the information to present in a grid_mapping variable.  I thought
that the point of standard names was to assist in identifying variables
that are of the same kind or class, and that the goal was to avoid
putting implementation details into standard_names.  By tacking on CRS
details, it seems to me that we are moving away from that goal.

Grace and peace,

Jim

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[V Balaji - NOAA Affiliate]

It's obvious even to this non-expert that different reference surfaces
yield different heights, but I fail to see how they are different
"sorts of height". Though I'm happy to stand corrected on that.

But for another reason I would like to take a contrary position here:
I don't believe the standard_name attribute uniquely identifies
a physical quantity, and the fact of two quantities sharing that
attribute doesn't make them "synonymous" to use Jim's terminology.

The example I often use to illustrate this is the quantities called
high, middle and low cloud amount. They all share the standard_name
cloud_amount_in_atmospheric_layer, and then another attribute defines
the layer.

The reason I'm making a bit of an issue of this, is that I think trying
to squeeze too much information into the standard_name attribute alone
will make it too convoluted. Other attributes of the variable may be
needed to remove all ambiguity, and that's fine. It's always been so
in CF.

Jonathan Gregory writes:


Dear Jim

I think the same as Karl. The reason is that I regard height above geoid and
height above reference ellipsoid as different geophysical quantities, as are
height above bedrock (the example I gave in an earlier email, to Rich) and
height (in the sense of the CF standard_name table i.e. above the ground). If
I am standing on the summit of Mount Everest, the height above ground of
my crampons is about 0 m, but their altitude is about 8848 m. In fact in your
email you referred to them as different "sorts" of height. That sounds to me
like different geophysical quantities. Conversion between them is possible but
it is a non-trivial operation involving geophysical data. Similarly conversion
is possible between altitude and geopotential height but they are different
geophysical quantities with different standard names.

The geoid and reference ellipsoid definition, however, are fine in the grid
mapping, because they do not define the geophysical quantity. They just make
it numerically precise.

Best wishes

Jonathan

- Forwarded message from Jim Biard  -


From: Jim Biard 
Date: Tue, 11 Feb 2014 13:51:56 -0500
To: CF metadata 
X-Mailer: Apple Mail (2.1827)
CC: Karl Taylor 
Subject: Re: [CF-metadata] Vertical datums (again)

Karl,

My point is that putting the reference surface in the standard name 
(potentially) proliferates standard names for things that (like temperatures in 
different units) are not different except for their reference frame.  I agree 
that we don?t want to put the datum information in the units, but the place for 
this sort of information already exists - it?s the grid_mapping variable.  We 
don?t have the appropriate attributes defined yet, but that is where the 
information should go.  The definition of the standard name can state a 
requirement for the information to present in a grid_mapping variable.  I 
thought that the point of standard names was to assist in identifying variables 
that are of the same kind or class, and that the goal was to avoid putting 
implementation details into standard_names.  By tacking on CRS details, it 
seems to me that we are moving away from that goal.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 11, 2014, at 1:44 PM, Karl Taylor  wrote:


Hi all,

for temperature, the units imply a zero point, but for height they don't.  For time, we 
specifically include the zero point in the units (e.g., "days since 20010101") and we 
also distinguish among various calendars with the "calendar" attribute.  For height I 
wouldn't advocate that approach, but rather the already proposed hybrid approach:  the standard 
name (roughly) specifies the reference surface, which can then be more precisely defined in another 
place (e.g., within the grid_mapping).

best regards,
Karl




On 2/11/14, 10:05 AM, Jim Biard wrote:

Hi.

It seems to me that tacking on a description of the datum in the standard name 
isn?t a good plan.  It creates a linkage between standard names and grid 
mappings / WKT blocks.  The nature of the height of the sea surface is
not altered by the choice of datum.  The values will be different, depending on 
what sort of height, but you can (most of the time!) translate heights from one 
CRS to another.  It is definitely more complicated, but tacking on a datum 
description appears to me to be akin to having different standard names for 
?temperature_in_C? and ?temperature_in_K?.  If you have properly specified your 
CRS, the question of where the zero in your height scale is located is 
completely unambiguous.

Grace and peace,

Jim

 Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for 

Re: [CF-metadata] Vertical datums (again)

[V Balaji - NOAA Affiliate]

Ok, fair enough. I understand it's blurry, and I suppose all I'm
arguing for is some general vigilance against proliferation of
names. You understand as well as anyone the need to be very very
precise in defining sea level rise, and I'll defer to your judgment
on this matter. (BTW when are we going to see a standard_name with
"barystatic" in it?)

Thanks,


Jonathan Gregory writes:


Dear Ethan, Balaji et al.

No-one is suggesting having different standard names for different geoids or
different reference ellipsoids, as far as I know. We agree that the identity of
the geoid etc. belongs in the grid mapping. The distinction of standard names
is for different geophysical quantities. The distinction of what is truly
different is blurred, but we have to make black-and-white choices. The one
which we make in many existing CF standard names is that if quantities refer
to different geophysically defined surfaces that makes them different geo-
physical quantities. I think that's a useful distinction for a data-analyst.
Geoid, reference ellipsoid, surface (i.e. bottom of the atmosphere), bedrock
(bottom of atmosphere, sea or ice sheet, whichever is lowest) and mean sea
level are all different geophysical concepts, aren't they. In my opinion,
primarily as a scientist analysing data, heights referring to these various
references are not the same geophysical quantity, and I expect them to have
different standard names. That is the approach we have followed in naming
quantities up to now.

I agree with Balaji to the extent that the standard name is not a complete
characterisation of a quantity. There is other CF metadata. Especially, there
are coordinates. The height of cloud can be specified by coordinates, which
avoids the needs for more standard names, is more precise and much more
flexible. I regard cloud amount on any level as the same geophysical quantity
(while acknowledging that different cloud microphysics is at work, of course)
and so I am happy for clouds at various heights to be distinguished by
coordinates. The same is the reason why we have a standard_name for
air_temperature, but we don't have one for "surface air temperature", since
the extra precision can be supplied by a coordinate of height. This is another
blurred distinction, I realise, but I think it works quite well in practice.

Cheers

Jonathan

- Forwarded message from Ethan Davis  -


Date: Wed, 12 Feb 2014 10:43:46 -0700
From: Ethan Davis 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
Thunderbird/24.3.0
To: cf-metadata@cgd.ucar.edu
Subject: Re: [CF-metadata] Vertical datums (again)

Hi all,

I agree with Jim on this. The grid_mapping, rather than the standard
name, is the appropriate place for this information. Just as it is for
"latitude" and "longitude (and X and Y). We don't have "latitude-wgs84"
or "latitude-airy-1830".

Ethan

On 2/11/2014 11:51 AM, Jim Biard wrote:

Karl,

My point is that putting the reference surface in the standard name
(potentially) proliferates standard names for things that (like
temperatures in different units) are not different except for their
reference frame.  I agree that we don?t want to put the datum
information in the units, but the place for this sort of information
already exists - it?s the grid_mapping variable.  We don?t have the
appropriate attributes defined yet, but that is where the information
should go.  The definition of the standard name can state a requirement
for the information to present in a grid_mapping variable.  I thought
that the point of standard names was to assist in identifying variables
that are of the same kind or class, and that the goal was to avoid
putting implementation details into standard_names.  By tacking on CRS
details, it seems to me that we are moving away from that goal.

Grace and peace,

Jim

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--

V. Balaji   Office:  +1-609-452-6516
Head, Modeling Systems Group, GFDL  Home:+1-212-643-2089
Princeton UniversityEmail: v.bal...@noaa.gov
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Ethan Davis]

Both geoids and reference ellipsoids are vertical datums used as the
reference from which measurements can be made. I'm not sure I see how
that makes those measurements different geophysical quantities.

I can see how lat/lon and X/Y are different. Similarly, height and
pressure levels are different. But height as measured from two different
types of vertical datums does not seem different in the same manner.

Ethan

On 2/12/2014 9:42 AM, Jonathan Gregory wrote:
> Dear Jim
> 
> I think the same as Karl. The reason is that I regard height above geoid and
> height above reference ellipsoid as different geophysical quantities, as are
> height above bedrock (the example I gave in an earlier email, to Rich) and
> height (in the sense of the CF standard_name table i.e. above the ground). If
> I am standing on the summit of Mount Everest, the height above ground of
> my crampons is about 0 m, but their altitude is about 8848 m. In fact in your
> email you referred to them as different "sorts" of height. That sounds to me
> like different geophysical quantities. Conversion between them is possible but
> it is a non-trivial operation involving geophysical data. Similarly conversion
> is possible between altitude and geopotential height but they are different
> geophysical quantities with different standard names.
> 
> The geoid and reference ellipsoid definition, however, are fine in the grid
> mapping, because they do not define the geophysical quantity. They just make
> it numerically precise.
> 
> Best wishes
> 
> Jonathan
> 
> - Forwarded message from Jim Biard  -
> 
>> From: Jim Biard 
>> Date: Tue, 11 Feb 2014 13:51:56 -0500
>> To: CF metadata 
>> X-Mailer: Apple Mail (2.1827)
>> CC: Karl Taylor 
>> Subject: Re: [CF-metadata] Vertical datums (again)
>>
>> Karl,
>>
>> My point is that putting the reference surface in the standard name 
>> (potentially) proliferates standard names for things that (like temperatures 
>> in different units) are not different except for their reference frame.  I 
>> agree that we don?t want to put the datum information in the units, but the 
>> place for this sort of information already exists - it?s the grid_mapping 
>> variable.  We don?t have the appropriate attributes defined yet, but that is 
>> where the information should go.  The definition of the standard name can 
>> state a requirement for the information to present in a grid_mapping 
>> variable.  I thought that the point of standard names was to assist in 
>> identifying variables that are of the same kind or class, and that the goal 
>> was to avoid putting implementation details into standard_names.  By tacking 
>> on CRS details, it seems to me that we are moving away from that goal.
>>
>> Grace and peace,
>>
>> Jim
>>
>> Visit us on
>> Facebook Jim Biard
>> Research Scholar
>> Cooperative Institute for Climate and Satellites NC
>> North Carolina State University
>> NOAA's National Climatic Data Center
>> 151 Patton Ave, Asheville, NC 28801
>> e: jbi...@cicsnc.org
>> o: +1 828 271 4900
>>
>>
>>
>>
>> On Feb 11, 2014, at 1:44 PM, Karl Taylor  wrote:
>>
>>> Hi all,
>>>
>>> for temperature, the units imply a zero point, but for height they don't.  
>>> For time, we specifically include the zero point in the units (e.g., "days 
>>> since 20010101") and we also distinguish among various calendars with the 
>>> "calendar" attribute.  For height I wouldn't advocate that approach, but 
>>> rather the already proposed hybrid approach:  the standard name (roughly) 
>>> specifies the reference surface, which can then be more precisely defined 
>>> in another place (e.g., within the grid_mapping).  
>>>
>>> best regards,
>>> Karl
>>>
>>>
>>>
>>>
>>> On 2/11/14, 10:05 AM, Jim Biard wrote:
>>>> Hi.
>>>>
>>>> It seems to me that tacking on a description of the datum in the standard 
>>>> name isn?t a good plan.  It creates a linkage between standard names and 
>>>> grid mappings / WKT blocks.  The nature of the height of the sea surface 
>>>> is 
>>>> not altered by the choice of datum.  The values will be different, 
>>>> depending on what sort of height, but you can (most of the time!) 
>>>> translate heights from one CRS to another.  It is definitely more 
>>>> complicated, but tacking on a datum description appears to me to be akin 
>>>> to having different stan

Re: [CF-metadata] Vertical datums (again)

[Ethan Davis]

Hi all,

I agree with Jim on this. The grid_mapping, rather than the standard
name, is the appropriate place for this information. Just as it is for
"latitude" and "longitude (and X and Y). We don't have "latitude-wgs84"
or "latitude-airy-1830".

Ethan

On 2/11/2014 11:51 AM, Jim Biard wrote:
> Karl,
> 
> My point is that putting the reference surface in the standard name
> (potentially) proliferates standard names for things that (like
> temperatures in different units) are not different except for their
> reference frame.  I agree that we don’t want to put the datum
> information in the units, but the place for this sort of information
> already exists - it’s the grid_mapping variable.  We don’t have the
> appropriate attributes defined yet, but that is where the information
> should go.  The definition of the standard name can state a requirement
> for the information to present in a grid_mapping variable.  I thought
> that the point of standard names was to assist in identifying variables
> that are of the same kind or class, and that the goal was to avoid
> putting implementation details into standard_names.  By tacking on CRS
> details, it seems to me that we are moving away from that goal.
> 
> Grace and peace,
> 
> Jim
> 
> CICS-NC Visit us on
> Facebook  *Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC 
> North Carolina State University 
> NOAA's National Climatic Data Center 
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org 
> o: +1 828 271 4900
> 
> 
> 
> 
> 
> On Feb 11, 2014, at 1:44 PM, Karl Taylor  > wrote:
> 
>> Hi all,
>>
>> for temperature, the units imply a zero point, but for height they
>> don't.  For time, we specifically include the zero point in the units
>> (e.g., "days since 20010101") and we also distinguish among various
>> calendars with the "calendar" attribute.  For height I wouldn't
>> advocate that approach, but rather the already proposed hybrid
>> approach:  the standard name (roughly) specifies the reference
>> surface, which can then be more precisely defined in another place
>> (e.g., within the grid_mapping). 
>>
>> best regards,
>> Karl
>>
>>
>>
>>
>> On 2/11/14, 10:05 AM, Jim Biard wrote:
>>> Hi.
>>>
>>> It seems to me that tacking on a description of the datum in the
>>> standard name isn’t a good plan.  It creates a linkage between
>>> standard names and grid mappings / WKT blocks.  The nature of the
>>> height of the sea surface is 
>>> not altered by the choice of datum.  The values will be different,
>>> depending on what sort of height, but you can (most of the time!)
>>> translate heights from one CRS to another.  It is definitely more
>>> complicated, but tacking on a datum description appears to me to be
>>> akin to having different standard names for “temperature_in_C” and
>>> “temperature_in_K”.  If you have properly specified your CRS, the
>>> question of where the zero in your height scale is located is
>>> completely unambiguous.
>>>
>>> Grace and peace,
>>>
>>> Jim
>>>
>>> CICS-NC Visit us on
>>> Facebook    *Jim Biard*
>>> *Research Scholar*
>>> Cooperative Institute for Climate and Satellites NC 
>>> North Carolina State University 
>>> NOAA's National Climatic Data Center 
>>> 151 Patton Ave, Asheville, NC 28801
>>> e: jbi...@cicsnc.org 
>>> o: +1 828 271 4900
>>>
>>>
>>>
>>>
>>>
>>> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory
>>> mailto:j.m.greg...@reading.ac.uk>> wrote:
>>>
 Dear Rich

> Thanks for the detailed explanation (and analogy) of why it's useful
> to tack on the "_above_geoid" or "_above_ellipsoid" or
> "_above_tidal_datum" to the standard-name.
>
> So we do that and then specify the geoid, ellipsoid or tidal datum
> elsewhere in the grid_mapping variable, right?

 Yes, that is the way we've been proceeding up to now. In fact we do
 not have
 any stdnames yet referring to tidal datum, but you're welcome to
 propose them
 if they're needed now, of course.

> geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
> ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
> tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc

 Thanks for these useful lists! I would tend to think that we should
 give different standard names for the various different tidal
 datums, since
 I would regard those as different geophysical quantities - would you
 agree?
 If there was data which referred to a tidal datum but didn't
 actually know
 which one it was, I suppose it might still be useful (if imprecise)
 and it
 could have a standard name that referred to "tidal datum"
 generically. But
 

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Jim

I think the same as Karl. The reason is that I regard height above geoid and
height above reference ellipsoid as different geophysical quantities, as are
height above bedrock (the example I gave in an earlier email, to Rich) and
height (in the sense of the CF standard_name table i.e. above the ground). If
I am standing on the summit of Mount Everest, the height above ground of
my crampons is about 0 m, but their altitude is about 8848 m. In fact in your
email you referred to them as different "sorts" of height. That sounds to me
like different geophysical quantities. Conversion between them is possible but
it is a non-trivial operation involving geophysical data. Similarly conversion
is possible between altitude and geopotential height but they are different
geophysical quantities with different standard names.

The geoid and reference ellipsoid definition, however, are fine in the grid
mapping, because they do not define the geophysical quantity. They just make
it numerically precise.

Best wishes

Jonathan

- Forwarded message from Jim Biard  -

> From: Jim Biard 
> Date: Tue, 11 Feb 2014 13:51:56 -0500
> To: CF metadata 
> X-Mailer: Apple Mail (2.1827)
> CC: Karl Taylor 
> Subject: Re: [CF-metadata] Vertical datums (again)
> 
> Karl,
> 
> My point is that putting the reference surface in the standard name 
> (potentially) proliferates standard names for things that (like temperatures 
> in different units) are not different except for their reference frame.  I 
> agree that we don?t want to put the datum information in the units, but the 
> place for this sort of information already exists - it?s the grid_mapping 
> variable.  We don?t have the appropriate attributes defined yet, but that is 
> where the information should go.  The definition of the standard name can 
> state a requirement for the information to present in a grid_mapping 
> variable.  I thought that the point of standard names was to assist in 
> identifying variables that are of the same kind or class, and that the goal 
> was to avoid putting implementation details into standard_names.  By tacking 
> on CRS details, it seems to me that we are moving away from that goal.
> 
> Grace and peace,
> 
> Jim
> 
> Visit us on
> Facebook  Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
> 
> 
> 
> 
> On Feb 11, 2014, at 1:44 PM, Karl Taylor  wrote:
> 
> > Hi all,
> > 
> > for temperature, the units imply a zero point, but for height they don't.  
> > For time, we specifically include the zero point in the units (e.g., "days 
> > since 20010101") and we also distinguish among various calendars with the 
> > "calendar" attribute.  For height I wouldn't advocate that approach, but 
> > rather the already proposed hybrid approach:  the standard name (roughly) 
> > specifies the reference surface, which can then be more precisely defined 
> > in another place (e.g., within the grid_mapping).  
> > 
> > best regards,
> > Karl
> > 
> > 
> > 
> > 
> > On 2/11/14, 10:05 AM, Jim Biard wrote:
> >> Hi.
> >> 
> >> It seems to me that tacking on a description of the datum in the standard 
> >> name isn?t a good plan.  It creates a linkage between standard names and 
> >> grid mappings / WKT blocks.  The nature of the height of the sea surface 
> >> is 
> >> not altered by the choice of datum.  The values will be different, 
> >> depending on what sort of height, but you can (most of the time!) 
> >> translate heights from one CRS to another.  It is definitely more 
> >> complicated, but tacking on a datum description appears to me to be akin 
> >> to having different standard names for ?temperature_in_C? and 
> >> ?temperature_in_K?.  If you have properly specified your CRS, the question 
> >> of where the zero in your height scale is located is completely 
> >> unambiguous.
> >> 
> >> Grace and peace,
> >> 
> >> Jim
> >> 
> >>  Visit us on
> >> Facebook   Jim Biard
> >> Research Scholar
> >> Cooperative Institute for Climate and Satellites NC
> >> North Carolina State University
> >> NOAA's National Climatic Data Center
> >> 151 Patton Ave, Asheville, NC 28801
> >> e: jbi...@cicsnc.org
> >> o: +1 828 271 4900
> >> 
> >> 
> >> 
> >> 
> >> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Karl,

My point is that putting the reference surface in the standard name 
(potentially) proliferates standard names for things that (like temperatures in 
different units) are not different except for their reference frame.  I agree 
that we don’t want to put the datum information in the units, but the place for 
this sort of information already exists - it’s the grid_mapping variable.  We 
don’t have the appropriate attributes defined yet, but that is where the 
information should go.  The definition of the standard name can state a 
requirement for the information to present in a grid_mapping variable.  I 
thought that the point of standard names was to assist in identifying variables 
that are of the same kind or class, and that the goal was to avoid putting 
implementation details into standard_names.  By tacking on CRS details, it 
seems to me that we are moving away from that goal.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 11, 2014, at 1:44 PM, Karl Taylor  wrote:

> Hi all,
> 
> for temperature, the units imply a zero point, but for height they don't.  
> For time, we specifically include the zero point in the units (e.g., "days 
> since 20010101") and we also distinguish among various calendars with the 
> "calendar" attribute.  For height I wouldn't advocate that approach, but 
> rather the already proposed hybrid approach:  the standard name (roughly) 
> specifies the reference surface, which can then be more precisely defined in 
> another place (e.g., within the grid_mapping).  
> 
> best regards,
> Karl
> 
> 
> 
> 
> On 2/11/14, 10:05 AM, Jim Biard wrote:
>> Hi.
>> 
>> It seems to me that tacking on a description of the datum in the standard 
>> name isn’t a good plan.  It creates a linkage between standard names and 
>> grid mappings / WKT blocks.  The nature of the height of the sea surface is 
>> not altered by the choice of datum.  The values will be different, depending 
>> on what sort of height, but you can (most of the time!) translate heights 
>> from one CRS to another.  It is definitely more complicated, but tacking on 
>> a datum description appears to me to be akin to having different standard 
>> names for “temperature_in_C” and “temperature_in_K”.  If you have properly 
>> specified your CRS, the question of where the zero in your height scale is 
>> located is completely unambiguous.
>> 
>> Grace and peace,
>> 
>> Jim
>> 
>>  Visit us on
>> Facebook Jim Biard
>> Research Scholar
>> Cooperative Institute for Climate and Satellites NC
>> North Carolina State University
>> NOAA's National Climatic Data Center
>> 151 Patton Ave, Asheville, NC 28801
>> e: jbi...@cicsnc.org
>> o: +1 828 271 4900
>> 
>> 
>> 
>> 
>> On Feb 11, 2014, at 11:43 AM, Jonathan Gregory  
>> wrote:
>> 
>>> Dear Rich
>>> 
 Thanks for the detailed explanation (and analogy) of why it's useful
 to tack on the "_above_geoid" or "_above_ellipsoid" or
 "_above_tidal_datum" to the standard-name.
 
 So we do that and then specify the geoid, ellipsoid or tidal datum
 elsewhere in the grid_mapping variable, right?
>>> 
>>> Yes, that is the way we've been proceeding up to now. In fact we do not have
>>> any stdnames yet referring to tidal datum, but you're welcome to propose 
>>> them
>>> if they're needed now, of course.
>>> 
 geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
 ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
 tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc
>>> 
>>> Thanks for these useful lists! I would tend to think that we should
>>> give different standard names for the various different tidal datums, since
>>> I would regard those as different geophysical quantities - would you agree?
>>> If there was data which referred to a tidal datum but didn't actually know
>>> which one it was, I suppose it might still be useful (if imprecise) and it
>>> could have a standard name that referred to "tidal datum" generically. But
>>> if you know it's mean_high_water (for instance), I would spell that out in
>>> the standard name.
>>> 
>>> However I think the various geoids are all different estimates of the same
>>> geophysical quantity, so they should *not* have different standard names.
>>> Likewise the ref ellipsoid is the "best" ellipsoid approximating the geoid -
>>> again, that is a single geophysical concept, with many alternative versions.
>>> 
>>> So we need a place to name the geoid, if that is the vertical datum. It 
>>> would
>>> be good to have a similar treatment to CRS WKT for this, but I don't see a
>>> place in WKT where the geoid can be identified. Can anyone help? Is the 
>>> geoid
>>> implied by, or identical to, the vertical datum name, perhaps? How does one
>>> know, in WKT, whether the vertical datum is a geoid

Re: [CF-metadata] Vertical datums (again)

[Karl Taylor]

Hi all,

for temperature, the units imply a zero point, but for height they 
don't.  For time, we specifically include the zero point in the units 
(e.g., "days since 20010101") and we also distinguish among various 
calendars with the "calendar" attribute.  For height I wouldn't advocate 
that approach, but rather the already proposed hybrid approach:  the 
standard name (roughly) specifies the reference surface, which can then 
be more precisely defined in another place (e.g., within the grid_mapping).


best regards,
Karl




On 2/11/14, 10:05 AM, Jim Biard wrote:

Hi.

It seems to me that tacking on a description of the datum in the 
standard name isn't a good plan.  It creates a linkage between 
standard names and grid mappings / WKT blocks.  The nature of the 
height of the sea surface is
not altered by the choice of datum.  The values will be different, 
depending on what sort of height, but you can (most of the time!) 
translate heights from one CRS to another.  It is definitely more 
complicated, but tacking on a datum description appears to me to be 
akin to having different standard names for "temperature_in_C" and 
"temperature_in_K".  If you have properly specified your CRS, the 
question of where the zero in your height scale is located is 
completely unambiguous.


Grace and peace,

Jim

CICS-NC Visit us on
Facebook  *Jim Biard*
*Research Scholar*
Cooperative Institute for Climate and Satellites NC 
North Carolina State University 
NOAA's National Climatic Data Center 
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org 
o: +1 828 271 4900





On Feb 11, 2014, at 11:43 AM, Jonathan Gregory 
mailto:j.m.greg...@reading.ac.uk>> wrote:



Dear Rich


Thanks for the detailed explanation (and analogy) of why it's useful
to tack on the "_above_geoid" or "_above_ellipsoid" or
"_above_tidal_datum" to the standard-name.

So we do that and then specify the geoid, ellipsoid or tidal datum
elsewhere in the grid_mapping variable, right?


Yes, that is the way we've been proceeding up to now. In fact we do 
not have
any stdnames yet referring to tidal datum, but you're welcome to 
propose them

if they're needed now, of course.


geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc


Thanks for these useful lists! I would tend to think that we should
give different standard names for the various different tidal datums, 
since
I would regard those as different geophysical quantities - would you 
agree?
If there was data which referred to a tidal datum but didn't actually 
know
which one it was, I suppose it might still be useful (if imprecise) 
and it
could have a standard name that referred to "tidal datum" 
generically. But
if you know it's mean_high_water (for instance), I would spell that 
out in

the standard name.

However I think the various geoids are all different estimates of the 
same

geophysical quantity, so they should *not* have different standard names.
Likewise the ref ellipsoid is the "best" ellipsoid approximating the 
geoid -
again, that is a single geophysical concept, with many alternative 
versions.


So we need a place to name the geoid, if that is the vertical datum. 
It would
be good to have a similar treatment to CRS WKT for this, but I don't 
see a
place in WKT where the geoid can be identified. Can anyone help? Is 
the geoid
implied by, or identical to, the vertical datum name, perhaps? How 
does one

know, in WKT, whether the vertical datum is a geoid or a ref ellipsoid?

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu 
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

It seems to me that tacking on a description of the datum in the standard name 
isn’t a good plan.  It creates a linkage between standard names and grid 
mappings / WKT blocks.  The nature of the height of the sea surface is 
not altered by the choice of datum.  The values will be different, depending on 
what sort of height, but you can (most of the time!) translate heights from one 
CRS to another.  It is definitely more complicated, but tacking on a datum 
description appears to me to be akin to having different standard names for 
“temperature_in_C” and “temperature_in_K”.  If you have properly specified your 
CRS, the question of where the zero in your height scale is located is 
completely unambiguous.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 11, 2014, at 11:43 AM, Jonathan Gregory  
wrote:

> Dear Rich
> 
>> Thanks for the detailed explanation (and analogy) of why it's useful
>> to tack on the "_above_geoid" or "_above_ellipsoid" or
>> "_above_tidal_datum" to the standard-name.
>> 
>> So we do that and then specify the geoid, ellipsoid or tidal datum
>> elsewhere in the grid_mapping variable, right?
> 
> Yes, that is the way we've been proceeding up to now. In fact we do not have
> any stdnames yet referring to tidal datum, but you're welcome to propose them
> if they're needed now, of course.
> 
>> geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
>> ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
>> tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc
> 
> Thanks for these useful lists! I would tend to think that we should
> give different standard names for the various different tidal datums, since
> I would regard those as different geophysical quantities - would you agree?
> If there was data which referred to a tidal datum but didn't actually know
> which one it was, I suppose it might still be useful (if imprecise) and it
> could have a standard name that referred to "tidal datum" generically. But
> if you know it's mean_high_water (for instance), I would spell that out in
> the standard name.
> 
> However I think the various geoids are all different estimates of the same
> geophysical quantity, so they should *not* have different standard names.
> Likewise the ref ellipsoid is the "best" ellipsoid approximating the geoid -
> again, that is a single geophysical concept, with many alternative versions.
> 
> So we need a place to name the geoid, if that is the vertical datum. It would
> be good to have a similar treatment to CRS WKT for this, but I don't see a
> place in WKT where the geoid can be identified. Can anyone help? Is the geoid
> implied by, or identical to, the vertical datum name, perhaps? How does one
> know, in WKT, whether the vertical datum is a geoid or a ref ellipsoid?
> 
> Best wishes
> 
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Rich

> Thanks for the detailed explanation (and analogy) of why it's useful
> to tack on the "_above_geoid" or "_above_ellipsoid" or
> "_above_tidal_datum" to the standard-name.
> 
> So we do that and then specify the geoid, ellipsoid or tidal datum
> elsewhere in the grid_mapping variable, right?

Yes, that is the way we've been proceeding up to now. In fact we do not have
any stdnames yet referring to tidal datum, but you're welcome to propose them
if they're needed now, of course.

> geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
> ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
> tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc

Thanks for these useful lists! I would tend to think that we should
give different standard names for the various different tidal datums, since
I would regard those as different geophysical quantities - would you agree?
If there was data which referred to a tidal datum but didn't actually know
which one it was, I suppose it might still be useful (if imprecise) and it
could have a standard name that referred to "tidal datum" generically. But
if you know it's mean_high_water (for instance), I would spell that out in
the standard name.

However I think the various geoids are all different estimates of the same
geophysical quantity, so they should *not* have different standard names.
Likewise the ref ellipsoid is the "best" ellipsoid approximating the geoid -
again, that is a single geophysical concept, with many alternative versions.

So we need a place to name the geoid, if that is the vertical datum. It would
be good to have a similar treatment to CRS WKT for this, but I don't see a
place in WKT where the geoid can be identified. Can anyone help? Is the geoid
implied by, or identical to, the vertical datum name, perhaps? How does one
know, in WKT, whether the vertical datum is a geoid or a ref ellipsoid?

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Signell, Richard]

Jonathan,
Thanks for the detailed explanation (and analogy) of why it's useful
to tack on the "_above_geoid" or "_above_ellipsoid" or
"_above_tidal_datum" to the standard-name.

So we do that and then specify the geoid, ellipsoid or tidal datum
elsewhere in the grid_mapping variable, right?

geoid:  NAVD88, GEOID93, GEOID96, USGG2009, etc
ellipsoid: WGS84, Airy 1830, Airy Modified 1849, etc
tidal_datum: MLLW, MLW, MTL, MHW, MHHW, etc

Older bathymetry data are almost always reported relative to
tidal_datums.  Yes, this is a huge can of worms.  It's why vertical
datum software such as
http://vdatum.noaa.gov/
are popular, so that folks can convert from something like MLLW to NAVD88.

-Rich


On Mon, Feb 10, 2014 at 1:30 PM, Jonathan Gregory
 wrote:
> Dear Jim and Rich
>
> Many thanks for your helpful comments. I see a prospect of my understanding
> things a bit better than before!
>
> Jim says that a vertical datum always has a reference ellipsoid. Sometimes a
> vertical datum might *be* a reference ellipsoid. Sometimes it is a geoid, and
> in that case, is it accompanied by a reference ellipsoid as part of the
> definition of the vertical datum?
>
> Rich comments that a vertical datum could be orthometric. If I've understood
> Jim correctly, orthometric describes how you measure the height wrt the
> reference surface. It is not a third type of surface, in addition to geoid
> and reference ellipsoid. Is that right?
>
> Tides define a different sort of reference surface from geoid and ellipsoid.
> Are there also vertical datums which involve tidal levels in their definition?
>
>> why can't we just say
>> "sea_surface_height_above_datum" or just "sea_surface_height" and then
>> specify the vertical datum, no matter what it is?
>
> I don't think we should do so because height wrt geoid and height wrt 
> ellipsoid
> are rather different quantities. For that reason they have different standard
> names (altitude and height_above_reference_ellipsoid, and there is also a
> standard name of geoid_height_above_reference_ellipsoid). They are seriously
> different in value, aren't they? - by 100s of metres, so you have to know 
> which
> one you are dealing with. If they had the same standard name, a height wrt
> geoid from one data source and a height wrt ref ellipsoid from another might
> be regarded as comparable quantities, which could be a serious error. Of 
> course
> I recognise that the stdname is not the only metadata one should consult, but
> it is the first point of call.
>
> To make an analogy, suppose we just defined height as "vertical distance above
> something", with something defined elsewhere. Then altitude and height above
> sea floor would be synomymous standard names. I don't think that would be as
> helpful to the data-analyst.
>
> I do think, however, that it's acceptable to define the geoid or reference
> ellipsoid in another place (the grid mapping) from the standard name. This is
> still a risk, because heights on different vertical datums might be treated as
> comparable they aren't, but on the other hand there are cases where heights on
> different vertical datums could be compared e.g. if they come from models with
> a different shape for the Earth.
>
> We can meet Rich's need, I think, if we provide a way for the grid_mapping to
> specify vertical datums which involve the geoid being implied.
>
> Best wishes
>
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@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
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Jim and Rich

Many thanks for your helpful comments. I see a prospect of my understanding
things a bit better than before!

Jim says that a vertical datum always has a reference ellipsoid. Sometimes a
vertical datum might *be* a reference ellipsoid. Sometimes it is a geoid, and
in that case, is it accompanied by a reference ellipsoid as part of the
definition of the vertical datum?

Rich comments that a vertical datum could be orthometric. If I've understood
Jim correctly, orthometric describes how you measure the height wrt the
reference surface. It is not a third type of surface, in addition to geoid
and reference ellipsoid. Is that right?

Tides define a different sort of reference surface from geoid and ellipsoid.
Are there also vertical datums which involve tidal levels in their definition?

> why can't we just say
> "sea_surface_height_above_datum" or just "sea_surface_height" and then
> specify the vertical datum, no matter what it is?

I don't think we should do so because height wrt geoid and height wrt ellipsoid
are rather different quantities. For that reason they have different standard
names (altitude and height_above_reference_ellipsoid, and there is also a
standard name of geoid_height_above_reference_ellipsoid). They are seriously
different in value, aren't they? - by 100s of metres, so you have to know which
one you are dealing with. If they had the same standard name, a height wrt
geoid from one data source and a height wrt ref ellipsoid from another might
be regarded as comparable quantities, which could be a serious error. Of course
I recognise that the stdname is not the only metadata one should consult, but
it is the first point of call.

To make an analogy, suppose we just defined height as "vertical distance above
something", with something defined elsewhere. Then altitude and height above
sea floor would be synomymous standard names. I don't think that would be as
helpful to the data-analyst.

I do think, however, that it's acceptable to define the geoid or reference
ellipsoid in another place (the grid mapping) from the standard name. This is
still a risk, because heights on different vertical datums might be treated as
comparable they aren't, but on the other hand there are cases where heights on
different vertical datums could be compared e.g. if they come from models with
a different shape for the Earth.

We can meet Rich's need, I think, if we provide a way for the grid_mapping to
specify vertical datums which involve the geoid being implied.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

I’ve got no problem with your suggestion.  In fact, there are two different 
issues here.  One is defining a standard name, and the other is how to 
annotate/declare a vertical datum.  The first issue is easily resolved.  The 
second make take a bit more time.

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 7, 2014, at 2:43 PM, Signell, Richard  wrote:

> Folks,
> 
> The datums are complicated, but perhaps the issue for CF is simple.
> 
> Don't we just measure vertical distance from an origin, and that origin is 
> the vertical datum?
> 
> The vertical datum may be ellipsoidal (e.g. WGS84), Orthometric (NAVD88) or 
> Tidal (Mean Tide Level), but why can't we just say 
> "sea_surface_height_above_datum" or just "sea_surface_height" and then 
> specify the vertical datum, no matter what it is?
> 
> http://vdatum.noaa.gov/docs/datumtutorial.html
> http://www.liblas.org/development/rfc/rfc_1_verticalcs.html
> 
> -Rich
> 
> 
> 
> 
> 
> 
> On Fri, Feb 7, 2014 at 1:46 PM, Jim Biard  wrote:
> Hi.
> 
> Heights are surprisingly complicated.  The vertical datum can be an ellipsoid 
> (with a sphere being a degenerate case), a geoid, or even a plane.  Every 
> vertical datum has a reference ellipsoid.  The heights above the datum can be 
> orthometric (normal to the datum surface at the point) or geodetic (normal to 
> the ellipsoid).  If your vertical datum is an ellipsoid, then the two types 
> of heights are the same.  If you are using a non-ellipsoidal vertical datum, 
> you are probably going to report orthometric heights, but it is possible, if 
> you happened to get your heights and X/Y positions from two different sources.
> 
> Grace and peace,
> 
> Jim
> 
> Visit us on
> Facebook  Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
> 
> 
> 
> 
> On Feb 7, 2014, at 1:21 PM, Jonathan Gregory  
> wrote:
> 
>> Dear all
>> 
>> I expect people remember the very lengthy debate we had about including WKT
>> in CF, in tickets 69 and 80, which should both be included in the next 
>> version
>> of CF, although in the current draft it seems that only ticket 69 is there so
>> far. In 5.6.1 of the new draft, it reads
>> 
>> "The crs_wkt attribute is intended to act as a supplement to other
>> single-property CF grid mapping attributes (as described in Appendix F); it 
>> is
>> not intended to replace those attributes. If data producers omit the
>> single-property grid mapping attributes in favour of the compound crs_wkt
>> attribute, software which cannot interpret crs_wkt will be unable to use the
>> grid_mapping information. Therefore the CRS should be described as thoroughly
>> as possible with the single-property attributes as well as by crs_wkt."
>> 
>> Ticket 80 adds a number of new attributes for grid_mapping, which will be
>> in Table F1 of CF. See
>> https://cf-pcmdi.llnl.gov/trac/attachment/ticket/80/issue80.2.txt
>> 
>> One of these attributes is reference_ellipsoid_name. That corresponds to the
>> SPHEROID name in WKT. As far as I can see in
>> the definition of WKT,
>> http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.html
>> there isn't a way to name a geoid. I guess that's because it's only used for
>> vertical reference, so it's probably implied by the VERT_DATUM name. Is
>> that right?
>> 
>> We could add a vertical_datum_name attribute in Table F1, just as ticket 80
>> adds a horizontal_datum_name attribute. That could then be exactly what Rich
>> requested. However, I have the same concern as before about the purpose of 
>> it.
>> Is the vertical datum always a geoid? If so, that's not a problem; we could
>> just say that the vertical_datum_name identifies the geoid, and therefore
>> affects quantities whose standard_names indicate they refer to the geoid, 
>> such
>> as altitude and sea_surface_height_above_geoid. If the vertical datum is not
>> necessarily a geoid, what else could it be? I think we have to be careful 
>> about
>> what quantities might be affected by the vertical datum. Insight about this
>> would be most welcome!
>> 
>> Best wishes
>> 
>> Jonathan
>>

Re: [CF-metadata] Vertical datums (again)

[Signell, Richard]

Folks,

The datums are complicated, but perhaps the issue for CF is simple.

Don't we just measure vertical distance from an origin, and that origin is
the vertical datum?

The vertical datum may be ellipsoidal (e.g. WGS84), Orthometric (NAVD88) or
Tidal (Mean Tide Level), but why can't we just say
"sea_surface_height_above_datum" or just "sea_surface_height" and then
specify the vertical datum, no matter what it is?

http://vdatum.noaa.gov/docs/datumtutorial.html
http://www.liblas.org/development/rfc/rfc_1_verticalcs.html

-Rich






On Fri, Feb 7, 2014 at 1:46 PM, Jim Biard  wrote:

> Hi.
>
> Heights are surprisingly complicated.  The vertical datum can be an
> ellipsoid (with a sphere being a degenerate case), a geoid, or even a
> plane.  Every vertical datum has a reference ellipsoid.  The heights above
> the datum can be orthometric (normal to the datum surface at the point) or
> geodetic (normal to the ellipsoid).  If your vertical datum is an
> ellipsoid, then the two types of heights are the same.  If you are using a
> non-ellipsoidal vertical datum, you are probably going to report
> orthometric heights, but it is possible, if you happened to get your
> heights and X/Y positions from two different sources.
>
> Grace and peace,
>
> Jim
>
> [image: CICS-NC] <http://www.cicsnc.org/>Visit us on
> Facebook <http://www.facebook.com/cicsnc>*Jim Biard*
> *Research Scholar*
> Cooperative Institute for Climate and Satellites NC <http://cicsnc.org/>
> North Carolina State University <http://ncsu.edu/>
> NOAA's National Climatic Data Center <http://ncdc.noaa.gov/>
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
>
>
>
>
> On Feb 7, 2014, at 1:21 PM, Jonathan Gregory 
> wrote:
>
> Dear all
>
> I expect people remember the very lengthy debate we had about including WKT
> in CF, in tickets 69 and 80, which should both be included in the next
> version
> of CF, although in the current draft it seems that only ticket 69 is there
> so
> far. In 5.6.1 of the new draft, it reads
>
> "The crs_wkt attribute is intended to act as a supplement to other
> single-property CF grid mapping attributes (as described in Appendix F);
> it is
> not intended to replace those attributes. If data producers omit the
> single-property grid mapping attributes in favour of the compound crs_wkt
> attribute, software which cannot interpret crs_wkt will be unable to use
> the
> grid_mapping information. Therefore the CRS should be described as
> thoroughly
> as possible with the single-property attributes as well as by crs_wkt."
>
> Ticket 80 adds a number of new attributes for grid_mapping, which will be
> in Table F1 of CF. See
> https://cf-pcmdi.llnl.gov/trac/attachment/ticket/80/issue80.2.txt
>
> One of these attributes is reference_ellipsoid_name. That corresponds to
> the
> SPHEROID name in WKT. As far as I can see in
> the definition of WKT,
>
> http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.html
> there isn't a way to name a geoid. I guess that's because it's only used
> for
> vertical reference, so it's probably implied by the VERT_DATUM name. Is
> that right?
>
> We could add a vertical_datum_name attribute in Table F1, just as ticket 80
> adds a horizontal_datum_name attribute. That could then be exactly what
> Rich
> requested. However, I have the same concern as before about the purpose of
> it.
> Is the vertical datum always a geoid? If so, that's not a problem; we could
> just say that the vertical_datum_name identifies the geoid, and therefore
> affects quantities whose standard_names indicate they refer to the geoid,
> such
> as altitude and sea_surface_height_above_geoid. If the vertical datum is
> not
> necessarily a geoid, what else could it be? I think we have to be careful
> about
> what quantities might be affected by the vertical datum. Insight about this
> would be most welcome!
>
> Best wishes
>
> Jonathan
>
>
> - Forwarded message from Jim Biard  -
>
> From: Jim Biard 
> Date: Fri, 7 Feb 2014 10:38:23 -0500
> To: CF metadata 
> X-Mailer: Apple Mail (2.1827)
> Subject: Re: [CF-metadata] Vertical datums (again)
>
> Hi.
>
> I think there is still value in adding an attribute to the grid_mapping
> set where the name of the vertical datum can be supplied.  The datums
> (data?) have ?standard? names (not CF standard names).  If you aren?t using
> a named vertical datum, you could specify either ?none? (or just don?t
> specify the attribute) or ?custom? if you are using a datum that hasn?t
> been given a name.  I agree that the name alone is not nec

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

Heights are surprisingly complicated.  The vertical datum can be an ellipsoid 
(with a sphere being a degenerate case), a geoid, or even a plane.  Every 
vertical datum has a reference ellipsoid.  The heights above the datum can be 
orthometric (normal to the datum surface at the point) or geodetic (normal to 
the ellipsoid).  If your vertical datum is an ellipsoid, then the two types of 
heights are the same.  If you are using a non-ellipsoidal vertical datum, you 
are probably going to report orthometric heights, but it is possible, if you 
happened to get your heights and X/Y positions from two different sources.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 7, 2014, at 1:21 PM, Jonathan Gregory  wrote:

> Dear all
> 
> I expect people remember the very lengthy debate we had about including WKT
> in CF, in tickets 69 and 80, which should both be included in the next version
> of CF, although in the current draft it seems that only ticket 69 is there so
> far. In 5.6.1 of the new draft, it reads
> 
> "The crs_wkt attribute is intended to act as a supplement to other
> single-property CF grid mapping attributes (as described in Appendix F); it is
> not intended to replace those attributes. If data producers omit the
> single-property grid mapping attributes in favour of the compound crs_wkt
> attribute, software which cannot interpret crs_wkt will be unable to use the
> grid_mapping information. Therefore the CRS should be described as thoroughly
> as possible with the single-property attributes as well as by crs_wkt."
> 
> Ticket 80 adds a number of new attributes for grid_mapping, which will be
> in Table F1 of CF. See
> https://cf-pcmdi.llnl.gov/trac/attachment/ticket/80/issue80.2.txt
> 
> One of these attributes is reference_ellipsoid_name. That corresponds to the
> SPHEROID name in WKT. As far as I can see in
> the definition of WKT,
> http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.html
> there isn't a way to name a geoid. I guess that's because it's only used for
> vertical reference, so it's probably implied by the VERT_DATUM name. Is
> that right?
> 
> We could add a vertical_datum_name attribute in Table F1, just as ticket 80
> adds a horizontal_datum_name attribute. That could then be exactly what Rich
> requested. However, I have the same concern as before about the purpose of it.
> Is the vertical datum always a geoid? If so, that's not a problem; we could
> just say that the vertical_datum_name identifies the geoid, and therefore
> affects quantities whose standard_names indicate they refer to the geoid, such
> as altitude and sea_surface_height_above_geoid. If the vertical datum is not
> necessarily a geoid, what else could it be? I think we have to be careful 
> about
> what quantities might be affected by the vertical datum. Insight about this
> would be most welcome!
> 
> Best wishes
> 
> Jonathan
> 
> 
> ----- Forwarded message from Jim Biard  -
> 
>> From: Jim Biard 
>> Date: Fri, 7 Feb 2014 10:38:23 -0500
>> To: CF metadata 
>> X-Mailer: Apple Mail (2.1827)
>> Subject: Re: [CF-metadata] Vertical datums (again)
>> 
>> Hi.
>> 
>> I think there is still value in adding an attribute to the grid_mapping set 
>> where the name of the vertical datum can be supplied.  The datums (data?) 
>> have ?standard? names (not CF standard names).  If you aren?t using a named 
>> vertical datum, you could specify either ?none? (or just don?t specify the 
>> attribute) or ?custom? if you are using a datum that hasn?t been given a 
>> name.  I agree that the name alone is not necessarily sufficient, but it 
>> does provide a human-readable marker, whereas the WKT and URN approaches 
>> require further digging.
>> 
>> Just to be clear, I?m not advocating either/or with regards to the more 
>> rigorous approaches.  A ?vertical_datum? attribute that contains a 
>> human-readable name should be present in addition to one (or more) of the 
>> other approaches.
>> 
>> Grace and peace,
>> 
>> Jim
>> 
>> Visit us on
>> Facebook Jim Biard
>> Research Scholar
>> Cooperative Institute for Climate and Satellites NC
>> North Carolina State University
>> NOAA's National Climatic Data Center
>> 151 Patton Ave, Asheville, NC 28801
>> e: jbi...@cicsnc.org
>> o: +1 828 271 4900
>> 
>> 
>> 
>> 
>> On Feb 7, 2014, at 10:25 AM, Hedl

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear all

I expect people remember the very lengthy debate we had about including WKT
in CF, in tickets 69 and 80, which should both be included in the next version
of CF, although in the current draft it seems that only ticket 69 is there so
far. In 5.6.1 of the new draft, it reads

"The crs_wkt attribute is intended to act as a supplement to other
single-property CF grid mapping attributes (as described in Appendix F); it is
not intended to replace those attributes. If data producers omit the
single-property grid mapping attributes in favour of the compound crs_wkt
attribute, software which cannot interpret crs_wkt will be unable to use the
grid_mapping information. Therefore the CRS should be described as thoroughly
as possible with the single-property attributes as well as by crs_wkt."

Ticket 80 adds a number of new attributes for grid_mapping, which will be
in Table F1 of CF. See
https://cf-pcmdi.llnl.gov/trac/attachment/ticket/80/issue80.2.txt

One of these attributes is reference_ellipsoid_name. That corresponds to the
SPHEROID name in WKT. As far as I can see in
the definition of WKT,
http://www.geoapi.org/3.0/javadoc/org/opengis/referencing/doc-files/WKT.html
there isn't a way to name a geoid. I guess that's because it's only used for
vertical reference, so it's probably implied by the VERT_DATUM name. Is
that right?

We could add a vertical_datum_name attribute in Table F1, just as ticket 80
adds a horizontal_datum_name attribute. That could then be exactly what Rich
requested. However, I have the same concern as before about the purpose of it.
Is the vertical datum always a geoid? If so, that's not a problem; we could
just say that the vertical_datum_name identifies the geoid, and therefore
affects quantities whose standard_names indicate they refer to the geoid, such
as altitude and sea_surface_height_above_geoid. If the vertical datum is not
necessarily a geoid, what else could it be? I think we have to be careful about
what quantities might be affected by the vertical datum. Insight about this
would be most welcome!

Best wishes

Jonathan


- Forwarded message from Jim Biard  -

> From: Jim Biard 
> Date: Fri, 7 Feb 2014 10:38:23 -0500
> To: CF metadata 
> X-Mailer: Apple Mail (2.1827)
> Subject: Re: [CF-metadata] Vertical datums (again)
> 
> Hi.
> 
> I think there is still value in adding an attribute to the grid_mapping set 
> where the name of the vertical datum can be supplied.  The datums (data?) 
> have ?standard? names (not CF standard names).  If you aren?t using a named 
> vertical datum, you could specify either ?none? (or just don?t specify the 
> attribute) or ?custom? if you are using a datum that hasn?t been given a 
> name.  I agree that the name alone is not necessarily sufficient, but it does 
> provide a human-readable marker, whereas the WKT and URN approaches require 
> further digging.
> 
> Just to be clear, I?m not advocating either/or with regards to the more 
> rigorous approaches.  A ?vertical_datum? attribute that contains a 
> human-readable name should be present in addition to one (or more) of the 
> other approaches.
> 
> Grace and peace,
> 
> Jim
> 
> Visit us on
> Facebook  Jim Biard
> Research Scholar
> Cooperative Institute for Climate and Satellites NC
> North Carolina State University
> NOAA's National Climatic Data Center
> 151 Patton Ave, Asheville, NC 28801
> e: jbi...@cicsnc.org
> o: +1 828 271 4900
> 
> 
> 
> 
> On Feb 7, 2014, at 10:25 AM, Hedley, Mark  
> wrote:
> 
> > Hello Rich
> > 
> > I think that using the WKT representation for vertical datum definitions is 
> > a good approach
> > 
> > As you have indicated, it is to be supported in CF 1.7 and provides a 
> > controlled terminology set for this purpose.
> > 
> > There is an example using the OS Newlyn datum in the draft spec which fits 
> > quite nicely.  
> > 
> > I'd rather see us adopting WKT for complex issues like this than creating a 
> > syntax for encoding CF grid_mapping attributes, there's a lot of prior art 
> > we can benefit from.
> > 
> > For example WKT enables me to specify more than just the EPSG code, which 
> > is useful as not all datum instances are provided by EPSG
> > 
> > mark
> > 
> > From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Signell, 
> > Richard [rsign...@usgs.gov]
> > Sent: 04 February 2014 11:47
> > To: CF metadata
> > Subject: [CF-metadata] Vertical datums (again)
> > 
> > CF folks,
> > 
> > On a telecon yesterday with a coastal inundation modeling group, one
> > of the PIs asked me how to handle vertical datums in NetCDF --
> > 

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

I think there is still value in adding an attribute to the grid_mapping set 
where the name of the vertical datum can be supplied.  The datums (data?) have 
“standard” names (not CF standard names).  If you aren’t using a named vertical 
datum, you could specify either “none” (or just don’t specify the attribute) or 
“custom” if you are using a datum that hasn’t been given a name.  I agree that 
the name alone is not necessarily sufficient, but it does provide a 
human-readable marker, whereas the WKT and URN approaches require further 
digging.

Just to be clear, I’m not advocating either/or with regards to the more 
rigorous approaches.  A “vertical_datum” attribute that contains a 
human-readable name should be present in addition to one (or more) of the other 
approaches.

Grace and peace,

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 7, 2014, at 10:25 AM, Hedley, Mark  wrote:

> Hello Rich
> 
> I think that using the WKT representation for vertical datum definitions is a 
> good approach
> 
> As you have indicated, it is to be supported in CF 1.7 and provides a 
> controlled terminology set for this purpose.
> 
> There is an example using the OS Newlyn datum in the draft spec which fits 
> quite nicely.  
> 
> I'd rather see us adopting WKT for complex issues like this than creating a 
> syntax for encoding CF grid_mapping attributes, there's a lot of prior art we 
> can benefit from.
> 
> For example WKT enables me to specify more than just the EPSG code, which is 
> useful as not all datum instances are provided by EPSG
> 
> mark
> 
> From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Signell, 
> Richard [rsign...@usgs.gov]
> Sent: 04 February 2014 11:47
> To: CF metadata
> Subject: [CF-metadata] Vertical datums (again)
> 
> CF folks,
> 
> On a telecon yesterday with a coastal inundation modeling group, one
> of the PIs asked me how to handle vertical datums in NetCDF --
> specifically where to specify that the model bathymetry and water
> levels were were relative to NAVD88.   I wasn't sure how to reply.
> 
> Was there any resolution to the 2nd half of this question asked back in 2011?
> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/054483.html
> 
> I looked at the draft 1.7 spec, and the only vertical datum reference
> info I found was the ability to specify VERT_DATUM in the new CRS
> well-known-text (WKT) section:
> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.7-draft1/ch05s06.html#idp5644304
> 
> Is this how we should specify the vertical datum in CF, using VERT_DATUM in 
> WKT?
> 
> Thanks,
> Rich
> --
> Dr. Richard P. Signell   (508) 457-2229
> USGS, 384 Woods Hole Rd.
> Woods Hole, MA 02543-1598
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Hedley, Mark]

Hello Rich

I think that using the WKT representation for vertical datum definitions is a 
good approach

As you have indicated, it is to be supported in CF 1.7 and provides a 
controlled terminology set for this purpose.

There is an example using the OS Newlyn datum in the draft spec which fits 
quite nicely.  

I'd rather see us adopting WKT for complex issues like this than creating a 
syntax for encoding CF grid_mapping attributes, there's a lot of prior art we 
can benefit from.

For example WKT enables me to specify more than just the EPSG code, which is 
useful as not all datum instances are provided by EPSG

mark

From: CF-metadata [cf-metadata-boun...@cgd.ucar.edu] on behalf of Signell, 
Richard [rsign...@usgs.gov]
Sent: 04 February 2014 11:47
To: CF metadata
Subject: [CF-metadata] Vertical datums (again)

CF folks,

On a telecon yesterday with a coastal inundation modeling group, one
of the PIs asked me how to handle vertical datums in NetCDF --
specifically where to specify that the model bathymetry and water
levels were were relative to NAVD88.   I wasn't sure how to reply.

Was there any resolution to the 2nd half of this question asked back in 2011?
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/054483.html

I looked at the draft 1.7 spec, and the only vertical datum reference
info I found was the ability to specify VERT_DATUM in the new CRS
well-known-text (WKT) section:
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.7-draft1/ch05s06.html#idp5644304

Is this how we should specify the vertical datum in CF, using VERT_DATUM in WKT?

Thanks,
Rich
--
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jim Biard]

Hi.

NAVD88 is a geoid adjusted to geodetic leveling measurements taken all over 
North America and fixed to the “mean sea level” height at Rimouski, Quebec, 
Canada. (http://en.wikipedia.org/wiki/North_American_Vertical_Datum_of_1988)

Jim

Visit us on
FacebookJim Biard
Research Scholar
Cooperative Institute for Climate and Satellites NC
North Carolina State University
NOAA's National Climatic Data Center
151 Patton Ave, Asheville, NC 28801
e: jbi...@cicsnc.org
o: +1 828 271 4900




On Feb 6, 2014, at 11:47 AM, Jonathan Gregory  wrote:

> Dear Rich
> 
>> Yes, I think your answer before is the answer now, but I'm just clear
>> on the details.  Would you specify sea_surface_height above NAVD88
>> like this?
>> 
>>float zeta(y=1534, x=2122);
>>  :standard_name = "sea_surface_height_above_reference_datum";
>>  :grid_mapping = "Albers_Projection";
>> 
>>int Albers_Projection;
>>  :grid_mapping_name = "albers_conical_equal_area";
>>  :standard_parallel = 20.5, 27.5; // double
>>  :longitude_of_central_meridian = -89.0; // double
>>  :latitude_of_projection_origin = 24.0; // double
>>  :false_easting = 0.0; // double
>>  :false_north = 0.0; // double
>>  :vertical_datum = 'urn:ogc:def:datum:epsg::5103'
> 
> I'm not clear still what NAVD88 is though. SSH must be above some surface. Is
> this surface a reference ellipsoid or a geoid? These are two different 
> standard
> names:
>  sea_surface_height_above_geoid
>  sea_surface_height_above_reference_ellipsoid
> whereas sea_surface_height_above_reference_datum is not an existing stdname.
> 
> If it's a reference ellipsoid, it can be described already by grid_mapping
> parameters. To name a geoid, we'd need a new attribute of grid_mapping, but
> I don't think that would be problematic.
> 
> Best wishes
> 
> Jonathan
> ___
> CF-metadata mailing list
> CF-metadata@cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Nan

> DEPTH:reference=;
> where currently vetted values for R are  "mean_sea_level",
> "mean_lower_low_water",
> "wgs84_geoid" and the default,  "sea_level".
> 
> DEPTH:coordinate_reference_frame="urn:ogc:crs:EPSG::5831"; or
> HEIGHT:coordinate_reference_frame="urn:ogc:crs:EPSG::5829";
> 5831 and 5829 can be resolved at http://www.epsg-registry.org/ but are not
> meant for human information. They're defined as 'depth (or height)
> relative to instantaneous
> water level, uncorrected for tide.'

The above is interesting. This and Rich's posting suggests that maybe part of
the difficulty is a different organisation of concepts in CF. Maybe this is
just my personal confusion, but I might not be the only one.

The standard_names of depth and height in CF are defined as meaning vertical
distance below and above "the surface". In stdnames, "the surface" means the
bottom of the atmosphere. So these concepts include a vertical datum. There is
no CF stdname for vertical distance above some surface to be specified in
another part of the metadata. All the stdnames which somehow involve a special
surface (like The Surface, the geoid, the tropopause, the top of the
atmosphere, the bedrock) identify it in the stdname itself.

However, some of these special surfaces might have to be more precisely
defined in extra metadata to accompany the standard name. This can already
be done for a reference ellipsoid, but not for a geoid.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Jonathan Gregory]

Dear Rich

> Yes, I think your answer before is the answer now, but I'm just clear
> on the details.  Would you specify sea_surface_height above NAVD88
> like this?
> 
> float zeta(y=1534, x=2122);
>   :standard_name = "sea_surface_height_above_reference_datum";
>   :grid_mapping = "Albers_Projection";
> 
> int Albers_Projection;
>   :grid_mapping_name = "albers_conical_equal_area";
>   :standard_parallel = 20.5, 27.5; // double
>   :longitude_of_central_meridian = -89.0; // double
>   :latitude_of_projection_origin = 24.0; // double
>   :false_easting = 0.0; // double
>   :false_north = 0.0; // double
>   :vertical_datum = 'urn:ogc:def:datum:epsg::5103'

I'm not clear still what NAVD88 is though. SSH must be above some surface. Is
this surface a reference ellipsoid or a geoid? These are two different standard
names:
  sea_surface_height_above_geoid
  sea_surface_height_above_reference_ellipsoid
whereas sea_surface_height_above_reference_datum is not an existing stdname.

If it's a reference ellipsoid, it can be described already by grid_mapping
parameters. To name a geoid, we'd need a new attribute of grid_mapping, but
I don't think that would be problematic.

Best wishes

Jonathan
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Signell, Richard]

Jonathan,

Yes, I think your answer before is the answer now, but I'm just clear
on the details.  Would you specify sea_surface_height above NAVD88
like this?

float zeta(y=1534, x=2122);
  :standard_name = "sea_surface_height_above_reference_datum";
  :grid_mapping = "Albers_Projection";

int Albers_Projection;
  :grid_mapping_name = "albers_conical_equal_area";
  :standard_parallel = 20.5, 27.5; // double
  :longitude_of_central_meridian = -89.0; // double
  :latitude_of_projection_origin = 24.0; // double
  :false_easting = 0.0; // double
  :false_north = 0.0; // double
  :vertical_datum = 'urn:ogc:def:datum:epsg::5103'


Something like that?

On Tue, Feb 4, 2014 at 10:08 AM, Jonathan Gregory
 wrote:
> Dear Rich
>
> Nothing further has been done in CF about this, but I'd be glad if it could 
> be,
> since it is often asked. I think there is no reason not to do something, since
> there is an evident need, if we could only agree what should be done, and the
> main problem is getting a sufficient understanding of these complexities. So
> I can only repeat my last para in the email you point to:
>
>> The discussion stalled because we didn't really understand what "vertical
>> datum" means! ... [If this concerns the definition of the geoid], we should
>> extend grid_mapping so it can identify the geoid by name, perhaps also giving
>> a URN as you say.  Unlike the ref ellipsoid, the geoid cannot be specified
>> by metadata, as it's too complicated!
>
> Is that the answer to your question of yesterday? i.e. would it suffice to
> specify that by "geoid" in this data, "NAVD88" was meant? Of course, in other
> datasets, geoid might mean a different definition. Specifying which geoid is
> meant is not always possible (for instance in the case of model data), but we
> could make it possible if that's useful. Is NAVD88 not a geoid name in your
> example?
>
> Best wishes
>
> Jonathan
>
> - Forwarded message from "Signell, Richard"  -
>
>> On a telecon yesterday with a coastal inundation modeling group, one
>> of the PIs asked me how to handle vertical datums in NetCDF --
>> specifically where to specify that the model bathymetry and water
>> levels were were relative to NAVD88.   I wasn't sure how to reply.
>>
>> Was there any resolution to the 2nd half of this question asked back in 2011?
>> http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/054483.html
>>
>> I looked at the draft 1.7 spec, and the only vertical datum reference
>> info I found was the ability to specify VERT_DATUM in the new CRS
>> well-known-text (WKT) section:
>> http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.7-draft1/ch05s06.html#idp5644304
>>
>> Is this how we should specify the vertical datum in CF, using VERT_DATUM in 
>> WKT?
>>
>> Thanks,
>> Rich
>> --
>> Dr. Richard P. Signell   (508) 457-2229
>> USGS, 384 Woods Hole Rd.
>> Woods Hole, MA 02543-1598
>> ___
>> CF-metadata mailing list
>> CF-metadata@cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
> - End forwarded message -
> ___
> CF-metadata mailing list
> CF-metadata@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
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Re: [CF-metadata] Vertical datums (again)

[Nan Galbraith]

This question certainly pops up on a regular basis.

After a discussion on the MMI 'Ask' metadata discussion list, OceanSITES
decided to add 2 attributes to the Z axis variable, one is 'reference', 
which
is intended for human readers, and the other is 
'coordinate_reference_frame',
which contains a URN that holds the definition of the 3D coordinate 
reference

system, which is, at least according to the EPSG, more useful than a simple
datum.

We are dealing only with data relative to instantaneous sea surface; we 
don't have
a mechanism for describing height above the sea floor, which we may need 
soon.


DEPTH:reference=;
where currently vetted values for R are  "mean_sea_level", 
"mean_lower_low_water",

"wgs84_geoid" and the default,  "sea_level".

DEPTH:coordinate_reference_frame="urn:ogc:crs:EPSG::5831"; or
HEIGHT:coordinate_reference_frame="urn:ogc:crs:EPSG::5829";
5831 and 5829 can be resolved at http://www.epsg-registry.org/ but are not
meant for human information. They're defined as 'depth (or height) 
relative to instantaneous

water level, uncorrected for tide.'

We'd be happy to implement this differently, if CF comes up with a scheme.

Thanks - Nan



On 2/4/14 10:08 AM, Jonathan Gregory wrote:

Dear Rich

Nothing further has been done in CF about this, but I'd be glad if it could be,
since it is often asked. I think there is no reason not to do something, since
there is an evident need, if we could only agree what should be done, and the
main problem is getting a sufficient understanding of these complexities. So
I can only repeat my last para in the email you point to:


The discussion stalled because we didn't really understand what "vertical
datum" means! ... [If this concerns the definition of the geoid], we should
extend grid_mapping so it can identify the geoid by name, perhaps also giving
a URN as you say.  Unlike the ref ellipsoid, the geoid cannot be specified
by metadata, as it's too complicated!

Is that the answer to your question of yesterday? i.e. would it suffice to
specify that by "geoid" in this data, "NAVD88" was meant? Of course, in other
datasets, geoid might mean a different definition. Specifying which geoid is
meant is not always possible (for instance in the case of model data), but we
could make it possible if that's useful. Is NAVD88 not a geoid name in your
example?

Best wishes

Jonathan

- Forwarded message from "Signell, Richard"  -


On a telecon yesterday with a coastal inundation modeling group, one
of the PIs asked me how to handle vertical datums in NetCDF --
specifically where to specify that the model bathymetry and water
levels were were relative to NAVD88.   I wasn't sure how to reply.

Was there any resolution to the 2nd half of this question asked back in 2011?
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2011/054483.html

I looked at the draft 1.7 spec, and the only vertical datum reference
info I found was the ability to specify VERT_DATUM in the new CRS
well-known-text (WKT) section:
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.7-draft1/ch05s06.html#idp5644304

Is this how we should specify the vertical datum in CF, using VERT_DATUM in WKT?

Thanks,
Rich
--
Dr. Richard P. Signell   (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

- End forwarded message -
___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata




--
***
* Nan GalbraithInformation Systems Specialist *
* Upper Ocean Processes GroupMail Stop 29 *
* Woods Hole Oceanographic Institution*
* Woods Hole, MA 02543 (508) 289-2444 *
***


___
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata