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

Re: netcdf and gempak



>From: Prof GWK Moore <address@hidden>
>Organization: Univ of Toronto
>Keywords: 199404211322.AA08103 GEMPAK5.1 netCDF interface conventions nuwg

Kent,

>In my group, we get and need data in a variety of different formats.
>We're finding it difficult keeping everything straight.  I'd like
>to simplify things by going to a standard file format.

We've been hearing this concern from our user community for quite
some time.  

>Netcdf looks interesting but my main concern is how well it is
>integrated into gempak.  I see no mentin of gempak in the 
>utilities.txt file.  Can gempak read netcdf files?
>If not, are there routines that translate netcdf into gempak format?
>Thanks
>Kent
>Professor G.W.K. Moore         Department of Physics
>60 St. George Street           University of Toronto
>Toronto,Ontario,Canada         M5S 1A7
>Phone: 416-978-4686            Fax:416-978-8905
>email:address@hidden

Currently there is no interface from netCDF to GEMPAK, either as 
stand alone programs or internal to GEMPAK.  However, because of the
concern of the community about proliferating data formats, I am involved
in a project to add a netCDF interface internal to GEMPAK.

The starting point for this project was to get involved with a group
of interested people here in Boulder and try to come up with some netCDF
conventions.  In principal, netCDF is a very nice format because it can
be completely self describing.  Using netCDF attributes, you can completely
describe the data within the data file itself.  This is important, especially
if people will be exchanging data.  In practice, however, netCDF files often
are as arbitrary and un-self-describing as any other data format.  The
perfect example of this are the netCDF files used in WXP.) 

So the aim of our conventions group was to define a minimum set of information 
that MUST be contained in each netCDF data file.  (Actually we've defined 3
sets, one for surface data, one for upper air data, and one for gridded 
data.)  Some of the types of conventions we've specified are: a completely
general way to specify time; a way to specify navigation for gridded data;
all variables must contain the attribute "units"; no variable must be refered
to by a specific name, rather each variable must have a "long name" attribute
so that it is interpretable by the human recipient; etc.  These conventions
will now allow me (and anyone else) to write a completely generic interface
to netCDF for GEMPAK.  Beyond adherence to the conventions, my code will NOT
require any arbitrary elements (variable names, etc) in the netCDF files.

Currently I am working on implementing the netCDF interface in the low level
GEMPAK data access libraries.  I am starting with the gridded data interface.
Once that is implemented and working, I will move on to the point source
data (upper air and surface).  As new data types present themselves, I will
add interfaces for those as well.  The bad news (for netCDF enthusiasts) is
that I am expecting a new version of GEMPAK (v 5.2) in the next month or
so.  I will have to devote significant time to preparing the new version for
the Unidata community, including writing installation tools and documentation.

So while there is definitely a netCDF/GEMPAK integration project going on, it
is necessarily bumped in priority by things like a new version of GEMPAK.
To be more quantitative, I hope to have a functioning gridded data interface
by the end of this summer.  At that point, I will probably be looking for
volunteers to test the interface.  Then I will tackle the point data interface,
which promises to be very sticky.

I hope this answers your questions.  I certainly am willing to discuss this
further with you if you have any other questions or comments.

Peggy
________________________________________________________________________
Peggy Bruehl                                    Unidata Program Center
address@hidden                          UCAR, PO Box 3000
(303) 497-8641                                  Boulder, CO 80307-3000
----------------------------------------------------------------------------
Unidata Mosaic Service                     URL http://www.unidata.ucar.edu/
****************************************************************************


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.