NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Quincey,
> This document introduces dimensions as an optional method of composing
> a dataspace in HDF5, so they ought to be completely analogous to netCDF
> dimensions.
> One possible difference is that I wasn't planning on naming the dimensions
> within a dataspace. They were just going to be indexed by their rank within
> the dataspace (i.e. the 0th dimension, the 1st dimension, etc). This could
> reference a named dimensions through an indirect dimension (see the
> shareability
> document), but the actual dimensions in the dataspace weren't planned on
> having
> names associated with them.
> Do you think this is an important requirement? Does the netCDF API
> require that the dimensions in a dataspace for a dataset have names, or
> will having shared dimensions using the names of dimension objects in the
> grouping hierarchy be sufficient?
Currently, each netCDF dimension must have a unique name. There are
several reasons for this:
1. To support functions such as
int nc_inq_dimid (int ncid, const char *name, int *dimidp);
which returns a dimension ID from its name. The netCDF ID can be
used to get the dimension length and determine whether it is an
unlimited dimension.
2. To support the association between a netCDF dimension and the
corresponding coordinate variable, if any. When there is a
corresponding coordinate variable, it is identified by having the
same name as the dimension.
3. In some discipline-specific netCDF conventions that associate
special meanings with particular dimension names, for example,
in the "CDC netCDF Conventions: Gridded Data":
http://www.cdc.noaa.gov/cdc/conventions/cdc_netcdf_standard.shtml
4. To distinguish between dimensions that happen to have the same
length but that are intended to represent distinct dimensions.
If two variable's dimensions are not related, we recommend
creating separate dimensions for them, even if they happen to
have the same length.
However, in netCDF-4, we have discussed supporting anonymous
dimensions as an enhancement. For example, if we want to provide
explicit support for a vector or list object of variable length that
keeps its own private length, it need not have a name if there is some
way to get its length from the vector/list object.
So as a bottom line, I'd say we have to be able to support a name with
every dimension as a default, but that it might be convenient to be
able to explicitly specify that a dimension be anonymous as a special
case, to support objects that "know their own length".
--Russ
netcdf-hdf archives: