NOTE: The decoders mailing list is no longer active. The list archives are made available for historical reasons.
Greg Thompson wrote:
John et al, The NCAR-RAL files are purely experimental and a place-holder as the products migrate into true NCEP operations. For that reason, we have to accomodate a variety of situations. The good news is a copy of table2 (NCEP version) could be made then modified locally for our ADDS use to solve any Thredds issue we're having today. As those rare EXP products mature through the wickets, we can just keep altering our local copy of Table 2. Is this a workable strategy?
should be fine - you just have to keep track of the tables and make sure you're using the right ones.
--Greg On Thu, Jun 21, 2007 at 02:21:16PM -0600, John Caron wrote:So if I understand the situation, the GRIB files really should be changed to indicate that they are using a different table. Greg, that a possibility? If so, we can add the NCAR/RAL table to the GRIB library release.If not, the GRIB library can be confgured by the user to substitute the NCAR/RAL table. However, that means that real NCEP files will not be useable.Robb Kambic wrote:can you comment on this? -------- Original Message -------- Subject: Re: grib tables Date: Thu, 21 Jun 2007 08:52:36 -0600 From: Greg Thompson <gthompsn@xxxxxxxxxxxx> Organization: UCAR/Unidata To: Rob Weingruber <weingrub@xxxxxxxxxxxx> CC: caron@xxxxxxxx References: <46796BAB.7080506@xxxxxxxxxxxx> Rob, NCEP maintains what I refer to as the "GRIB bible." It is "Office Note 388" and I have two rather old copies in my office in a red 3-ring binder to the right of my desktop computer (lowest book shelf). You're welcome to look at the hard copy or download a more recent one off web - should be pretty easy to locate on Google using "GRIB Edition 1 Office Note 388." The most problematic part of GRIB is the need for the various a-priori lookup tables. Specifically "TABLE 2" which holds the names of the various weather variables. Since the GRIB spec only originally held 256 elements for these and NCEP has "bloated" the table with duplicates and can never "retire" out of use elements, they have since created a "secondary" table to hold more elements. That is now TABLE 129 I believe. Somewhere in the GRIB "Product Description Section (PDS)" [rather similar to MDV's field header] is an element that determines whether to use Table 129 or Table 2 to identify the parameter. Here's the deal (I believe). Thredds should be coded to allow a local user to "override" the NCEP Table 2 (or 129) and refer to some local version instead. Given that the GRIB spec allows for each "originating center" to produce its own Table 2, the need for local variants of Table 2 is almost mandatory. By the spec, elements 1-128 are "dictated" to be standardized by WMO and all originating centers should leave those alone. Each originating center is "expected" to maintain their own 129-255 elements. To my knowledge, there's no single person at NCAR to "maintain" that NCAR-wide table. I was personally responsible for getting NCEP to enter us (NCAR) as an originating center 13 years ago. John will know all about Table 2 if he's dealt much in GRIB (I expect he has). He may not know that Table 2 got completely filled and now Table 129 exists. Regardless, I contend that Thredds needs an inherent way to allow customization for local use to "ingest" a user-defined Table 2.Hiya, The management of GRIB parameter tables is the weakest link in the GRIB format. With that being said here's the THREDDS solution to the problem. According to the file attached to the original message, here are the variables in the file that designate which table to use. center = 7 NCEP sub_center = 0 table_version = 2 As stated, these files appear that they are coming from NCEP, so they use the NCEP parameter table. Since this is not the table that is wanted to decode the data, the user must overide the table with a local user defined table. Here's a page that shows how to overide the tables:http://www.unidata.ucar.edu/software/netcdf-java/tutorial/docGrib/tables/grib1tables.htmlOnce the table is overridden the only way to revert to the original table is to read in the original table again.Robb...
decoders archives: