⇐ ⇒

[CF-metadata] CF-1.0-beta5: curvilinear bounds "contiguous"attribute

From: John Caron <caron>
Date: Mon, 17 Mar 2003 08:32:18 -0700

Steve Hankin wrote:

>>In our NcML encoding, we have tentatively agreed upon 2 ways to specify
>>coordinate bounds, the first from CF, the second the simple case of a
>>contiguous grid:
>>
>>CoordinateAxisBoundary element is a Variable which must have the shape:
>>
>> 1) (dim1,dim2..., nvertices), where dim1,dim2... are from the
>>CoordinateAxis, nvertices number of vertices of the boundary. [CF
>>definition]
>>
>> 2) (dim1+1, dim2+1,...) where (dim1, dim2...) are from the
>>CoordinateAxis [contiguous case]
>>
>>
>
>Hi John,
>
>I think the spirit of this is an excellent suggestion -- better in principle than an
>optional "contiguous" attribute because the "contiguousness" becomes a self-describing
>property of the (dim1+1, dim2+1,...) encoding. Experience has shown that the majority of
>file outputs would be fully described by this encoding and very efficiently processed.
>
>The awkwardness of this approach lies in the limitations of the netCDF record attribute --
>that there is no way simultaneously to have a record axis of length N and a bounds
>variable of length N+1 on the record axis. Therefore one cannot readily append to a file
>that represents axis bounds this way (typ. the time axis). That (and other factors) lead
>to the N*2 encoding of 1D axes.
>
ok, that explains a lot, i hadnt thought of the "record dimension" problem.

do you see the record dimension (presumably time) as the main use of
coordinate bounds?

my emphasis has been on making the common case easy, so if using
contiguous coordinate bounds not on a record dimension is common, it may
warrent consideration in addition to the more general case.
Received on Mon Mar 17 2003 - 08:32:18 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒