[CF-metadata] Re: CF NetCDF Conventions

From: Jonathan Gregory <jonathan.gregory>
Date: Thu, 11 Apr 2002 09:42:24 +0100

Dear Alan and Brian

Thank you for your emails. Sorry I have been so long in replying. I am
grateful for Alan's comments and I agree with Brian's answers except for (a).

> a) All the examples apply the "coordinates" attribute to data variables.
> This is obviously required for two-dimensional cases (latitude, longitude),
> but a one dimensional alternative coordinate could presumably be applied
> to the coordinate variable and inherited by any data variable that used
> this axis. Is this allowed? If so, there should be examples and a
> discussion of this approach.

> > a) I like this suggestion. I think it's more robust to have 1-D alternate
> > coordinates attached to the appropriate coordinate variable rather than to
> > the data variable. Consider the example in section 6.2. If an application
> > takes a horizontal slice of the xwind variable and produces an new
> > variable, say xwind1(sig1,lat), then the coordinates attribute of xwind is
> > no longer appropriate for xwind1. But applications generally just copy
> > the attributes of the input variable to the output variable, which in this
> > case is not the right thing to do. This problem is avoided by attaching
> > the coordinates attribute to the sigma variable rather than to xwind.
> > Ideally of course the applications will be smart enough to slice the
> > alternate coordinates as well. But in the meantime...

I appreciate the point of this suggestion, but on balance I am not in favour
of it, for two reasons:

* It makes the standard and hence the data-reading software more complicated,
because of the need to look both on the data variable and on the coordinate
variable for coordinates attributes.

* It could lead to inappropriate attribution of coordinates, or alternatively
more effort to avoid such misattribution. For instance, if you have two
quantities on the same trajectory, say temperature(time) and humidity(time),
they can share the auxiliary coordinates lat(time) lon(time) height(time),
which can therefore be named by a coordinates attribute of the time(time)
coordinate variable. That's fine - it is the point of the proposal. But now
suppose you have a separate trajectory with the same sample times. Because it
has different lat lon and height, it cannot share the time coordinate var,
even though the dimension and all the values are identical. Upon adding the
second trajectory to the file, you would therefore have to detect this, and
duplicate the time axis. You'd have to do the same thing if you wanted to
include any quantity measured at the same times but not along the trajectory.
For example, you might have in the same file a gridded field of surface pressure
pstar(time,xlat,xlon). Again, it can't use the same time dimension, because of
the implicit and inappropriate association with lat, lon and height that would
arise.

It seems to me that the duplication, or the need to work out when this new
facility can be used, is potentially more of a nuisance to data-writing
software than the need to avoid indiscriminately copying the coordinates
attribute. Also, inappropriate copying such as the kind which Brian mentioned
can be quite easily detected by the data-reading software, because the
auxiliary coordinate variable has a dimension which is not a dimension of the
data variable, and is therefore illegal.

> d) I have no objection to adding the "all_leap" calendar.
Would it be a significant pitfall that all_leap has a _ and noleap doesn't?

Best wishes

Jonathan
Received on Thu Apr 11 2002 - 02:42:24 BST