Re: [netcdf-java] Reading GRIB2 levels data

HI Nikolas:

So I dont see any such grib record in the file. I would expect discipline =
0, category = 3, parameter = 6 according to the Note. There is likely some
formula we need to know also, using the level values (32-33, 33-34, etc).
You might want to contact NCEP to see if you can track that down.

I also see that I dont in fact deal with this case, although some of the
mechanism for doing so is done(VExplicitField).

So, Im sorry I cant help you. If you do locate the missing grib record and
the correct formula, send it along and ill have a look at it.

John



On Wed, Dec 7, 2016 at 6:05 AM, Dahn, Nikolas <
nikolas.dahn@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> 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@iosb-ast.
> fraunhofer.de> 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/>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 listnetcdf-java@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit: 
> http://www.unidata.ucar.edu/mailing_lists/
>
>
>
  • 2016 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdf-java archives: