Rob, > Thank you for your response and I do apologize for not responding sooner but > working multiple task and time got the best of me. I have researched the > documentation for the ISCCP D1 Data and it is treated at signed data, so your > recommendation to add the value of 256 if the initial value is less than zero > will result in the correct wall. > > You did make reference to netCDF-4, the latest version of which is 4.1.2rc1. > Is this a library which you would include in compile run to form an > executable? Unfortunately I do not have a sophisticated development > environment and have been pulling window command line utilities together to > help process the files I need. When looking at the web page you suggested I > did not see where I could download the new version of the ncdump utility. In our FAQ on porting to Windows, there's a note at the end of the question "How can I use netCDF-4.1 with Windows?" http://www.unidata.ucar.edu/netcdf/docs/faq.html#windows_netcdf4_1 that reads: NOTE: User Viet Eitner has contributed a port of 4.1.1 to Visual Studio, including an F90 port to Intel Fortran. Download source (ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32/netcdf-4.1.1-win32- src.zip) or binary (ftp://ftp.unidata.ucar.edu/pub/netcdf/contrib/win32 /netcdf-4.1.1-win32-bin.zip) versions. That binary has an ncdump.exe for 4.1.1, when you unzip it. Alternatively, our current netcdf-4.1.2rc1 release can be built on Windows in a cygwin environment and will create an ncdump.exe for version 4.1.2. I think ncdump should treat signed/unsigned integers the same way in both versions, so the older 4.1.1 probably has the same features and bugs in that respect. --Russ > -----Original Message----- > From: Unidata netCDF Support [mailto:address@hidden > Sent: Wednesday, March 23, 2011 9:19 PM > To: Graydon, Robert > Cc: address@hidden > Subject: [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 127, 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 represent 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 (long), as well as the four unsigned types > corresponding to eacho of the four integer signed types. > > > This is documented in the netCDF 3.6.3 User's Guide in Appendix C > > http://www.unidata.ucar.edu/netcdf/old_docs/docs_3_6_3/netcdf.html#NetCDF-Classic-Format > > 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 > implementations. > > 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 > > 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 > > 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.