Errors when converting NEXRAD composites (GINI) to netCDF3/netCDF4 #480
Comments
1riggs
changed the title
GINI calibration values can be negative (for the data value range), and GEMPAK uses the left most bit of the stored integer to deignate the signedness. Fixes Unidata#480
GINI calibration values can be negative (for the data value range), and GEMPAK uses the left most bit of the stored integer to deignate the signedness. Fixes Unidata#480 Minor addition - since the long_name attribute was there and so close, go ahead an add the standard_name attribute to the x and y coordinate variables.
GINI calibration values can be negative (for the data value range), and GEMPAK uses the left most bit of the stored integer to designate the signedness. Fixes Unidata#480 Minor addition - since the long_name attribute was there and so close, go ahead an add the standard_name attribute to the x and y coordinate variables.
GINI calibration values can be negative (for the data value range), and GEMPAK uses the left most bit of the stored integer to designate the signedness. Fixes Unidata#480 Minor addition - since the long_name attribute was there and so close, go ahead an add the standard_name attribute to the x and y coordinate variables.
|
Happy to see this addressed so quickly! Is there a better way to start using netCDF-java with this fix than building based on the maint-5.x.x branch? |
|
@dopplershift and I paired up and were able to knock it out somewhat quickly once we got in the same room, although we had to dig through some GEMPAK code to see how these GINI files were actually encoded (as far as we can tell, the way these coefficients are encoded isn't documented outside of the GEMPAK source code). I just pushed a snapshot version of toolsUI that has the fix if you'd like to give it a spin - https://artifacts.unidata.ucar.edu/repository/unidata-all/edu/ucar/toolsUI/5.4.0-SNAPSHOT/toolsUI-5.4.0-20200922.213306-5.jar |
|
I very much appreciate the effort and thanks for the link! I converted the sample data I included in the initial issue to netCDF4 and things are looking good for the most part. The statistics are in the expected range but the no data value still seems suspect. According to GDAL the no data value is 9.96920996838686905e+36, I admit I'm new to this radar data stuff, but I'm concerned that the value is the result of a bug in the conversion process. I'm running the conversion on the command line using: |
|
I can certainly see why that no data value would raise an eyebrow! In this case, there isn't an explicit attribute being set on the variable |
|
Ah that makes sense. Thank you very much for the insight and the bug fix! |
Backport of Unidata/netcdf-java#488 GINI calibration values can be negative (for the data value range), and GEMPAK uses the left most bit of the stored integer to designate the signedness. Fixes Unidata/netcdf-java#480. Minor addition - since the `long_name` attribute was there and so close, go ahead an add the `standard_name` attribute to the `x` and `y` coordinate variables.
GINI calibration values can be negative (for the data value range), and GEMPAK uses the left most bit of the stored integer to designate the signedness. Fixes Unidata#480 Minor addition - since the long_name attribute was there and so close, go ahead an add the standard_name attribute to the x and y coordinate variables.
When writing a NEXRAD composite GINI file to netCDF the resulting file has incorrect values. I have attached a zip file with the original GINI file as well as the netCDF which resulted from using toolsUI to convert the file to netCDF. Note that the same error occurs when using IDV, or Weather and Climate Toolkit, which all rely on netcdf-java.
nexrad-gini-samples.zip
The original file is sourced from a public google cloud storage bucket, and the netCDF was inspected using
gdalinfo -statsusing GDAL versions 3.1 & 3.0.System Info
The text was updated successfully, but these errors were encountered: