My own thinking goes along these lines:
A grid is a discrete sampling of a continuous function. The coordinates give a location in
space/time, say {x(x), y(y), z(z), time(time)}, and the value of that function at that point is
data(time,z,y,x).
>From that POV, its likely to be "wrong" that an application would interpret the coordinate as one of
the edges of a cell, because that would make it "off-by-half-point" for contouring or visualization.
I agree with Jonathan to add such a wording for future clarity.
IMO, you could contact the application developer and say: if you see a CF file, please interpret
coordinates as center-of-cell where that matters.
Coordinate bounds allow edges to be explicit, and you could ask the application developer to look
for those. When not specified, I put the edges halfway between the coordinates.
Balaji's gridspec is a solution for describing other sampling topologies, but alas, we have not yet
integrated it into the spec, nor does the netcdf-java library implement it yet.
Regards,
John
Thomas Lavergne wrote:
> 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
>
> _______________________________________________
> 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 - 10:45:04 GMT
