From a users perspective (and not speaking for COLA), yes- they did
BUFR w/ the latest 1.9, but we have some issues with a couple of
required datasets and trying to figure a workaround (thus the perl bufr
decoder). But indeed, GDS handles plotting/decoding and gds serving of
(most?) BUFR. My pblm might be the data feed, the tables, or the
supplied metadata from eh originator. Regards, Glenn
James Gallagher wrote:
On Apr 15, 2005, at 6:52 AM, Glenn Rutledge wrote:
Wow,
This thread (pun intended) woke me up this Friday morning. WCS for
OPeDNAP will be a great leap forward for our shop and BUFR- the WMO
standard format for model input ("the BUFR tanks" at NCEP, Upper-Air
collectives, and other data near and dear to NWP, goes a long way
toward the implementation of a long awaited single (virtual)
interface to for anyone doing Model Intercomparison Projects, or
grib/NetCDF/BUFR... data analysis. We just wrote a BUFR decoder in
perl to overcome some of our issues with BUFR (as listed below), so
yes- NOMADS cares very much- more importantly users- last month we
had 4M downloads, serving over 3.6Tb of data and several emails
requesting BUFR access. NOAA has a requirement for BUFR
decode/access and display as well.
So, the NCDC NOMADS shop will gladly test or otherwise try to help in
this endeavor. Granted, we don't have the expertise to develop this-
we do have some talent to install and flush out issues associated
with these formats and interfaces thru OpeNDAP. One final note:
Grib2 is on the horizon....COLA is very much aware of this but not a
top priority. Anyone working this for GDS? Just wondering......
On the GIS/WCS front: Dan Holloway is taking a short vacation, but
when he gets back he can provide first-hand information about the
MapServer-OPeNDAP gateway. Briefly, MapServer uses the GDAL library to
read from various sources. Frank Warmerdam and I have written a
GDAL-DAP driver, so GDAL can be used to read from DAP servers. There
are limits, but Frank took my driver code and spiffed it up quite a
bit. He also wrote an OGR driver; OGR is the point data equivalent to
GDAL (GDAL is designed to work with raster data). So OGR can be used
to read from 'DAP Sequences' like the EPIC-DAP server from PMEL.
Caveat: I haven't tested this myself.
On the BUFR front: There's been considerable interest in support for
BUFR for a long time. I though that COLA was working on this? Can some
one on DODS TEch comment?
James
Thanks to all for your leadership and vision in all this....Glenn
John Caron wrote:
Tennessee Leeuwenburg wrote:
Hi guys,
We're looking at phase two of the project I'm working on at the
moment. Phase one involved hooking up our weirdo database to
OpenDAP, and it looks that that will be a success. There's one
thing that's not as wonderful as we might hope, and a couple of
cool extra things we'd like to do.
In order to cope with observational data stored in BUFR format,
we've had to write scripts for conversion to NetCDF prior to
serving it with thredds. I don't really like messing about in
thredds code if I can help it, on account of it makes code
maintainance that much harder. So we convert to NetCDF on a
product-by-product basis. But it would be way cool if we could
serve BUFR data more generally and without the conversion step. So
my question is : does anyone on this list care much about BUFR
data, and is anyone thinking much about how it might fit into an
OpenDAP context?
What kind of data is stored in BUFR?
We have an "I/O service provider" framework in netcdf-java version
2.2, where you can read non-native files as if they are netcdf
files. We have done GRIB files in this way, among others. It would
probably be very cool to be able to do that for BUFR files. If
you're interested i can tell you more.
The other angle is from the GIS world rather than the data sharing
world. We'd love to publish some of our data sets in such a way
that GIS packages can read them. To the best of my knowledge, no
GIS package reads OpenDAP or even NetCDF. This means we've either
got to do a conversion step from NetCDF into something that the GIS
packages can read, and then serve it out using a different server -
like a shapefile server for instance. So we would have to choose
specific products to make available, provide shapefile derivatives
from our hi-res NetCDF data, and tell people to go look there. It's
not the worst plan I've ever heard, but has anyone here heard about
any efforts to integrate OpenDAP more tightly with GIS software?
The next version of the THREDDS server will have OpenDAP integrated
into it. It will also have an experimental WCS server for gridded
data. The idea is that anything that can be read in through
netcdf-java version 2.2 can be served through opendap. If theres
enough georeferencing, these can also be served through WCS. Again
it would be cool to extend this to a WFS server for features,
although it would be a lot of work.
We are also working with ESRI on their project to read in netcdf
gridded files, and another project with GDAL/Cadcorp experimenting
with netcdf over WCS. Still both in research stage.
--
Glenn K. Rutledge
NOMADS Program Manager
NOAA Meteorologist / Physical Scientist
National Oceanic and Atmospheric Administration
National Climatic Data Center
151 Patton Ave
Asheville, North Carolina 28801
(828) 271-4097
The contents of this message are mine personally and do not
necessarily reflect any position of the Government or the National
Oceanic and Atmospheric Administration."
--
James Gallagher jgallagher at opendap.org
OPeNDAP, Inc 406.783.8663
--
Glenn K. Rutledge
NOMADS Program Manager
NOAA Meteorologist / Physical Scientist
National Oceanic and Atmospheric Administration
National Climatic Data Center
151 Patton Ave
Asheville, North Carolina 28801
(828) 271-4097
The contents of this message are mine personally
and do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration."
