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