Hello Bryan
Sorry, silence doesn't mean consent.
I didn't think it did, but prodding that notion can encourage people to pitch
in.
My reasoning is that I do not think it is the responsibility of the standard name to
define what is meant by x. The initial parts of the definition in the table:
'"x" indicates a vector component along the grid x-axis' ... ', positive with
increasing x'; say everything there is to say.
It is the responsibility of the coordinate and grid_mapping variables to define
what 'x' means.
Rather than this we have the case now where significant metadata inspection on
coordinate system and coordinate is required to determine the correct
standard_name from two mutually exclusive choices when writing CF NetCDF. This
feels to me to be an unnecessary complication which delivers little benefit
from a data and metadata definition perspective.
If you are importing something where x is used as the coordinate, and it is
longitude, then why not put that in other metadata?
I would say that I have defined this explicitly, using the approach I propose.
I define that the data variable is x-wind and I define that x is longitude,
therefore I can infer that the x-wind data variable is eastward wind, with
respect to the defined grid_mapping. Forcing me to put it in the standard_name
adds complexity to software which writes data and increases the opportunity for
data to be written incorrectly.
For example, does the cf_checker cross reference the 'x' coordinate and any
standard names to ensure that datasets defined with respect to a true longitude
coordinate variable do not use standard names with the 'x' modifier?
The you say x, I say x, and we both mean different things, is what we need to
avoid
This cannot be avoided, in almost all cases x means different things in
different datasets. It can even mean different things in the same file.
in particular we must not change definitions of existing quantitities.
I don't think that it is safe to make that strong a statement on definition
changes over time. I can understand the desire to avoid invalidating datasets
by narrowing definitions after they are defined; but I don't think that a
constrained broadening of the definition of a modifier should be refused on
principle. Such changes sometimes need to take place to keep the standard as
applicable to its community as possible.
That's not to say 'eastward' isn't a useful standard name: there is a good case
for model intercomparison, as there is no guarantee that my 'x' is anything
like your 'x' for a given dataset: we can agree to publish data as 'eastward'
to allow quick and easy intercomparison.
even this becomes slightly problematic at small scales, as eastward is with
respect to a coordinate reference system, so my east may be subtly different
from yours.
many thanks
mark
-----Original Message-----
From: Bryan Lawrence [mailto:bryan.lawre...@ncas.ac.uk]
Sent: Wed 18/04/2012 11:34
To: cf-metadata@cgd.ucar.edu
Cc: Hedley, Mark
Subject: Re: [CF-metadata] identification of vector components
Hi Mark
Sorry, silence doesn't mean consent.
I think it is exactly the place of standard names to be completely proscriptive
about what terms mean.
The you say x, I say x, and we both mean different things, is what we need to
avoid, and in particular we must not change definitions of existing
quantitities.
Admittedly, your change wouldn't strictly change anything retrospectively,
since it's an inclusive change, but it's probably a dangerous thing to do. (My
sense of deja vu tells me we've been here before, and I may even have been on
the other side of the argument :-).
If you are importing something where x is used as the coordinate, and it is
longitude, then why not put that in other metadata? The point of the CF
standard is that it just that ....
Bryan
There have not been any responses to this post in the last 10 days.
I know that this is a dangerous philosophy, but can I suggest that, in this
case, silence equals consent?
If it is, I would like to see these amendments in the standard_name
publications as soon as possible. Would this cause concern?
many thanks
mark
-----Original Message-----
From: cf-metadata-boun...@cgd.ucar.edu on behalf of Hedley, Mark
Sent: Thu 05/04/2012 17:35
To: cf-metadata@cgd.ucar.edu
Subject: [CF-metadata] identification of vector components
There is a statement in the definition of many standard names which are used
for vector component definitions, e.g.:
x_wind
alias: grid_eastward_wind
"x" indicates a vector component along the grid x-axis, when this is not
true longitude, positive with increasing x. Wind is defined as a two-dimensional
(horizontal) air velocity vector, with no vertical component. (Vertical motion in the
atmosphere has the standard name upward_air_velocity.)
I think that the statement 'when this is not true longitude' is problematic,
particularly for software converting from other formats, where x indicates the
grid i direction, independent of rotation or projection. I do not think it is
the place for standard_name to limit the use of the term 'x' to cases where the
horizontal coordinate reference system is not 'true latitude longitude'
I propose that these terms be removed from all standard names which have 'x' or
'y' as a modifier.
This would enable all x-ward and y-ward definitions to be used, independent of
the grid_mapping, as standard names.
eastward and northward remain useful modifiers as many models may choose to
output eastward vector components where east is not the x direction for the
model grid.
The work on vector containers in:
https://cf-pcmdi.llnl.gov/trac/ticket/79
has indicated a good way forward for identifying vector components, and
identifying that vectors are with respect to a grid_mapping. I think this
proposed change would interface nicely to the proposal in ticket 79
How would this proposal be viewed by the community?
mark
_______________________________________________
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
--
Bryan Lawrence
University of Reading: Professor of Weather and Climate Computing.
National Centre for Atmospheric Science: Director of Models and Data.
STFC: Director of the Centre for Environmental Data Archival.
Ph: +44 118 3786507 or 1235 445012; Web:home.badc.rl.ac.uk/lawrence
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
