[CF-metadata] bounds

From: Jonathan Gregory <jonathan.gregory>
Date: Mon, 28 Apr 2003 23:24:30 +0100

Dear All

I believe the issue of bounds is the only thing which stands in the way of a
non-beta release of CF. There hasn't been any further activity on that thread
this month, so I'd like to restart it by summarising the position. I think
there are three cases to distinguish in the current CF draft:

1D: A coordinate variable x(x) has bounds (x,2) i.e. each cell has an upper and
a lower boundary. This allows cells to be non-contiguous or overlapping, but it
means a check is needed to determine whether they are contiguous.

2D rectilinear: In the case when lat and lon are not 1D axes but there are two
1D projection/transformation axes x and y in the horizontal plane, the
auxiliary coordinates lat(y,x) and lon(y,x) have bounds (y,x,4). The order of
the vertices is not specified. The axes x and y can themselves have 1D bounds.
The 2D cells are contiguous in lat and lon if they are contiguous in x and y,
so contiguousness can be checked in 1D if the bounds are supplied.

2D non-rectilinear: In the case when the horizontal cells are not arranged in a
2D array, they have one or more index dimensions n,..., with auxiliary
coordinate variables lat(...,n) and lon(...,n) having bounds (...,n,p), where p
is the number of vertices of the cells e.g. they could be hexagonal. Checking
for contiguous cells in this case is complicated.

In the 1D case, an alternative representation for contiguous cells would have
bounds (x+1), the bounds of cell i having indices i and i+1. This scheme is not
currently included in CF but may seem more obvious. It has the attraction that
contiguousness is guaranteed by construction and therefore does not have to be
tested. This avoids the difficulty of deciding how to check for contiguousness
reliably, given numerical imprecision.

However, it has the drawbacks (a) it can't be used for the unlimited dimension,
(b) it doesn't avoid an explicit contiguousness check for wrap-round axes e.g.
longitude, in which the first and last boundaries may be coincident, (c) it may
be unreliable to assume that all contiguous cases use (x+1), since (x,2) must
also be supported; hence a contiguousness check may still be needed for (x,2).

My own opinion is that we should stick with supporting just (x,2) for 1D and
not allow (x+1) as an alternative. I don't think that the advantage of not
having to test for contiguousness in certain cases justifies the extra
complexity of supporting two schemes in the standard.

I'd like to make the following proposals concerning bounds (a summary of what I
proposed in my last posting):

(1) In the 1D case, if no bounds are supplied, assume contiguous cells.

(2) 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.

(3) It follows that cells i and i+1 are contiguous if bound (i,1) equals bound
(i+1,0), with a tolerance that the absolute difference between the bounds must
be several orders of magnitude smaller than the absolute difference between the
gridpoints of the cells.

(4) In the 2D rectilinear case, the bounds should be dimensioned (y,x,2,2),
where the 3rd index corresponds to y and the 4th to x. (This is a change from
the current CF standard.) This case is indicated by their being two trailing
dimensions of size 2. Contiguousness should be checked on the bounds of the 1D
coordinate variables rather than the 2D auxiliary coordinate variables. As a
consequence of the ordering of the 1D bounds, the 2D vertices are ordered in a
"zigzag" - an N or a Z or their mirror images.

(5) In the non-rectilinear case, the bounds should be dimensioned (...,n,p) (no
change to CF). The fact that there is only a single bounds dimension, which has
size p>2, indicates this case. The vertices must be traversed anticlockwise in
the lat-lon plane as viewed from above. Testing for contiguousness is a
complicated operation, so you might want to save the results. I suggested in an
earlier posting a scheme we might adopt for this (on Mon Mar 17 at 17:49:50).

Best wishes

Jonathan
Received on Mon Apr 28 2003 - 16:24:30 BST