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> 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
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
