This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
> >To: address@hidden > >Subject: Service Message > >Organization: College of Marine Studies, University of Delaware > >Keywords: 199803190618.XAA22049 Hi Randy, > I am currently writing some programs that 'pack' floating point > values into BYTE and SHORT variables, but keep the 'scale_factor' > and 'add_offset' attributes as FLOAT. > > My question is about the valid_{min,max,range} attributes... > > The NetCDF documentation says that 'valid_min', 'valid_max', > and 'valid_range' should be the same type as the packed variable, > but I'm finding it convenient to make them the same type as the > 'scale_factor' and 'add_offset' attributes... > > It would seem to me that the appropriate data-type for these > attributes depends on whether one wants to do range-checking > before or after scaling the variables.. The documentation in the User's Guide is in error in saying The type of each valid_range, valid_min and valid_max attribute should match the type of its variable ... since the type conversion available with netCDF-3 makes this requirement unnecessary. We will delete that sentence from the next version of the User's Guides. You're right in pointing out that it's currently unclear whether the intention was for the valid_{min,max,range} attributes to apply to the data values before or after packing. Since the library doesn't use these attributes or treat them in any special way, you can use them either way. Unfortunately, since we didn't specify which way we intended them to be used, there are probably existing conventions and applications that conflict. Harvey Davies (who replied earlier on the netcdfgroup mailing list) helped us clarify the User's Guide conventions, and it was his intention that the valid_* attributes apply to the packed values, not the unpacked values. This is also required by the use of valid_* attributes to determine if bytes should be interpreted as signed or unsigned when doing arithmetic to unpack values. So, if you are doing this for the first time, I would assume that the valid_* values apply to the packed values. We'll try to make this clearer in the next revision of the User's Guides. I'd be interested if you find out about other developers who have assumed the alternative convention in their applications or data. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu