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.
I'd like to second Larry's comments. He has hit on the major impediments we have in migreating away from Gempak to IDV. Clint On Fri, 2008-09-12 at 10:47 -0600, Larry D. Oolman wrote:
The biggest deterrents to our migration from GEMPAK to IDV are 1) quality of graphics 2) viewing text products 3) speed and memory 4) ease of scripting 5) grid manipulation. 1) Quality of graphics. We have a number of professors, scientist, and students that submit graphics from GEMPAK for publication. We don't feel that the quality of IDV is there yet and probably won't be unless it has the capability to output some form of vector graphics. A couple of our professors consider this the highest priority. 2) Text products. When I look at the weather, I spend as much time looking at the NWS text products as I do looking at graphic displays. 3) My web site is built largely on GEMPAK. I get about 120,000 actual data requests (not hits) per day. An IDV based server would be too slow to be feasible at this time. While 3D is nice, IDV is still uses too much memory to be unable to load large 3D sets such as a loop of level II radar or high resolution grids. 4) Ease of scripting. Have you ever tried to manually edit an xidv file? 5) GEMPAK's forte has and continues to be in manipulating grid fields. IDV is improving in this area but still isn't up to GEMPAK. As a note, we played with using IDV for our teaching and have gone back to mostly using GEMPAK.
gembud
archives: