Re: [CF-metadata] Vertical datums (again)
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 Facebookhttp://www.facebook.com/cicsncJim Biard Research Scholar Cooperative Institute for Climate and Satellites NChttp://cicsnc.org/ North Carolina State Universityhttp://ncsu.edu/ NOAA's National Climatic Data Centerhttp://ncdc.noaa.gov/ 151 Patton Ave, Asheville, NC 28801 e: jbi...@cicsnc.orgmailto:jbi...@cicsnc.org o: +1 828 271 4900 On Mar 14, 2014, at 2:21 PM, Jonathan Gregory j.m.greg...@reading.ac.ukmailto: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 jbi...@cicsnc.orgmailto: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.edumailto: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)
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)
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 j.m.greg...@reading.ac.uk 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)
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 j.m.greg...@reading.ac.uk 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)
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 d.c.hass...@reading.ac.uk 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 j.m.greg...@reading.ac.uk 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)
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 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 http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
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
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
Re: [CF-metadata] Vertical datums (again)
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 j.m.greg...@reading.ac.uk 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
[CF-metadata] Vertical datums (again)
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
Re: [CF-metadata] Vertical datums (again)
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)
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 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 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
___
CF-metadata mailing list
Re: [CF-metadata] Vertical datums (again)
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 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
--
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)
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)
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 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 -- 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)
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 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
Re: [CF-metadata] Vertical datums (again)
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 j.m.greg...@reading.ac.uk 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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Tue, 11 Feb 2014 13:51:56 -0500 To: CF metadata cf-metadata@cgd.ucar.edu X-Mailer: Apple Mail (2.1827) CC: Karl Taylor taylo...@llnl.gov 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
Re: [CF-metadata] Vertical datums (again)
Biard jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Tue, 11 Feb 2014 13:51:56 -0500 To: CF metadata cf-metadata@cgd.ucar.edu X-Mailer: Apple Mail (2.1827) CC: Karl Taylor taylo...@llnl.gov 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 taylo...@llnl.gov 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 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
Re: [CF-metadata] Vertical datums (again)
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
[CF-metadata] Vertical datums (again)
Dear Balaji I understand it's blurry, and I suppose all I'm arguing for is some general vigilance against proliferation of names. I completely agree with that sentiment! The blurriness comes in places where coordinates are discrete, from a permissible set, such as area_types. This was done to avoid proliferation of standard names, and because it can be convenient to have a dimension of area_type. I don't think there are the same advantages in the case of height above ground vs height above geoid - there's only a small handful of different species of height and they are not likely to be wanted as group together in a data variable. (BTW when are we going to see a standard_name with barystatic in it?) Good question! I hope that if it happens it's because of global mean sea level change rather than Star Trek invading the CF convention. 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)
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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Tue, 11 Feb 2014 13:51:56 -0500 To: CF metadata cf-metadata@cgd.ucar.edu X-Mailer: Apple Mail (2.1827) CC: Karl Taylor taylo...@llnl.gov 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 taylo...@llnl.gov 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 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
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 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 mailto:jbi...@cicsnc.org o: +1 828 271 4900 On Feb 11, 2014, at 1:44 PM, Karl Taylor taylo...@llnl.gov mailto:taylo...@llnl.gov 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 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 Feb 11, 2014, at 11:43 AM, Jonathan Gregory j.m.greg...@reading.ac.uk 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
Re: [CF-metadata] Vertical datums (again)
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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Tue, 11 Feb 2014 13:51:56 -0500 To: CF metadata cf-metadata@cgd.ucar.edu X-Mailer: Apple Mail (2.1827) CC: Karl Taylor taylo...@llnl.gov 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 taylo...@llnl.gov 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 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
[CF-metadata] Vertical datums (again)
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 eda...@unidata.ucar.edu - Date: Wed, 12 Feb 2014 10:43:46 -0700 From: Ethan Davis eda...@unidata.ucar.edu 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
Re: [CF-metadata] Vertical datums (again)
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 eda...@unidata.ucar.edu - Date: Wed, 12 Feb 2014 10:43:46 -0700 From: Ethan Davis eda...@unidata.ucar.edu 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)
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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Tue, 11 Feb 2014 13:51:56 -0500 To: CF metadata cf-metadata@cgd.ucar.edu X-Mailer: Apple Mail (2.1827) CC: Karl Taylor taylo...@llnl.gov 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 taylo...@llnl.gov 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 Climate and Satellites
Re: [CF-metadata] Vertical datums (again)
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 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
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 taylo...@llnl.gov 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 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
Re: [CF-metadata] Vertical datums (again)
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)
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 j.m.greg...@reading.ac.uk 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)
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 j.m.greg...@reading.ac.uk 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)
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)
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 mark.hed...@metoffice.gov.uk 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)
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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Fri, 7 Feb 2014 10:38:23 -0500 To: CF metadata cf-metadata@cgd.ucar.edu 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 mark.hed...@metoffice.gov.uk 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
Re: [CF-metadata] Vertical datums (again)
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 j.m.greg...@reading.ac.uk 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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Fri, 7 Feb 2014 10:38:23 -0500 To: CF metadata cf-metadata@cgd.ucar.edu 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 mark.hed...@metoffice.gov.uk 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
Re: [CF-metadata] Vertical datums (again)
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 jbi...@cicsnc.org 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 j.m.greg...@reading.ac.uk 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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Fri, 7 Feb 2014 10:38:23 -0500 To: CF metadata cf-metadata@cgd.ucar.edu 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
Re: [CF-metadata] Vertical datums (again)
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 rsign...@usgs.gov 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 jbi...@cicsnc.org 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 j.m.greg...@reading.ac.uk 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 jbi...@cicsnc.org - From: Jim Biard jbi...@cicsnc.org Date: Fri, 7 Feb 2014 10:38:23 -0500 To: CF metadata cf-metadata@cgd.ucar.edu 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
Re: [CF-metadata] Vertical datums (again)
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)
Dear Nan DEPTH:reference=R; 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)
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=R; 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 rsign...@usgs.gov - 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
Re: [CF-metadata] Vertical datums (again)
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 j.m.greg...@reading.ac.uk 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 rsign...@usgs.gov - 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
