netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
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 ==============================================================================