NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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. Regards, Mark ~~~~~~~~~~~ Mark Ignaszewski Fleet Numerical Meteorology and Oceanography Center Science and Data Exploitation Team Monterey, CA 93943 USA ~~~~~ Voice: (+1) 831-656-4370 -- Fax: (+1) 831-656-4363 E-mail: Mark.Ignaszewski@xxxxxxxxxxxxxx -----Original Message----- 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. -Roy M. 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. >> >>-Roy M. > >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." ********************** Roy Mendelssohn Supervisory Operations Research Analyst NOAA/NMFS 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) voice: (831)-648-9029 fax: (831)-648-8440 www: http://www.pfeg.noaa.gov/ "Old age and treachery will overcome youth and skill."
netcdf-java archives: