Hi Alan,
Thanks for your comments. I've responded to each of your points below.
CF co-authors: points a) and d) contain changes that I'd like to make to
the document. Please let me know whether or not you agree.
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...
b) As you observed, the cell_method is a property of the data and not of
the axis. An axis with a bounds attribute may be used by data variables
that are representing point values as well as by other data variables that
represent various cell properties.
The interpretation of cell_method is already complicated by the fact that
the default methods depend on whether the data variable is an extensive or
intensive quantity of the cell. My feeling is that providing another layer
of possible default values adds to the complexity without adding any
descriptive power to the convention. I understand that the suggestion is
to add convenience, and not descriptive power. But in this case the
convenience must be traded off against adding complexity.
c) We agonized over this. In the end the decision was made that
conformance to COARDS was more important than the added convenience of the
new time representation. We decided that the convenience of the calendar
based time representations should be addressed by the utilities that read
and write the data. Admittedly it will take some time before these
utilities are developed.
d) I have no objection to adding the "all_leap" calendar.
After discussion with the ferret developers we decided to change "360" to
"360_day". They raised "sematic objections" to using a pure number as a
calendar name. My preference would be not to reintroduce pure numbers as
calendar names. But I have no objection to allowing "366_day" as an alias
for "all_leap", and "365_day" as an alias for "noleap".
e) I'll let Steve comment on the Ferret aspects of this question.
The "days since 0000-..." convention for indicating climatological data
comes from COARDS. The CF convention offers alternatives that allow a much
more precise description of the data used to compute the climatology, and
we have deprecated the "days since 0000-..." convention. The section on
climatological statistics has been significantly updated and, we hope,
improved from the previously released 1.0-beta3 version. The working
version is available from the CF metadata home page which I've just put
together at
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/. Please check
it out and send us your feedback.
Best regards,
Brian
On Fri, 15 Mar 2002, Alan Wallcraft wrote:
> The CF conventions are a significant advance over previous efforts, but
> I have a few comments:
>
> 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.
>
> b) Similarly, cell_method is applied to data variables but could be
> inherited along with a coordinate variable. This is less obviously
> appropriate than the 1-D alternative coordinate, since the method is
> being applied to the data not the axis, but I think it is still a
> worthwhile convention for the default cell_method to be from the
> coordinate variable (possibly replaced by an explicit cell_method for
> a particular data set). The example I am thinking of is when the
> time axis represents (say) monthly means.
>
> c) I like the GDT absolute time convention, particularly "day as %Y%m%d.%f".
> This is much easier for humans to interpret than "days since ....". My
> only problem with "day as %Y%m%d.%f" is that the "%f" isn't in (say) Unix
> strftime. I suggest adding this to CF, perhaps only as an alternative
> coordinate for relative time dimensions (and perhaps only the "day as .."
> case for simplicity).
>
> d) I suggest adding a new calendar: "all_leap" for perpetual modern leap
> years. Also "365" and "366" as alternative names for "noleap" and
> "all_leap". We run several ocean models that use a 366-day model year
> when forced with climatological winds.
>
> e) Ferret Release_Notes imply that "360" should be "360day" and that
> "days since 0001-..." can only be used for a climatology (CF says this
> must be "days since 0000-...", and we use "days since 0001-..." for
> ocean models forced by climatological winds). Is this just a case of
> Ferret tracking old versions of CF? Are there any other general
> purpose packages that already support, or will support, the CF
> conventions?
>
> Alan.
>
-----------------------------------------------------------------
Brian Eaton | email: eaton at ucar.edu
Climate Modeling Section |
National Center for Atmospheric Research |
P.O. Box 3000, Boulder, CO 80307 |
Received on Thu Mar 21 2002 - 11:29:08 GMT
