I want to comment on the recent discussion about conventions,
in particular valid_range.
First, if you want a netCDF file to be portable (and that is
one of the main reasons for using netCDF) then you must conform
to the published conventions. These conventions are of two types:
- generic: as in chapter 8 of the C, F77 and F90 User Guides
- application-specific: as in "netCDF Conventions" Web Pages
All netCDF files, software and application-specific conventions
should comply with the generic conventions. I was involved in
rewriting these in 1996 and we spent a lot of time trying to
make them as simple, clear and convenient as possible. If we could
have started from scratch, many things would have been different.
But the whole point of conventions is that it is more important
that people comply with them than that they be ideal. A less-
than-ideal convention is still very useful, provided people do
comply.
The application-specific conventions (e.g. COARDS) are very important
for files and software within their application areas, but are
not relevant outside their areas. However, there may be a need to
make some of these conventions generic, so they do apply to all files.
Regarding valid_range. The generic conventions clearly state that
the type must match that of the variable. If if does not, then
there should be an error message. Some software may then attempt
to recover and make some sense of erroneous data like this, but such
a "feature" worries me because it encourages file writers to use the
feature and write non-standard files.
I certainly do not like the idea of meaning depending on data type.
This is completely against the philosophy of the version 3 API which
is designed so the reader does not have to worry about the external
data type.
I agree that most file users would probably prefer valid range to
be an internal value. So I like the idea of another attribute for
this purpose. The suggested name "unpacked_valid_range" seems
appropriate. But this new attribute should be treated purely as
comment information for humans and ignored by software doing scaling
of input data. (In this respect it would be similar to
"missing_value".)
Harvey Davies, CSIRO Atmospheric Research,
Private Bag No. 1, Aspendale 3195
E-mail: harvey.davies@xxxxxxxx
Phone: +61 3 9239 4556
Fax: +61 3 9239 4444
