Dear Jonathan,
We should not be overly surprised by the choice made by some applications. Software were designed
and developed before CF conventions (or even netCDF) came in place and, in the slow process of
adapting to new standards, need to keep backward compatibility with previous ways of doing things.
The (silent) standard for my application was to consider "corners" and was not yet adapted to use
the "center".
Anyway, and although I agree with you that CF "provides bounds to describe cells", we could
acknowledge that, in very particular (but not rare) occasions, a spatially intensive grid coordinate
system can be interpreted as representative of a cell (e.g. for plotting purposes). I do not think
we can expect from historical applications, some handling several other formats, that they start
digging out "cells" information because they happen to load a CF-compliant netCDF file. Cells are
great for us to specify what goes into a pixel (an average, a maximum, etc...) but are an overkill
when it only comes to locating the pixel before plotting the field, don't you think?
If we agree on this, one could imagine having a special paragraph in the CF document for the case of
a "regularly spaced grid whose all cells are equally sized rectangles that cover totally (and only)
the area left between the neighboring cells". If I am not mistaken, then the
projection_x&y_coordinates are sufficient and their 'grid_spacing' attribute defines the cell
dimensions. The only degree of freedom left is to decide/specify what the values in the
projection_x&y_coordinates 1D datasets stand for (center vs border). Two solutions here :
1) CF demands that they hold the center of the grid cell;
2) we come up with a syntax that allows us to code that we are giving the 'center', the 'lower' or
the 'upper' value of the grid cell. Then we could be free to give, in one file, the 'center' on the
X and Y coordinates but the 'lower' limit in the Z coordinate. Why not grid_reference (or
grid_location...) :
double xc(xc) ;
xc:axis = "X" ;
xc:units = "km" ;
xc:long_name = "x coordinate of projection (eastings)" ;
xc:standard_name = "projection_x_coordinate" ;
xc:grid_spacing = "62.50 km" ;
xc:grid_location = "center"
I am almost certain that you do not like this, Jonathan ;-), as it mixes between two distinct
concepts : coordinates vs cells, intensive vs extensive. But maybe it is worth having the
discussion? I repeat that 'cell' is a great concept but might be an overkill for some usage.
Furthermore, CF is used by many models, some with C-grid, some with A-grid, some with mixed of those
two... Do they all use cells or do most of them silently use the 'intensive' coordinates system as a
proxy for their cells? And if the case, how bad is that (in the CF sense)?
I have no strong feeling about this, but I do not see how I can contact the team of developers of my
favorite visualization software and tell them that they should decode the "cell" information before
plotting my data field. And, so far, I have no way of telling them "read the CF document : it is
written that you should use the values as 'center' coordinates".
Cheers,
Thomas
Jonathan Gregory wrote:
> Dear Thomas
>
> I think it may not be explicitly written down in the CF standard, but it is
> certainly assumed that the coordinates you give (xc yc) are the gridpoints.
> For an intensive quantity, the default interpretation of the data is that
> it exists at particular points, which are those specified by the coordinates.
> Your application is making a surprising assumption in taking the coordinates
> to lie at the corner of the cell. As you say, CF provides bounds in order to
> describe cells, because that's not what coordinates are intended for.
>
> Cheers
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Jan 27 2009 - 03:00:25 GMT
