Hi all,
Dale Robinson wrote:
> Thank you Johnathan et al. for your great comments and suggestions.
>
> I like Johnathan?s suggestions very much. They seem straightforward,
> especially for people who are not experts in vertical datums or in the
> logic of the CF convention.
>
> I will address Johnathan?s points one at a time below. I certainly am
> not knowledgeable in the correct usages of CF stn. names and
> attributes and I don?t want to sidetrack the discussion by suggesting
> inappropriate usages. Therefore, I will restrict my comments to my
> role as a user of the CF convention and a data provider.
>
>
> 1) Johnathan: ?I think that height above geoid (altitude) and height
> above reference ellipsoid are different geophysical quantities and do
> need different standard names?
>
> Yes, I agree. Looking at the std. names table I see the following
> ?height? terms:
I disagree on this. Both are distances above a reference surface that is
used as the zero level. A vertical datum is a reference from which to
measure height and/or depth. Vertical datums can be based on ellipsoids,
tidal measurements (e.g., EPSG datum 5111, "Australian Height Datum",
description: "MSL 1966-68 at 30 gauges around coast."), a set of station
locations (e.g., EGSG datum 5102, "National Geodetic Vertical Datum
1929", description: "26 tide gauges in the US and Canada."), or a geoid
(e.g., WGS 84 EGM96 geoid, which EPSG calls datum 5203).
Two good links on Wikipedia:
http://en.wikipedia.org/wiki/Geodetic_system
http://en.wikipedia.org/wiki/Datum_(geodesy)
And then there's the WGS84 report, linked from
http://earth-info.nga.mil/GandG/wgs84/gravitymod/index.html
> a. geopotential_height
> Geopotential is the sum of the specific gravitational potential energy
> relative to the geoid and the specific centripetal potential energy.
> Geopotential height is the geopotential divided by the standard
> acceleration due to gravity. It is numerically similar to the altitude
> (or geometric height) and not to the quantity with standard name
> height, which is relative to the surface.
I do agree this is a different geophysical quantity. But there still
should be a way to define the particular geoid from which potential
energy is being measured.
> b. height
> Height is the vertical distance above the surface.
>
> c. altitude
> Altitude is the (geometric) height above the geoid, which is the
> reference geopotential surface. The geoid is similar to mean sea level.
>
> Unless I am missing something, what seems to be missing here is a term
> for Geodetic or Ellipsoidal height.
>
> *d. ellipsoidal_height *
> Height of a point above the reference ellipsoid
>
> Speaking as a user of CF, the lack of this term seems to be a gap in
> the standard names that should be filled. The inclusion of this term
> was deemed important when describing sea surface height; both
> sea_surface_height_above_geoid and
> sea_surface_height_above_reference_ellipsoid standard names are
> included in CF. Therefore, I suggest including a term like
> height_above_reference_ellipsoid or ellipsoidal_height.
>
> 2) Johnathan: ?If you have a *data* variable with the standard name of
> altitude, for instance, you might want to identify the geoid? What if
> we allowed the grid_mapping_name to be optional if the grid mapping
> was included only in order to describe the geoid or reference ellipsoid??
>
> Yes. I don?t know about the method (grid_mapping_name), but it does
> seem that if you define something as ?height above the geoid? or
> ?height above the reference ellipsoid?, a user would want to know
> which geoid or reference ellipsoid.
I agree that data variables as well as vertical coordinate variales
should be able to reference/define a vertical datum.
Expanding the grid mapping section to deal with vertical datum seems
like a good option. However, I think we are going to want to name
vertical datum as well. Perhaps we should expand the "Horizontal CRS,
Grid Mappings, and Projections" section to deal with vertical CRS as
well by adding a vertical_datum_name attribute similar to the
grid_mapping_name attribute. This gets complicated by the fact that
grid_mapping can define 2-D or 3-D CRS and you might want to combine the
same 2-D horiz CRS with multiple 1-D vertical CRS.
> 3) ?The fact the Dale wants to distinguish the various tidal datums
> shows that they define distinct quantities.?
>
> When I think about it, yes they seem to be distinct quantities. The
> range of mean lower low water and mean higher high water varies from
> location to location. A user of the data may not know what the offsets
> among datums are in a particular area. Heights referenced to these
> datums (especially MLLW) are very important to local users of the
> data. As a user of the CF convention and netCDF, I want to make sure
> that the people using my data can convert the height values we give
> them into values most useful to them. So inclusion of an offset
> variable, especially one so intuitively named
> (altitude_of_mean_low_water) would help me and many of the users of my
> data immensely.
Even if the user doesn't know the offsets between two tidal datums, they
do exist. To me, that doesn't seem like enough of a difference to
consider them distinct quantities.
Ethan
> In summary, a set of std. names and attributes that allows the
> following would help me as a user of CF and the users of my data:
> - height relative to the ellipsoid
> - name of the ellipsoid
> - height relative to the geoid
> - name of the geoid
> - altitude of (offset to) other common datums (e.g. MLLW)
>
>
> I don?t know how to correctly format the following within the CF
> convention, but I?ll take a chance below based on Johnathan?s
> suggestions. No doubt it is incorrectly formulated, but I think you
> will see what I am getting at.
>
> float ellips_height;
> ellips_height:standard_name="ellipsoidal_height? // i.e.
> height_above_reference_ellipsoid
> ellips_height:grid_mapping="ellipsoid";
>
> float altitude; // data variable
> altitude:standard_name="altitude";
> altitude:grid_mapping="geoid";
>
> float alt_mllw; // offset variable
> alt_mllw:standard_name="altitude_of_mean_lower_low_water ";
>
> char geoid; // grid mapping variable
> geoid:geoid_name="geoid03";
>
> char ellipsoid; // grid mapping variable
> ellipsoid: ellipsoid_name="WGS84";
>
>
> Thanks.
>
> -Dale
>
>
>
> Dear Dale et al.
>
> You're quite right, altitude is height above geoid. Hence the names
> for the
> tidal datums should be altitude_of_DATUM, which is neater. We should
> spell
> them out, I think e.g. altitude_of_mean_low_water, as we generally avoid
> abbreviations in standard names for the sake of intelligibility by
> people who
> aren't experts in the relevant area.
>
> The way you propose to use attribute ancillary_variables isn't quite
> what it
> was intended for, I think. Do you envisage there could be several data
> variables in the file giving alternative values for a particular
> offset? If
> so, I can appreciate there may be a need for a link. But if there is
> only one,
> is a link required? You could find the variable you want by examining the
> standard names.
>
> While I think that it's better not to have different standard names for
> altitude wrt different geoids as I would consider them to be varying
> definitions of the same geophysical quantity, I think that height
> above geoid
> (altitude) and height above reference ellipsoid are different geophysical
> quantities and do need different standard names. Hence I would not be in
> favour of a generic "height above vertical datum". I don't think that is
> sufficiently well-defined to have a standard name. I also think that
> "height
> above reference ellipsoid" is a different quantity from "height above
> mean low
> water" etc. The fact the Dale wants to distinguish the various tidal
> datums
> shows that they define distinct quantities.
>
> Ethan argues for putting the definition of vertical coordinate system
> with
> vertical coordinate variables, not in the grid mapping, which is so
> far for
> horizontal coordinate systems. I would note that
>
> * we have already defined the ellipsoid in the grid mapping. To define it
> separately somewhere else, even if only by name, could be confusing or
> inconsistent.
>
> * it's not needed only for vertical coordinate variables. If you have
> a *data*
> variable with the standard name of altitude, for instance, you might
> want to
> identify the geoid.
>
> However I do feel that it's a bit cumbersome to introduce a grid_mapping
> variable with a "dummy" horizontal coordinate system just to name the
> geoid.
> What if we allowed the grid_mapping_name to be optional if the grid
> mapping
> was included only in order to describe the geoid or reference ellipsoid?
>
> float altitude; // data variable
> altitude:standard_name="altitude";
> altitude:grid_mapping="geoid";
> char geoid; // grid mapping variable
> geoid:geoid_name="WGS84";
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
>
> Jonathan Gregory wrote:
>> Dear Dale et al.
>>
>> You're quite right, altitude is height above geoid. Hence the names
>> for the
>> tidal datums should be altitude_of_DATUM, which is neater. We should
>> spell
>> them out, I think e.g. altitude_of_mean_low_water, as we generally avoid
>> abbreviations in standard names for the sake of intelligibility by
>> people who
>> aren't experts in the relevant area.
>>
>> The way you propose to use attribute ancillary_variables isn't quite
>> what it
>> was intended for, I think. Do you envisage there could be several data
>> variables in the file giving alternative values for a particular
>> offset? If
>> so, I can appreciate there may be a need for a link. But if there is
>> only one,
>> is a link required? You could find the variable you want by examining
>> the
>> standard names.
>>
>> While I think that it's better not to have different standard names for
>> altitude wrt different geoids as I would consider them to be varying
>> definitions of the same geophysical quantity, I think that height
>> above geoid
>> (altitude) and height above reference ellipsoid are different
>> geophysical
>> quantities and do need different standard names. Hence I would not be in
>> favour of a generic "height above vertical datum". I don't think that is
>> sufficiently well-defined to have a standard name. I also think that
>> "height
>> above reference ellipsoid" is a different quantity from "height above
>> mean low
>> water" etc. The fact the Dale wants to distinguish the various tidal
>> datums
>> shows that they define distinct quantities.
>>
>> Ethan argues for putting the definition of vertical coordinate system
>> with
>> vertical coordinate variables, not in the grid mapping, which is so
>> far for
>> horizontal coordinate systems. I would note that
>>
>> * we have already defined the ellipsoid in the grid mapping. To
>> define it
>> separately somewhere else, even if only by name, could be confusing or
>> inconsistent.
>>
>> * it's not needed only for vertical coordinate variables. If you have
>> a *data*
>> variable with the standard name of altitude, for instance, you might
>> want to
>> identify the geoid.
>>
>> However I do feel that it's a bit cumbersome to introduce a grid_mapping
>> variable with a "dummy" horizontal coordinate system just to name the
>> geoid.
>> What if we allowed the grid_mapping_name to be optional if the grid
>> mapping
>> was included only in order to describe the geoid or reference ellipsoid?
>>
>> float altitude; // data variable
>> altitude:standard_name="altitude";
>> altitude:grid_mapping="geoid";
>> char geoid; // grid mapping variable
>> geoid:geoid_name="WGS84";
>>
>> Cheers
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
>
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: edavis at ucar.edu
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
Received on Fri Sep 12 2008 - 14:07:53 BST
