Hi Ed,
How about a function like this:
EXTERNL int
nc_def_compound_att(int ncid, nc_type compound_typeid, char *att_name,
nc_type att_base_typeid, nc_type
*att_typeidp);
This could construct a new compound type, suitable for use as such an
attribute. For example, after defining come compound type cmp_typeid,
you could create the type for a "units" attribute like this:
nc_def_compound_att(ncid, cmp_typeid, "units", NC_CHAR, units_att_typeid);
If you passed a base type of NC_NAT, the compound attribute type could
use the same type as each field in the compound type. So you could get
a _FillValue type like this:
nc_def_compound_att(ncid, cmp_typeid, "_FillValue", NC_NAT, fill_att_typeid);
Maybe I'm not following this quite right, but this doesn't seem to do
quite the same thing as Russ's previous suggestion / example. In his
example Russ defined a single compound attribute type for string
attributes ('compound obs_atts') and then used this as the type for two
different compound attributes ('obs_atts obs_var:units' & 'obs_atts
obs_var:standard_name'), whereas it looks like this function would
create distinct types for each compound attribute.
I'm not saying that this is necessarily a bad thing, I really haven't
thought enough about it (and don't yet feel I have enough experience
with the whole netCDF way of doing things to hold strong opinions on how
it should be ;-), although I did quite like Russ's original proposal for
its simplicity.
I certainly think adding an API function to do something like this is a
good idea, though.
regards
Simon Wood
--
Simon Wood Meteorology & Remote Sensing
Scientific Programmer NIWA
simon.wood@xxxxxxxxxx http://www.niwa.co.nz
==============================================================================
To unsubscribe netcdf-hdf, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
