[netCDF #PJC-789165]: Another question about netcdf4

James,

> On Sep 14, 2011, at 8:49 AM, Unidata netCDF Support wrote:
> 
> >> This will be impossible to answer algorithmically ;-) , but do you know
> >> which of the new types (compound, vlen, opaque and enum) are the most
> >> used and which are the least used?
> >
> > I think none of these are being used much yet, as people are mainly
> > sticking with the classic model, using netCDF-4 for compression,
> > chunking, and very large files.  However, from support questions I've
> > seen, I'd say the most used is vlen, followed by compound, enum, and
> > opaque, with the latter hardly used at all.
> >
> >> In my work on the handler updates I'd like to make the folks maximally
> >> happy with minimal effort, esp. since NOAA just agreed to fund work to
> >> make many of the kludges I'm about to consider moot...
> >
> > Unfortunately, vlen and compound are the most effort to implement ...
> 
> For compound types, is it possible that people can put dimensions in
> a compound? I'm guessing that only groups can be used for that,
> correct? Where I'm going is if I need to be looking inside a
> Compound (which maps to DAP2's Structure) for instances of DAP2's
> Grid type. Doing that will mean treating the scope created by a
> Structure (compound) in a more sophisticated way, probably using two
> passes to build the type definitions.

No, a compound type can't hold a netCDF dimension.  The only
containers for dimensions are groups.  A fixed-size multidimensional
array can be a member of a compound type, but the shape of such an
array is fixed and belongs to the specific array member definition.
The "dimensions" used to specify the size of such an array member are
anonymous and so can't be shared in defining any other array members
or variables.

The netCDF-4 enhanced data model used for the netCDF C-based APIs
doesn't support netCDF variables as members of compound data types,
which means, for example, that compound members can't have associated
attributes, although we have developed a convention for associating
attributes with members that's described here:

 
http://www.unidata.ucar.edu/netcdf/papers/nc4_conventions.html#Convention_for_Assigning_Attri

This netCDF-4 enhanced data model is close to the HDF5 data model in
having compound members not be HDF5 datasets and not have attributes
of their own.

The netCDF-Java Common Data Model (CDM) differs in a few ways from the
netCDF-4 enhanced data model, but there is a two-way mapping between
them:

  http://www.unidata.ucar.edu/software/netcdf-java/CDM/Netcdf4.html

In particular, a CDM Structure, which is analogous to the netCDF-4
compound type, can have actual netCDF variables as members of the
structure.  For now, the 2-way mappings set up between these data
models haven't caused any problems, but if you try to support both
data models, you may find problems reconciling the differences,
unfortunately.

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: PJC-789165
Department: Support netCDF
Priority: Normal
Status: Closed