Re: [thredds] On the suitability of BUFR and GRIB for archiving data

On 1/3/2012 12:10 PM, Paul Hamer wrote:
> All good stuff John. Here's hoping that the proposed solutions are 
> considered and who knows, even implemented.
>
> Unfortunately for Unidata the situation as it exists still requires a 
> workable approach and an easy way for users of the tools published by 
> you to add/update these tables during their own development of 
> models/observing systems.  I have, in my own experience, had several 
> groups ask about BUFR and GRIB encoding and how to handle something 
> that's not yet dealt with using WMO published tables. I'm going to be 
> working some with Java NetCDF on setting up what I consider to be a 
> more flexible table handling approach and will be happy to pass that 
> on if I can get it to a publishable standard. :-)

yes, id love to get that, and/or hear more about your plans.

im working on similar things in 4.3, heres the doc i have so far:

http://www.unidata.ucar.edu/software/netcdf-java/formats/GribTables.html

not positive if thats a done deal or not, some of it is harder than i 
expected.

> One thing missing from your paper is a valid date/time component for 
> each table entry. Both GRIB and BUFR (since edition 3, version 13) 
> allow for updates to existing table entries. One would require an 
> ability to obtain a valid table for the reference time of the data 
> being unpacked since the table may change within a single version 
> published - I know, it's completely the wrong way to do anything like 
> this but that is the reality.

this could only be done for a particular center, who would have to 
validate when they changed tables. whew, talk about brittle.


> Anyway, here's wishing all of you at Unidata the very best in 2012 and 
> thanks again to you and your colleagues for taking time to interview 
> me last year.

A pleasure. things are in a bit of turmoil here, sorry we didnt have 
anything to offer you right now.