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.
> Hello, > Thanks for your answer. I will remember that ucar.bufr.BufrDump is > deprecated and no longer supported. > However, I have analyzed bit-to-bit the provided file and it really > seems that ucar.bufr.BufrDump is right and Netcdf-Java is wrong. For > instance, let us look at the 'obsRecord.Parcel lifted index (to 500 hPa) > (see Notes 3 and 4)' field (descriptor in table B : F=0 X=13 Y=42). The > first bits related to this field in section 4 are : > 0 1 1 1 0 1 0 0 0 1 0 0 1 1 1 1 1 1 1 1 0 0 0 1 0 0 1 0 ... > In this sequence : > Bits 1 to 6 : 0 1 1 1 0 1 : local reference value (29 ie 29-20=9°C) > Bits 7 to 12 : 0 0 0 1 0 0 : number of bits for each increment (4 bits) > Bits 13 to 16 : 1 1 1 1 : 1st increment : indicates a missing value > Bits 17 to 20 : 1 1 1 1 : 2nd increment : indicates a missing value > Bits 21 to 24 : 0 0 0 1 : 3rd increment : 1 ie 9+1=10°C > Bits 25 to 28 : 0 0 1 0 : 4th increment : 2 ie 9+2=11°C > and so on... > Please could you have a look to this and, if the problem is confirmed, > give me an approximate delay before it gets resolved ? > Thanks in advance again. > Frederic Bacheviller yes, you're right, i wasnt correctly detecting missing data when the message is compressed. I have a new release (4.0.40) at http://www.unidata.ucar.edu/software/netcdf-java/ if you'd like to test and make sure its fixed now. Thanks for debugging! John Ticket Details =================== Ticket ID: RUT-379172 Department: Support netCDF Java Priority: Normal Status: Open