[Fwd: Re: valid_min, valid_max, scaled, and missing values]

• Subject: [Fwd: Re: valid_min, valid_max, scaled, and missing values]
• From: John Caron <caron@xxxxxxxxxxxxxxxx>
• Date: Tue, 27 Feb 2001 13:11:02 -0700

-------- Original Message --------
Subject: Re: valid_min, valid_max, scaled, and missing values
Date: Sat, 24 Feb 2001 10:55:37 -0700
From: Russ Rew <russ@xxxxxxxxxxxxxxxx>
Organization: UCAR Unidata Program
To: John Caron <caron@xxxxxxxxxxxxxxxx>
CC: support-netcdf@xxxxxxxxxxxxxxxx

John,

> One problem is that the the statement that the "attribute type should
> match the data type" does not specify whether to compare packed or
> unpacked. This is a little more obvious when seen through the java API
> which has only "Numbers" as attribute data types. "is in the units of
> the packed data" is unambiguous. 
> 
> One could try to check the attribute type, and decide based on that, but
> theres no way to find that info out through Java API I think. Perhaps we
> should change that?

Yes, I'm beginning to think it's necessary to permit various numeric
types for attributes in the Java interface, because in the published
conventions there is information encoded in the type of an attribute
that would otherwise be lost to the Java interface.  And it would be
impossible to create netCDF files through the Java interface that
conform to such conventions if the attribute type can't be specified
properly.

But maybe I've misunderstood what's possible in the Java interface.
Glenn's interface had an Attribute.getComponentType() method and a
constructor that took a java.lang.Number for a value, so maybe it
permits any numeric type for an attribute.  And your interface has
Attribute.getValueType(), so does that return numeric types that
aren't just Double.Class?

If not, how difficult would it be to change the Java interface to
support attributes of type byte, short, int, float, and double,
instead of just "Numeric"?  It appears that the only alternative is to
get everyone to change their conventions to not encode information in
the type of attributes, and it might be too late for that with
terabytes of information out there in netCDF datasets that follow
published conventions.  I'm sort of surprised that no one has
previously raised this issue.

> I'm thinking VariableStandardized should look at the attribute type and
> choose based on that. If its integer, use packed, if floating use
> unpacked. We should also promulgate another convention so that users can
> do either in a standard way. Its clear some users prefer specifying in
> unpacked units.

It sounds like you must already have a way to determine the numeric
types of Attributes in your Java interface.

> PS: do you mind if i send this to netcdf-support so we have a record?

No, by all means, except I think you'll have to forward it to the
address "bitbucket" and CC: support-netcdf to make it work.

--Russ