Jeff Whitaker <jswhit@xxxxxxxxxxx> writes:
> By the way, while I'm ranting ... Another potential problem is see is
> nested user-defined types. Since this is allowed in netcdf-4, I can
> see the potential for creating horribly complicated files with
> compounds of vlens containing compounds containing enums etc. Don't
> think many people would be crazy enough to use it, but it makes it
> very hard to create client code to read arbitrary netcdf-4 files,
> since you have to check for all those possibilities in general. I
> wonder whether it might not be wise to sacrifice some generality for
> simplicity and just say that user-defined types can only be composed
> of primitive data types.
Here at NetCDF World Headquarters, we also wonder how these new
features will be used by the netCDF community!
Perhaps some of the HDF5 readers of this mailing list can provide some
real world examples of nested structures.
To read them, the only general purpose answer I know of (as with
groups) is a recursive function. This is how the netCDF-4 file reading
code handles the problem, and, I believe, how ncdump handles the
problem (Russ will correct me if I'm wrong about ncdump).
Both of these are in C (for example libsrc4/nc4hdf5.c, function
The problem, perhaps, is what to do with this information once you
For example, it's easy to plot a data file full of NC_INT, or
NC_FLOAT, but how do you plot a file full of data in compound types?
It is a more complicated problem, but I'm sure the very clever
programmers working on the IDV will come up with something. ;-)
Although these new features present many new complexities, the
CLASSIC_MODEL flag allows users to produce netCDF-4 files which don't
use any of the user-defined types, and thus can be read (and, with a
little modification on the nc_create call, written) by existing
Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
To unsubscribe netcdfgroup, visit: