Jonathan,
I agree with this completely. It's more precise and complete than the current
draft.
One comment on terminology: it might be better to avoid the term '2D rectilinear'
in the CF document, as I have seen the terms rectilinear / non-rectilinear used in
several ways. The current draft uses the term, stating that in addition to COARDS,
CF provides ' the spatial coordinates of non-rectilinear gridded data', implying
that rectilinear refers to the COARDS case alone. This is also the sense that we
use it in-house, reserving the term 'curvilinear' for your '2D rectilinear' case.
Brian, can we finalize this issue?
--Bob
Jonathan Gregory wrote:
> I think I was wrong in the previous posting about the ordering of 2D vertices.
> If we adopt (y,x,2,2) for 2D bounds, the natural convention (I feel) for the
> size-2 trailing dimensions is the same as for 1D, that 0 indicates the side of
> cell which faces in the direction of smaller cell index and 1 the direction of
> larger index. With this convention, you know the "adjacencies" of the grid i.e.
> which vertices should be coincident, so you can check for contiguousness. But
> you don't know how to go round the square anticlockwise or clockwise unless you
> have also inspected the handedness of the x-y-upward coordinate system. There
> are four possibilities for how it looks in lat-lon, depending on the sign
> conventions of x and y:
>
> 1,0 < 1,1 1,1 > 1,0 0,0 > 0,1 0,1 < 0,0
> v ^ ^ v ^ v v ^
> 0,0 > 0,1 0,1 < 0,0 1,0 < 1,1 1,1 > 1,0
>
> On the other hand, with the (y,x,4) convention, you can specify the sense of
> circulation in lat-lon, but then the adjacencies are more complicated. It
> seems to be a choice (unless I am confused now - quite possible). Here are
> the proposals again, modified to reflect this:
>
> (1) For a 1D coordinate variable with bounds (x,2), define an ordering for the
> 2nd index, namely that the bounds should be ordered in the same sense as the
> coordinates, so that the 0-bound of cell i is on the side that faces cell i-1
> and the 1-bound on the side facing cell i+1. [At present, there is no ordering
> defined for 1D bounds.]
>
> (2) If 1D cells i and i+1 are contiguous, bound (i,1) should exactly equal
> bound (i+1,0). The data-writer should ensure that this is so. [At present, the
> standard does not state how contiguousness should be tested.]
>
> (3) In the 2D rectilinear case, the bounds should be dimensioned (y,x,2,2),
> where the first trailing index corresponds to the y dimension and the second to
> the x. The trailing indexes have the same convention as for 1D points, so that
> the 0-bound in either x or y is on the side which faces the cell with the next
> smallest index in that dimension, the 1-bound on the side facing the cell with
> the next largest index. If the coordinate system x-y-upward is right-handed
> (like lon-lat-upward), the elements (j,i,0,0), (j,i,0,1), (j,i,1,1), (j,i,1,0)
> in that order traverse the vertices of cell (j,i) anticlockwise in the lon-lat
> plane as viewed from above. If the coordinate system is left-handed, this
> sequence of elements traverse the vertices clockwise. [This dimensioning of the
> 2D vertices is new.]
>
> (4) In the 2D rectilinear case, if cells (j,i) and (j,i+1) are contiguous in x,
> bound(j,i,q,1) should exactly equal bound(j,i+1,q,0) for q=0 and q=1. If cells
> (j,i) and (j+1,i) are contiguous in y, bound(j,i,1,p) should exactly equal
> bound(j+1,i,0,p) for p=0 and p=1. Since a continuous grid mapping in 2D will
> not affect contiguousness, it is sufficient to check the bounds for any single
> value of j and q for contiguousness in x, i and p for contiguousness in y.
>
> (5) In the non-rectilinear case, the bounds should be dimensioned
> (...,n,p). The vertices must be traversed anticlockwise in the lon-lat plane as
> viewed from above. The starting vertex is not specified by the standard. [At
> present, the standard does not state any ordering.]
>
> Jonathan
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://www.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed May 28 2003 - 19:19:28 BST
