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@cgd.ucar.edu >> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata