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:
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.
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.
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.
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
>
>
--
Dale Robinson, Ocean Observing Programs Coordinator
Romberg Tiburon Center
3152 Paradise Drive
Tiburon, CA 94920
email dhr.sfsu at gmail.com
http://sfbeams.sfsu.edu
Received on Fri Sep 12 2008 - 11:42:51 BST
