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

Re: Paper on OpenDAP

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.

-Roy M.

At 4:33 PM -0600 8/23/05, John Caron wrote:
Don Murray wrote:

Hi Ethan-

Ethan Davis wrote:

I just wanted to dig a bit deeper into the BUFR issue.

Does anyone know of a Java library for reading BUFR data?

No. I thought the nj22 team was going to write one. ;-)

It doesnt appear that we have the resources for now.

I looked around a bit but didn't find anything. The reason I ask is that the netCDF-java 2.2 library (nj22) has an interface for allowing other data formats to be read through the nj22 API. We've used this to add reading of several non-netcdf formats to nj22 (GRIB-1, GRIB-2, GINI, NIDS, NEXRAD level II, e.g.). If there is a java library out there it might not be too hard to add BUFR reading to nj22.

There are a couple of issues with BUFR.  One is that it is not like
GRIB in that a BUFR file may have point observations, trajectories,
winds, etc.  I'm not sure how the IOServiceProvider interface does at
figuring out which type of data type to create.

The IOSP job is just to read the data into the nj22 data model, so in principle it doesnt need to know the datatype.
In practice, we would likely optimize how this is done based on the datatype.

A second, major problem with BUFR is that it is like GML. Although there is a standard format, there are no standard vocabularies for what the data look like. One of the biggest problems is getting all the tables for a particular dataset (worse than GRIB).

i feel your pain.

we dont try to do all GRIBs, but just the ones that are in use, and so we keep growing it as we go along. I suppose the same strategy would work for BUFR.

The interface is ucar.nc2.IOServiceProvider. We probably need to work on the documentation but there are several example implementations in the nj22 code. If anyone wants to take a look at this, we could advise and (as time permits) assist. Once an IOSP was done, the TDS could serve the data out through OPeNDAP.

Would the IOSP layer allow you to read in one BUFR file as
point data and another as a trajectory or is it "datatype"

yes, as above.

Since the NWS is moving toward sending METARs in BUFR format, we'll need something soon.

do you know if theres any sample data yet?

Tennessee, what kind of data is your BUFR?

Don ************************************************************* Don Murray UCAR Unidata Program address@hidden P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm "Time makes everyone interesting, even YOU!" *************************************************************

"The contents of this message do not reflect any position of the Government or NOAA."
Roy Mendelssohn
Supervisory Operations Research Analyst
Environmental Research Division
Southwest Fisheries Science Center
1352 Lighthouse Avenue
Pacific Grove, CA 93950-2097

e-mail: address@hidden (Note new e-mail address)
voice: (831)-648-9029
fax: (831)-648-8440
www: http://www.pfeg.noaa.gov/

"Old age and treachery will overcome youth and skill."

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.