[CF-metadata] Three questions

From: Jonathan Gregory <jonathan.gregory>
Date: Fri, 31 May 2002 15:46:41 +0100

Dear Dr Rockel

It's good to know you're trying to use the CF conventions.

> 1. The co-ordinate system is rotated lat/lon. I found no information in
> the CF-conventions how to handle this. Would the "north_pole" attribute
> as described in the GDT-conventions a possibility?

The CF requires expects that the true lat and lon of the points will be
supplied in 2D auxiliary coordinate variables, named by the coordinates
attribute. This is described in section 5.2. This method carries no information
about how the grid is constructed (in this case, by rotating the pole). The
convention requires this information in order that a generic application can
know how to locate the data, without having to understand many possible kinds
of grid.

It might also be valuable to supply optional information about how the grid is
constructed. Currently the CF convention doesn't have a way of doing this.
It has been discussed but it is not present in the current release as we
did not have time to agree on something. For a rotated grid, I think the
information in the north_pole attribute of the GDT convention is what you
need, but it might be better to introduce some more general method of doing
it, since there are many kinds of grid which might have to be described e.g.
Mercator, polar stereographic.

If you have views on this, that would be helpful.

> 2. The model uses an Arakawa-C grid. Therefore U and V velocities are
> shifted half a grid box. I also found no information in the CF-conventions
> how to handle this. There may be at least two possibilities:
> a. defining an attribute "grid_shift" that would be grid_shift=0.5,0. for
> U and grid_shift=0.,0.5 for V
> b. defining two additional co-ordinate fields that contain the shifted
> values
> What do you think?

(b) is what we would expect. That is, the grids of T, U and V are all
separately described with their own coordinate variables, and the file does
not indicate the relationship between these. The fact that it is an Arakawa
C-grid would be "higher-level" metadata. The GDT and COARDS conventions also
do not have a way of recording this. I think you could argue that it is just
as satisfactory to *deduce* the relationship between the grids, by
examining the coordinates. In a sense, recording that it is an Arakawa
C-grid is redundant.

> 3. The attribute "cell_method" applied to time is like the "time range
> indicator" in the GRIB format definitions (if I understand it right). The
> cell_method can be minimum, maximum, mean and so forth. What is the reason
> that accumulated values are not considered? Wouldn't it be more consistent
> to allow also "sum" or "accumulated" as a cell_method?

For a quantity which is extensive (meaning that the value depends on the size
of the cell), a sum or accumulation is the default interpretation. For example,
if the cell_methods is not specified for time for precipitation amount (kg m-2),
it is assumed to be a sum. This is described in section 7.2. Does that seem
all right to you?

Best wishes

Jonathan Gregory jonathan.gregory at metoffice.com
phone +44 1344 854542 fax +44 1344 854898
Hadley Centre, Met Office, London Road, Bracknell, Berks., UK. RG12 2SY
Received on Fri May 31 2002 - 08:46:41 BST