>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.