Creation order: time stamps or sequence numbers

NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.


>     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 ...


  • 2003 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-hdf archives: