NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Quincey, > For the functions below, how do you get the ID/num of an object > when you don't know the name? Do you pass in a NULL pointer for the > name parameter? No, you don't need to know the name just use the ID, since IDs for variables are guaranteed to be in the range 0, 1, ..., nvars-1 and similarly for dimensions and attributes. The C/Fortran interfaces support access to objects by ID, but if you want a particular named object and don't know its ID, you use the appropriate function to get the ID from the name first. The C++ and Java interfaces eliminate the IDs but still use handles and provide a way to iterate through the objects in ID order. This is not a very important capability, it's just that users would notice if ncdump output their variables in a different order when the data was stored in an HDF5 file than when it was stored as a netCDF file. For some users, the intended order is part of the way they have structured their data, for example putting all the variables having to do with georeferencing and coordinate systems together after the variables that hold the real data. Rearranging these to be alphabetical by name would lose the intent of originally constructing them in a meaningful order. Other (most?) users don't care about the order of the objects in a file or the order they appear in an ncdump output. But in supporting backward compatibility for format and APIs, we have to cater to the picky users who don't want the order changed just because the underlying file format has changed. > I think supporting creation order for attributes might be a bit > more of a problem than for the other kinds of objects, but from > reading your description of the attribute number below, it doesn't > look like it's a real problem if the "creation order" of attributes > changes. Is that so? For some minority of users, it would be a problem, because some netCDF variables have a hundred attributes or more. For example, if FGDC georeferencing information were stored as attributes, it might be important to store them in the same order as in the FGDC standard, to be able to easily compare them with the standard specification. CDL (the output from ncdump) is the form in which data structures and metadata are discussed in our community. Being able to generate CDL with things in the intended order is sometimes important. An analogy is program source. The order in which variables are stored in memory may be irrelevant, but the order in which you declare them in the program source is sometimes important for clarity, and the same for structure members. If a program editor rearranged the declarations of variables and structure members to be in alphabetical order, some programmers would be annoyed ... --Russ
netcdf-hdf archives: