[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: GRIB files with non-standard GRIBTAB files?



Henry,

I answered Robert later on stating that I added the grib paramater table for the sample data that was given by url. Just for your information, the tables are added by configuration of center id, sub center id and table version number. The sample data had 7, 138, 130 numbers so the table referenced below will be added for the data. As long as the configurations are unique there's not a problem of adding tables. The data providers are responsible to make sure that their configuration is unique so there are no conflicts. The table format is the NWS ascii parameter table format.

1:PRES:Pressure [Pa]

The next release will have your table included, I named it vic_138_v130.tab


RObb...




Robert,

Just so I don't forget about this issue, I added the table as vic_138_v130.tab under id 7, 138, 130.
The configuration can be changed at a later date.

Robb...





From: Robb Kambic <address@hidden>
To: Robert B. Schmunk <address@hidden>
<address@hidden>
Subject: Re: [Fwd: Fwd: GRIB files with non-standard GRIBTAB files?] (fwd)

ALPINE 2.00 MESSAGE TEXT Folder: sent-mail Message 96 of 104 78% NEW

Robert,

Just so I don't forget about this issue, I added the table as vic_138_v130.tab under id 7, 138, 130.
The configuration can be changed at a later date.

Robb...





On Thu, 23 Jul 2009, Robert B. Schmunk wrote:


On Jul 23, 2009, at 14:30, Robb Kambic wrote:
>
> This solution is ok but I don't like requiring absolute path names. It
easier to add the table
> to the master list of tables in tablelookup.lst for the package.

I have to agree with you. Also, the GSFC people who originally
contacted me about the GRIBTAB issue were particuarly concerned
aboutusers who wouldn't understand that they'd have to deal with
GRIBTAB files to go with the GRIB datasets.

However, they have also said they're somewhat new to GRIB
themselves (or as they said, "we're more HDF folks") so it may
be a while before you hear from Chris L. about adding to the
master list.

Thanks much for the help,

rbs









On Fri, 24 Jul 2009, Fang, Hongliang {Henry}(GSFC-610.2)[R S INFORMATION 
SYSTEMS INC] wrote:

Dear Robb,

We are trying to open some GRIB files with Panoply and IDV, however, we have 
problems with our

non-standard GRIBTABs. As directed by Robert Schmunk, I'm writing to ask how can we: 1) 
add our GRIBTABs to the netCDF-Java directory; and 2) how to "register" our 
GRIBTAB at runtime using Panoply or IDV.

Thank you for your instruction.

Henry



________________________________________
From: Lynnes, Christopher S. (GSFC-6102)
Sent: Thursday, July 23, 2009 9:09 AM
To: Schmunk, Robert B. (GSFC-611.0)[SIGMA SPACE CORP]
Cc: Fang, Hongliang {Henry}(GSFC-610.2)[R S INFORMATION SYSTEMS INC].; Vollmer, 
Bruce E. (GSFC-6102)
Subject: Re: GRIB files with non-standard GRIBTAB files?

OK, thanks for the info.  This process has been very educational for
us too (we're more HDF folks)...

On Jul 22, 2009, at 8:16 PM, Robert B. Schmunk wrote:


Chris,

I went ahead and passed the question on to John Caron, who in turn
forwarded it onto someone else at Unidata who is involved with the
GRIB Decoder code. That is Robb Kamic, address@hidden

The GRIB Java Decoder includes a directory full of GRIBTAB files,
and Robb indicated that additional GRIBTABs could be added to that
directory and included in their distribution "jar". That jar is in
turn included in the netCDF-Java distribution and thence in
Panoply. You should check with Robb to see what is required to
get your GRIBTABs included.

Otherwise, it turns out that there is a way to "register" a user's
GRIBTAB file at runtime when using the GRIB Decoder. The big hitch
with this is that 1) one has to know enough to do this, and 2)
it has to be done before any GRIB files are opened. I would guess
that this is not an optimal solution if you have users who are
unfamiliar with GRIB and expect that all they have to do is open
the dataset. (You could have counted me amongst that crowd just a
few hours ago.)

rbs








On Jul 22, 2009, at 16:56, Christopher Lynnes wrote:

Well, let us take a more detailed look at the issue, and maybe we'll
submit something to support-netcdf-java.

On Jul 22, 2009, at 4:21 PM, Robert B. Schmunk wrote:


Chris,

I think this is something you probably need to bring up with John
Caron or the IDV developers at Unidata. I'm using John's netCDF-Java
library for all interaction with GRIB and HDF datasets, along with
netCDF datasets, and so I have minimal knowledge of how GRIB files
are structured and what is expected to be in them.

Since IDV is a Unidata product, it's no surprise that that app
would have the same problem.

I'll try throwing the question to John C. and see what he might
say.

rbs




On Jul 22, 2009, at 15:12, Christopher Lynnes wrote:

On Jul 22, 2009, at 3:02 PM, Christopher Lynnes wrote:

Robert,
We have some GRIB files with non-standard GRIBTABs.  The problem
is
that when we read them in through Panoply, the variable names are
wrong (as one would expect), but there is no way for the user to
know
that they are wrong, esp. users that are unfamiliar with GRIB.
Any
ideas?

To amplify,  we're wondering if octet 12 could be inspected for the
Table Version number, and if other than 2, maybe just display the
parameter index number instead of trying to look the name up.  Or
is
this something that needs to be addressed to the netcdf library
developers?

Also, any idea on whether you will support reading in GRIB files
with the associated GRIBTAB (aka parameter index) file?
BTW, Panoply is not alone in this area; we have the same dilemma
with IDV.

We have some examples if you care to play with them, e.g.:
Data file: 
ftp://agdisc.gsfc.nasa.gov/data/s4pa//GLDAS/GLDAS_VIC10_3H//2009/165/GLDAS_VIC10_3H.A2009165.2100.001.grb
GRIBTAB file: http://disc.sci.gsfc.nasa.gov/hydrology/grib_tabs/gribtab_VIC.txt
--
Christopher Lynnes             NASA/GSFC, Code 610.2
301-614-5185


--
Christopher Lynnes             NASA/GSFC, Code 610.2
301-614-5185




--
Robert B. Schmunk, address@hidden
NASA Goddard Institute for Space Studies, 2880 Broadway, New York,
NY
10025



--
Christopher Lynnes             NASA/GSFC, Code 610.2
301-614-5185




--
Robert B. Schmunk, address@hidden
NASA Goddard Institute for Space Studies, 2880 Broadway, New York, NY
10025



--
Christopher Lynnes             NASA/GSFC, Code 610.2
301-614-5185


===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================