I just want to throw in my two cents here. At the primitive level, netCDF does
NOT support such structures directly since the notion of the abstraction of
multidimensional blocks is inherently rectilinear. However, the self-
descriptive mechanism does permit one to define conventions for the storage
of such meshes. If one is careful, the support can be extended to very
complex structures that is no less self-describing then primitive structures
provided "raw" by netCDF. This is something that I did in the original CDF
around 1986 or so for direct support of non-rectilinear geographic grids with
non-constant cell size, although constant topological primitive as well as
sparse matrices, especially for applications in visualization. It is
certainly still supported in the current CDF release among other things.
In general, there are problems in supporting such notions in netCDF because the
geographic grid typically will have to be torn (i.e., you're flattening a
continuous surface onto a rectilinear grid as a multidimensional block) and
hierarchical structures are not directly supported. If one accepts some
limitations (i.e., defines some bounds) on how well to support this class of
grids, it is possible to adequately (depending on the application) provide for
them at a layer above netCDF and confine their interpretation to applications
(i.e., not burdening netCDF with direct support). However, for large grids or
collections of grids it may not be efficient or practical in access or storage.
This is NOT meant as a criticism of what netCDF does provide, but merely
acknowledgement of the limitations in the data model at the heart of CDF and
netCDF, from someone with familiarity on the topic.
I can cite specific examples, if anyone is interested.
Lloyd Treinish
------------------------------- Referenced Note -------------------------------
Received: from unidata.ucar.edu by watson.ibm.com (IBM VM SMTP V2R2) with TCP;
Mon, 13 Jan 1992 18:07:03 EST
Received: by unidata.ucar.edu id AA05493
(5.65c/IDA-1.4.4 for netcdfgroup-send); Mon, 13 Jan 1992 15:15:21 -0700
Received: from acd.acd.ucar.EDU (acd.ucar.edu) by unidata.ucar.edu with SMTP id
AA05489
(5.65c/IDA-1.4.4 for <netcdfgroup@xxxxxxxxxxxxxxxx>); Mon, 13 Jan 1992
15:15:20 -0700
Message-Id: <9201132215.AA28201@xxxxxxxxxxxxxxxx>
Received: by acd.acd.ucar.EDU (AIX 3.1/UCB 5.61/ NCAR Mail Server 04/10/90)
id AA28201; Mon, 13 Jan 1992 15:15:14 -0700
Cc: netcdfgroup@xxxxxxxxxxxxxxxx
> Is it possible and/or permitted in netCDF to have multidimensional
> coordinate variables and attributes?
Short answer to both is yes. Longer answer is other people may not
know what you mean since the dataset will become a bit less self
describing.
> Here are two examples of what I'm talking about. First lets say I've
> divided up the globe into 90 regions each having the same amount of elements
> in the lat direction and the lon direction. The shape of the variable would
> thus be (90,36,72) and the dimension names would be (region,lat,lon).
> Now here is what I'm getting at. The lat and lon coordinates are different
> for each region. A one dimensional coordinate variable for the dimensions lat
> and lon will not cut it. However, a two dimensional one would with a shape
> of (90,36) for lat and (90,72) for lon, would work. I haven't ever seen
> any files with this organization. Is this legal?
Quite legal to have a *variable* with dimension (90,36,72). Each dimension
may or may not have a *variable* associated with it. This association is
achieved simply by having a variable of the same name as the dimension.
In our datasets we do not often have this implicit association. You are
free to assign a variable of the same name as a dimension any fixed
dimensions. What this variable means depends on interpretation.
> The second example concerns attributes. Lets say I have a 3D array and rather
>than store the variable attributes min and max for the whole array. I'd like to
> have a variable attribute that stores an array of mins and maxs for individual
> 2D slices. Is this resonable and legal? How are the dimensions of attributes
> stored? The attribute section of the netCDF guide shows attributes only having
> a type and a length, no dimensions.
Attributes have a "length" which translates to a singly dimensioned quantity.
You are free to increase this single dimension to essentially include multiple
dimensions, but the subscripting into this array and its ultimate interpretation
will have to be known by subsequent software. If you define attributes
"mins" and "maxs", for example and say these are to apply to array(90,36,72)
where mins(90) correspond to each of the 90 two dimensional 36x72 arrays,
then things are fine. But this is not the only way these attributes could
correspond and their correspondance would have to be understood by software
presented with this data.
