Back when we stored BUFR data in our database at FNMOC, the BUFR data was
just a "blob" as far as the DBMS knew and there where other meta-data tables
that allowed for search and retrieval. Obviously, this did not allow full
relational searches of all data elements but that was the price of
efficiency. (We don't actually store data in BUFR format in our database
any more. However, there is a software layer that retrieves data and
encodes it into BUFR messages for transmission to external "customers".)
There are many types of data currently in BUFR on the GTS; buoy data,
aircraft data, and lots of satellite data. I think the WMO's solution to
the "standard vocabularies" issue (if I understood the comment correctly) is
to define "templates" that data providers will use for a particular type of
data. I haven't been following this issue very closely and do not know what
the status is.
Unfortunately (for this discussion), we do not use Java-based
encoders/decoders. I wonder if one of the other GTS data providers might
have a Java-based solution that would be useful for the nj22 efforts.
Fleet Numerical Meteorology and Oceanography Center
Science and Data Exploitation Team
Monterey, CA 93943
Voice: (+1) 831-656-4370 -- Fax: (+1) 831-656-4363
From: Roy Mendelssohn [mailto:Roy.Mendelssohn@xxxxxxxx]
Sent: Tuesday, August 23, 2005 4:54 PM
To: John Caron
Cc: THREDDS; netcdf-java@xxxxxxxxxxxxxxxx
Subject: Re: Paper on OpenDAP
FNMOC. GTS data. There have been many headaches along the way,
including a switch in local tables that we didn't know about. And
the translator that we have at least is pretty slow.
But that is the WMO standard, and that is what Fleet follows. I
don't know if they are still doing it, but at one time they were
storing the BUFR files (as BUFR) in a database system for access. I
was always curious as to the extra overhead to have any kind of a
useful key or other search information to find the correct BUFR file.
At 5:25 PM -0600 8/23/05, John Caron wrote:
>Roy Mendelssohn wrote:
>>Doesn't GRADS do BUFR? perhaps a partial solution lies there.
>>BTW, as a group that translates a ton of BUFR every month, boy do
>>we feel your pain. And getting the data out of BUFR, in terms of
>>reasonable access and display, is one of the best investments in
>>time that we make.
>Yes, but we are looking for a Java solution.
>Who writes your BUFR files, and what data is in there?
"The contents of this message do not reflect any position of the
Government or NOAA."
Supervisory Operations Research Analyst
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097
e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
"Old age and treachery will overcome youth and skill."