I have been considering Bryan's point some more:
The only reason I can see here, and it seems to be the one you are espousing,
is that it's a convenience for someone importing their data - they want the
standard name to be the name they used to use - but why? It's rarely the case,
so why does it have to happen here?
I don't think this is the reason I am bringing this issue up, it is not a
matter of convenience. To me the matter is of what the standard name is there
to do: in my view to explicitly identify the phenomenon described by the
variable.
A vector component of a phenomenon is what has to be defined. In my mind there
are two cases:
1. where the vector component is aligned to the data grid
2. where the vector component is not aligned to the data grid
These are importantly different to me as a data consumer. For example, with
numerical model output: 1. is very likely to be solved directly by the model,
2. is very likely to e derived during post processing from other output.
Currently I can encode 1. in all cases, but I have to use different standard
names dependent on the definitions of my coordinate variables; 2. can only be
encoded if my component direction is east/north and my data grid does not
include east or north as coordinate direction.
I am content that I cannot encode 2. in all cases, as to encode a vector
component in an arbitrary direction is a non trivial matter. My desire is to
explicitly code case 1 as a particular standard name. I think this is the
phenomenon I want to identify, all other required information is able to be
extracted from the data variable and its associate variables as required.
There are particular issue here with format interoperability and conversion
with respect to phenomenon. In GRIB2, for example, there are codes which
identify vector components:
Wind direction (from which blowing) degree true
Wind speed ms
u-component of wind ms
v-component of wind
but no code for eastward_...
The current situation poses significant challenges for GRIB - CF
interoperability.
As a data consumer, and software writer, I want to be able to use the
convenience of not inspecting the coordinate variable when I find eastward_wind
as a standard name!
My perspective as a data consumer is that I want to know when my data is a
vector component using the same grid definition as my data. If that turns out
to be east, that's a useful piece of downstream information, not a core part of
the phenomenon definition.
mark
-----Original Message-----
From: Jon Blower [mailto:[email protected]]
Sent: Fri 20/04/2012 18:46
To: Hedley, Mark; [email protected]
Subject: RE: [CF-metadata] identification of vector components
Hi Mark, all,
I've just re-read the wording of the "_x_" standard names. The wording used is "along the
grid x-axis, when this is not true longitude". I have to say I don't like this form of words at all.
What is meant by "true longitude"? I'd probably need to understand this meaning before figuring
out what changes may be useful. Can anyone help?
Irrespective of the distinction between "_eastward_" and "_x_" it might be worth
discussing whether this form of words needs to change. It doesn't seem to sit very well with the
introduction of "proper GIS" concepts into CF, and I guess it's a consequence of the GCM-centric
history of CF.
Cheers, Jon
-----Original Message-----
From: Hedley, Mark [mailto:[email protected]]
Sent: 20 April 2012 17:43
To: Jon Blower; [email protected]
Subject: RE: [CF-metadata] identification of vector components
Hello Jon
I.e. I think Bryan has a point when he says (or as I interpret): "if I see x_wind I
expect to inspect the coordinate variable, if I see eastward_wind I don't". I think
this is a useful distinction.
I think this distinction is maintained, eastward is a term always meaning east
with respect to geographic longitude. The capability I would like is to be
allowed to use x-wind, even if x may mean east in some way. As such, any time
'x' is seen, then the coordinate variable must be inspected. When eastward is
seen I it is clear that the coordinates do not need to be inspected.
The key aspect about x-wind is that it is defined with respect to the
coordinate variables, it is a coordinate variable direction. Eastward is the
ambiguous term, as it may or may not be in a coordinate variable direction,
depending on the definition of the coordinates.
The coordinates are crucial to defining the degrees of freedom of the data,
part of its characteristic. I believe the definition of vector components
should recognise this.
What would one do in the case of a precisely-specified lat-lon system, e.g. a
WGS84 system? Would this be encoded as a projection, and would we use x_wind
in this case?
I don't think WGS84 is a projection, I would call it a geographic coordinate
system. I would like to encode data using WGS84 as a coordinate reference
system and define my vectors as x and y
What about, say, British National Grid, where the eastings and northings are
oriented (roughly) east and north? Would eastward_wind be allowable?
This is a good example of an ambiguity: data modelled on a British National
Grid lattice has x_wind and y_wind. The x and y are nearly but not quite
eastward. I think the standard_name table would mandate x and y for such
variables, but the vector directions are pretty close to east and north.
(I guess I'm driving toward the suggestion that eastward_wind only be allowed
for the implicit lat-lon grid that CF allows and tends to be the default in the
GCM community.)
In this case I would like to use x_wind. The x direction is what characterises
my data, the fact that that direction is eastward is secondary information
which is encoded in the data, as in this case x is eastward everywhere.
The standard name table description
(http://cf-pcmdi.llnl.gov/documents/cf-standard-names/about) includes the
statement:
'It is expected that the table will expand by the addition of new entries, but
existing entries will always continue to be valid. If it becomes desirable to
introduce a new name for a quantity which has already been named, the old name
will be defined as an alias of the new name'
I think what I am proposing is that eastward_* entries are kept as standard
names. In cases where eastward==x then this name is treated as an alias to x_*
I believe alias are still valid to use, and certainly maintain backwards
compatibility. This enables data producers to produce datasets with x_* vector
components without having to inspect the coordinate definitions to see if it is
invalid or worry if it is partially invalid, which can add significant
complexity to data writing and conversion processes.
all the best
mark
-----Original Message-----
From: [email protected] on behalf of Jon Blower
Sent: Thu 19/04/2012 17:39
To: [email protected]
Subject: Re: [CF-metadata] identification of vector components
Hi all,
I started off agreeing with Mark in this discussion and thought that eastward_wind should be a
special case of x_wind. However, I'm not so sure now. "eastward" is a suitably
imprecise concept to go with the suitably-imprecise definition of "longitude" in CF
(hence its evolution I guess). If the coordinate system is more precisely specified as a defined
projection with a projection_x_coordinate, then x_wind seems appropriate.
I.e. I think Bryan has a point when he says (or as I interpret): "if I see x_wind I
expect to inspect the coordinate variable, if I see eastward_wind I don't". I think
this is a useful distinction.
What would one do in the case of a precisely-specified lat-lon system, e.g. a
WGS84 system? Would this be encoded as a projection, and would we use x_wind
in this case? What about, say, British National Grid, where the eastings and
northings are oriented (roughly) east and north? Would eastward_wind be
allowable?
(I guess I'm driving toward the suggestion that eastward_wind only be allowed
for the implicit lat-lon grid that CF allows and tends to be the default in the
GCM community.)
Thoughts?
Jon
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Hedley, Mark
Sent: 19 April 2012 12:51
To: [email protected]
Subject: Re: [CF-metadata] identification of vector components
The problem I have with what you are proposing is that we would then
potentially have two different standard names for the *same* quantity, and
until such time as we have a way of handling that properly, we ought not do it.
I do not feel uncomfortable about this. I feel that this situation already
exists in a number of situations.
For example, there are ocean models which use a tri-polar horizontal model
grid, with 2 northerly poles and a normal south pole. The consequence of this
grid for vector components is as follows:
- in the southern hemisphere:
- x == eastward
- y == northward
- in the northern hemisphere
- x != eastward
- y != northward
- the amount of discrepancy changes as either of the northerly poles is
approached
The Ocean models I know of write out vector components as x-<standard_name> and
y-<standard_name> so in some locations x is east and in other locations it is not
I suspect there are other datasets created where x may mean east.
I feel it is a better compromise to allow x to mean east and encourage data
consumers to be careful in interpreting vector components. I believe that
https://cf-pcmdi.llnl.gov/trac/ticket/79 will help data consumers with this.
mark
-----Original Message-----
From: Bryan Lawrence [mailto:[email protected]]
The problem I have with what you are proposing is that we would then
potentially have two different standard names for the *same* quantity, and
until such time as we have a way of handling that properly, we ought not do it.
Cheers
Bryan
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:[email protected]]
Sent: Wed 18/04/2012 11:34
To: [email protected]
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: [email protected] on behalf of Hedley, Mark
Sent: Thu 05/04/2012 17:35
To: [email protected]
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
_______________________________________________
