Harvey Davies (hld@xxxxxxxxxxxx) asks:
> I am having trouble with the new version of ncdump crashing due to its
> use of C_format (e.g. "%7.2f") with raw data of type short. I assumed
> that C_format applied to the floating point value produced by
> muliplying by scale_factor and then adding add_offset.
> Should attribute C_format apply to the scaled or unscaled value/type?
It currently applies to the unscaled value and type.
> Would it be possible to provide either or both of the following new options
> in ncdump?
> 1. An option to over-ride format specified by C_format
This is a good suggestion. The `-d fdigits[,ddigits]' already exists to
specify a default precision that is overridden by any C_format attributes,
but it appears that it would have been more useful to have the -d option
override the C_format attribute, since you can get the C_format output by
not using the -d option. Unfortunately changing this now would not be
backward-compatible with the current behavior, so a new option will be
required. I propose to use -p (for precision), and otherwise have it behave
like the -d option, which should be declared obsolete and removed from the
documentation but still supported for backward-compatibility.
> 2. An option to apply scaling specified by scale_factor and add_offset.
This is also a good suggestion but could lead to some confusion, since the
type of the variable in such cases will be an integer type (usually byte or
short) but its data will be output as float or double (whatever the type of
the add_offset attribute). For that reason, unpacking by ncdump should be
optional (as you have suggested) rather than the default. We would also
have to modify ncgen to pack limited-precision floating-point data back into
integers, since any output from ncdump should be usable as input to ncgen.
I'll put this on the to-do list.
> I note mention of proposed new attributes _Scale and _Offset on page 12
> of new version of netCDF User's Guide. I guess these will provide a more
> elegent solution to the problem.
Implementing the transparent packing proposal that used reserved attributes
_Scale, _Offset, and _Nbits will have to wait until at least netCDF 3.0. It
will also require a new version number for the on-disk netCDF format.
Russ Rew Unidata Program Center
russ@xxxxxxxxxxxxxxxx UCAR, PO Box 3000
Boulder, CO 80307-3000
P.S. Thanks to all those who replied to my survey of netCDF use. The
revised answer to how widely netCDF is used is in the new pub/netcdf/FAQ
file on unidata.ucar.edu. And there is a new acknowledgements file in
pub/netcdf/THANKS as well.