Just a quick interjection from a primarily altimetric background. These definitions seem to fit well with requirements for satellite altimetry measurements.
Whilst it is true that the specifics of the geoid used (model, degree and order of expansion etc) are important, simply being able to correctly identify 'sea surface height above reference ellipsoid' vs 'sea surface height above geoid' gives us fundamentally different parameters (first is approx = geoid height, second is dynamic topography) Hence even without the details of the geoid used, the very definition is extremely important There is a significant difference in that altitude is generally applied to the height of the satellite above the reference ellipsoid - not the geoid - so I would not like to see that alias be included. Helen On 17 Feb 2014, at 21:10, John Graybeal <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected]<mailto:[email protected]> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ________________________________ This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
