[CF-metadata] X and Y projection coordinate (center vs corner)

[Thomas Lavergne]

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