[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #AKJ-370049]: ncdump question

Hi Robert,

> I have downloaded the windows command line utility ncdump and use it to
> create an ASCII version of an HDF5 file I downloaded from the ISCCP data
> serve r. D1 Cloud Data.
> The command line I used is:         ncdump -l 1212 inputfile > output file
> I have found that the ncdump routine has modified some of the values
> from the original input file.
> For example: The value 255 from the input file is changed to the value of -
> 1.  (255 is supposed to represent an undefined value.)
> The value 201 is changed to the value of -55
> The value of 190 is changed to -66
> The value of 144 is changed to -112 (this happens to
> be a longitude value in the file)
> To the best of my knowledge this is an HDF5 formatted file.
> Is this a known problem with this utility or should I be including
> addition command parameters in the command line.

It looks like ncdump is interpreting these 8-bit values as signed integer bytes
rather than unsigned integers bytes.  The range of a signed byte is  -128 to 
whereas the range of an unsigned byte is 0 to 255.  To get the equivalent signed
value from the unsigned value, you can subtract 256.  An 8-bit byte can 
either range of integers, depending on what type the variable is declared.

The netCDF-3 library only supports 3 integer types, and they are all signed: 
byte (8 bits),
short (16 bits), and int (32 bits).  The netCDF-4 library (and the ncdump 
utility that
accompanies that version) supports those 3 types but an additional 64-bit type 
as well as the four unsigned types corresponding to eacho of the four integer 

This is documented in the netCDF 3.6.3 User's Guide in Appendix C


where it says:

  Note on byte data: It is possible to interpret byte data as either
  signed (-128 to 127) or unsigned (0 to 255). When reading byte data
  through an interface that converts it into another numeric type, the
  default interpretation is signed. There are various attribute
  conventions for specifying whether bytes represent signed or unsigned
  data, but no standard convention has been established. The variable
  attribute â_Unsignedâ is reserved for this purpose in future

Was the HDF5 data you are reading declared to be of type unsigned
byte?  If so, it ought to be handled correctly by the ncdump utility
in netCDF-4, the latest version of which is 4.1.2rc1, available from
the netCDF home page.  If that doesn't work and the HDF5 type was
declared as unsigned, you've identified a bug in the library that
we'll have to fix.


Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu

Ticket Details
Ticket ID: AKJ-370049
Department: Support netCDF
Priority: Normal
Status: Closed

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.