NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Thank you kindly for your support. I have uploaded a file to the following URL: https://mega.nz/#!JkI0DIbJ!-P7VqflJJ2jnPDGA3BB158IthLEGojT756xPEF2wgeQ The following variables use the generalized height coordinates: - Temperature - Pressure - u-component_of_wind - v-component_of_wind Up till now I was not able to find the corresponding 3D-Grib-Message, but I'm not sure how to look for it either. I am happy with my solution for now, but I suspect there might be more data hidden somewhere (?). Thanks, Nikolas PS: John, thanks for the hint at the 5.0 branch. I wasn't aware of it. I will check it out in the near future. ________________________________ Von: Antonio S. Cofiño [antonio.cofino@xxxxxxxxx] Gesendet: Dienstag, 6. Dezember 2016 16:08 An: John Caron; Dahn, Nikolas Betreff: Re: [netcdf-java] Reading GRIB2 levels data Dahn, if you want I can provide you a sftp where you can put the file, and make it available to everyone via HTTP. (or restricted what you prefer). Just sent me your SSH public key Antonio -- Antonio S. Cofiño Associate Professor and Researcher Grupo de Meteorología de Santander Dep. of Applied Mathematics and Computer Sciences Universidad de Cantabria (Spain) Academic Visitor National Centre for Atmospheric Science Department of Meteorology School of Mathematical, Physical and Computational Sciences University of Reading (UK) http://antonio.cofino.es On 06/12/16 14:33, John Caron wrote: Hi Nikolas: 1. The best version of the library to work on with GRIB is 5.0. https://www.unidata.ucar.edu/software/thredds/v5.0/netcdf-java/documentation.html 2. Generalized Vertical Height Coordinate (see Note 4) The definition of a generalized vertical height coordinate implies the absence of coordinate values in section 4 but the presence of an external 3D-GRIB message that specifies the height of every model grid point in meters (see Notes for section 4), i.e., this GRIB message will contain the field with discipline = 0, category = 3, parameterm = 6 (Geometric height). So the code has to search though the file to look for another GRIB record ("an external 3D-GRIB message") to find the coordinates. So the PDS does not have the information. There are some heuristics somewhere to do this. Ill have to dig around for where that is, but (assuming it finds it) it should create the correct coordinate system at the GridDataset layer. 3. To help you any further I will need a copy of the file. Can you put on ftp or dropbox or something? Regards, John On Mon, Dec 5, 2016 at 9:50 AM, Dahn, Nikolas <nikolas.dahn@xxxxxxxxxxxxxxxxxxxxxx<mailto:nikolas.dahn@xxxxxxxxxxxxxxxxxxxxxx>> wrote: I found a fix and a way to apply it as a temporary hack. Basically what happens is the following: - In Grib2CollectionBuilder.Grib2Rectilyser.make unique coordinate systems are built from the various PDS sections - The PDS' data sections are collected into VariableBags - To determine which coordinates are used the vertical height unit is examined, among others - This unit is (usually) provided by the Grib2Customizer (an implementation of GribTables) - The current implementation lacks a switch-case for code 150 (generalized vertical height) and the default mapping defines the unit as 'null' - From this it is determined that no vertical coordinate is present - Thus the coordinate is missing and the builder builds the coordinate system without the height coordinate - In the end most of the data is missing because the later data sections overwrite the earlier ones, as one of their distinguishing dimensions is missing The fix is quite simple: all I did was adding case statements for code 150 in Grib2Customizer.getVertUnit(int) and Grib2Customizer.getLevelNameShort(int). A patch is attached below. For those who stumble over this and don't have access to a patched version, you can derive a class from Grib2Customizer and override the two offending methods. Then set a private variable of Grib2Customizer via reflection like shown below. I recommend doing this in a static block. Field f = Grib2Customizer.class.getDeclaredField("wmoStandardTable"); f.setAccessible(true); f.set(null, MyGrib2Customizer.factory(0, -1, -1, -1, -1)); Cheers, ~ Patch: ==== --- ucar/nc2/grib/grib2/table/Grib2Customizer.java.orig 2016-12-05 17:44:09.663099300 +0100 +++ ucar/nc2/grib/grib2/table/Grib2Customizer.java.patched 2016-12-05 17:45:16.147099300 +0100 @@ -408,6 +408,9 @@ case 119: return new GribLevelType(code, "Pa", null, false); // ?? + case 150: + return new GribLevelType(code, "numeric", null, true); + case 160: return new GribLevelType(code, "m", "sea level", false); @@ -505,6 +508,8 @@ return "hybrid_pressure"; case 120: return "pressure_thickness"; + case 150: + return "generalized_vertical_height"; case 160: return "depth_below_sea"; case GribNumbers.UNDEFINED: _______________________________________________ NOTE: All exchanges posted to Unidata maintained email lists are recorded in the Unidata inquiry tracking system and made publicly available through the web. Users who post to any of the lists we maintain are reminded to remove any personal information that they do not want to be made public. netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxx<mailto:netcdf-java@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: <http://www.unidata.ucar.edu/mailing_lists/> http://www.unidata.ucar.edu/mailing_lists/ _______________________________________________ NOTE: All exchanges posted to Unidata maintained email lists are recorded in the Unidata inquiry tracking system and made publicly available through the web. Users who post to any of the lists we maintain are reminded to remove any personal information that they do not want to be made public. netcdf-java mailing list netcdf-java@xxxxxxxxxxxxxxxx<mailto:netcdf-java@xxxxxxxxxxxxxxxx> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
netcdf-java
archives: