This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Tom W., Sorry to have missed you this year at the MUG meeting...hope you are doing well. A question....we are about to start processing Meteosat-8 here, and Doris' group is interested in viewing the data in AWIPS, as well as McIDAS. I'm told that they are using your area-to-netcdf program for Meteosat-7 data. Do you know if it works with Meteosat-8 AREAs, as well? I'm still a little confused as to why Doris is using your program rather than the ADDE conversion code in IMGCOPY, but it may have something to do with different "flavors" of netCDF. Any ideas? Thanks, Bryan Batson 281-853-3238 From address@hidden Wed Nov 10 08:10:26 2004 Hi Bryan! Hey, sorry I missed you, too...and Doris. Especially since it was her "Last Hurrah" before getting hitched... By "Meteosat-8" do you mean "MSG"? If you do, then the answer is that the current release does not have the navigation code for that; however, I can make a new release if it's needed since I've just released the Java library MSG navigation (although there is some controversy about this since the EUMETSAT ADDE server puts different data into the nav block than the SSEC server apparently). For the AWIPS output, though, the navigation may not be needed, since the input AREA is a re-mapped image into an AWIPS projection. The reason they're using areatonetcdf is because IMGCOPY does not yet write an AWIPS formatted netcdf file. There is a server developed at Huntsville that does (I think they use it for MODIS?). If you want to go that route, you might contact "them" (not knowing who "them" is, but I do know that Russ Dengel has been working on-and-off on this for our ADDE server suite). So...that's the scooper -- hope all's well down your way! tom From address@hidden Wed Nov 10 09:12:35 2004 Thanks Tom. There still seems to be some confusion here (at least on my part) about the difference between what IMGCOPY does and what your code does. Regardless, I think we would like to get ahold of the MSG-friendly version of your code. Thanks, Bryan From address@hidden Wed Nov 10 09:15:56 2004 Bryan: The AWIPS NetCDF files must be in a particular format (attributes, variables, etc) in order for AWIPS to display the data. AFAIK, the current ADDE netcdf writer in MCIDAS-X does not produce netcdf files that are in that format. I'll update the areatonetcdf this week and let you know -- might not be til early next week, though... tom From address@hidden Wed Nov 10 09:18:28 2004 OK. No sweat. Is it your impression that your areatonetCDF code generates AWIPS format data? I ask this because one of Doris' folks said this: The netCDF images are created with a java script (AreaToNetCDF), which I think was written by Tom Whittaker at SSEC. Also, the netCDF files that are written out are not necessarily "AWIPS friendly". We had to do some navigational manipulating on AWIPS to get them to display. Thanks, Bryan From address@hidden Wed Nov 10 09:52:14 2004 Bryan: First off, I use "java" not "java script" (I wish the person at Netscape, Inc who coined "java script" would have chosen another name). Second, areatonetcdf output is strictly for the remapped AREA files created from McIDAS. Originally, there were only 2-3 projections that were "canned" in AWIPS and we got the remap "template" AREAs from the NWS for our work. They are correct that if you're using some other projection, then you have to manipulate the AWIPS settings...but it has nothing to do with areatonetcdf per se, it has to do with the remapping in McIDAS. the reason for all this is apparently the navigation info that one can put into netcdf files for AWIPS was ignored for the standard projections (which was what was used when we wrote this)...i don't know if it's still ignored or not, but the "bottom line" is there are no community conventions for storing images in netcdf (unlike gridded data), and so we could not, for example, put the GOES O&A data into the file and hope it would mean anything. If new conventions have been adopted by FSL for AWIPS image NetCDF files, then perhaps the new ADDE write server Russ is working on (or the one done a HSV) can make use of that information -- I just don't know (the areatonetcdf was created over 5 years ago and not really touched since then except to add updated navigation modules). tom