At the NOAA Coast Survey Development Laboratory, we have been developing
a tool to transform between different vertical datums such as Sea Level,
Mean Lower Low Water, NAD-83, NAVD 88 etc. etc.
http://nauticalcharts.noaa.gov/csdl/Vdatum.htm
Given the wealth of datums available, I am of the opinion that a surface
such as, "sea_surface_height", should not include the datum in the
standard name. It is an attribute of the variable. I would much rather
have a codified attribute sea_surface_height:Datum="sea_level" . This
affords the ability to include the datum transformation variable to be
included elsewhere in the netcdf file
Variable ZETA(time,nx,ny)
ZETA:Datum="sea_level"
Variable MLLW(nx,ny)
MLLW:Standard_Name="Mean_Lower_Low_Water"
MLLW:Datum="sea_level"
Variable NAD83(nx,ny)
NAD83:Standard_Name="NAD_83"
NAD83:Datum="sea_level"
This allows the user to transform ZETA out of "sea_level" to MLLW or
NAD_83 by a subtraction.
PS It is a very important fact that the MLLW datum is not spatially
constant. This is the whole problem with creating coherent digital
elevation models that join the NOAA/OCS hydrography with USGS topography
data.
Tom Gross
Chesapeake Community Model Program
ccmp.chesapeake.org
Chesapeake Research Consortium
P.O. Box 28
645 Contees Wharf Road
Edgewater, MD
temporary Phone: 443 482 2200 x2490
410-798-1283
or on Monday and Tuesdays
tom.gross at noaa.gov
NOAA/NOS/Coast Survey Development Lab.
Silver Spring, MD (301) 713-2809 x139
-----Original Message-----
From: cf-metadata-bounces at cgd.ucar.edu
[mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jonathan Gregory
Sent: Tuesday, February 07, 2006 2:47 PM
To: cf-metadata at cgd.ucar.edu
Subject: [CF-metadata] CF2 and standard names
Dear Bert
Thanks for your questions.
> when it comes to the use of standard names, I'm still not certain what
to do.
Standard names, like most features of CF, are optional. You don't have
to use
them if you don't think they will help you.
> some kind of standardisation can
> be helpful for users to understand model output from various sources
and as
> such it may be a valuable source of information when setting up a
coupling
> between model components of different origin
That is the first reason to your question
> (1) what are the main reasons for using standard names
It's not only for coupling, but for any activity where data from
different
sources is to be brought together, for example in the comparative
analysis of
data from various climate models. The second reason is that within a
data
source, standard names may be a convenient and precise help in
distinguishing
among quantities.
> I feel a bit uneasy about
> introducing the standard name "sea_surface_height_above_sea_level" in
the
> output of modelling systems that have so far been using "water level"
or
> similarly simple looking phrasings.
You know what you mean by "water level" in the context of your own
model, but
the standard name is a more precise description of a particular
quantity.
However, it may not be the quantity you want, or precise enough for your
purposes. We should introduce further standard names which are more
appropriate
for other kinds of application, as they arise. There is an awkwardness
about
"lake", "sea" and "river" which we haven't properly dealt with yet. The
choice
of "sea" reflects the origin of the standard names. Some word was needed
to
distinguish water in the atmosphere (as cloud or vapour) from water in
the
ocean.
> reference level is not everywhere the same: a
> river in Tibet may be modelled using a completely different reference
level
> than a lowland river like the Rhine or the Mississippi.
Quite right. It has previously been proposed that we should have a
facility,
via a standard name parameter, to specify the reference surface. This is
not
necessary in all applications (for instance in climate models, which
have
idealised Earth geometry), so it should be optional. Different kinds of
application require different levels of precision, so standard naming
has to
offer such levels.
> (3) or, wouldn't it be better to define a name space and some mapping
as has
> been suggested in relation to CF2 standards
If sufficiently precise names exist in other domains, we could devise
some way
of mapping them into the standard name space. This would save effort and
duplication in the community. However we have to be careful that in
doing this
we don't accidentally allow different domains to give alternative names
to the
same quantity without the equivalence being noted, because if that
happened the
names would not be useful for their original purpose of indicating which
data
are comparable.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Feb 08 2006 - 08:30:18 GMT
