I believe your items 1. and 2. match the interpretation of the User's
Guide made in the CF conventions. The reason these restrictions are
important is so that an application can identify missing values *before*
using scale/offset attributes to transform values. Attempting to transform
missing values could potentially result in an invalid operation.
I not sure what historical uses you're referring to in item 3. Version 2.3
of the User's Guide says the type of valid_range should match the type of
its variable. In version 3 of the User's Guide the valid_range is only
allowed to be "wider" than the variable type when that type is byte. That
was to allow the signedness of the bytes to be identified using valid_range
since the signedness attribute was deprecated.
The primary purpose of valid_range as described in the current version of
the User's Guide is to facilitate identifying missing values. Allowing
valid_range to be wider than its variable (except in the case where it's
used to indicate the signedness of bytes) requires the application to
transform data before looking for missing values. I can't see any benefit
to doing this.
On Tue, Sep 12, 2006 at 01:07:29PM -0600, John Caron wrote:
> The users guide is vague on the interaction between missing data and
> scale/offset standard attributes. Id like to propose adding the following:
> 1. The _FillValue and missing_value standard attribute values must be in
> the units of the packed data.
> 2. The valid_range, valid_max and valid_min standard attribute values
> should be in the units of the packed data.
> 3. To accomodate historical uses, if the valid_range, valid_max or
> valid_min values are wider than the packed data type, then these will be
> interpreted as being in the units of the unpacked data. Wider means: (byte
> < short < int < float < double ). Otherwise, they will be interpreted as
> being in the units of the packed data.
> Comments solicited.
> To unsubscribe netcdfgroup, visit:
To unsubscribe netcdfgroup, visit: