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.
Linda Miller wrote:
All-
Your feedback is solicited!
*GEMPAK NAWIPS Functionality*
Below is information that the Unidata Users Committee has compiled about
functionalities that are not currently available, but are desirable in
the IDV.
GEMPAK will remain available for the indeterminate future, but at some
point, sites will have to migrate from GEMPAK to another package. It is
important that the community identify critical functionalities of the
current GEMPAK software that must be retained (or enhanced) in future
incarnations of AWIPS-II, IDV, or other packages. Which capabilities
could be handled by IDV, and which would not make sense to roll into
IDV? Which functionalities are most critical to the user community?
The following features are available in the Unidata NAWIPS suite. This
includes a set of programs that utilize data in GEMPAK format, and in
most cases use GEMPAK programs to manipulate and display data. These
programs include NMAP2, NSHARP, GARP, and GEMPAK.
This list is ****not** in order of priority. If you have thoughts on
how to rank this list, or have additional items, please share them in
the NAWIPS Migration forum:
http://www.unidata.ucar.edu/forums/forum.jspa?forumID=21
1) Objective analysis of raw observations to form evenly spaced grids
(In my view, this need has been mitigated by modern DA systems and
reanalyses to a large extent)
2) Ability to link object libraries to data manipulation programs
written in FORTRAN or other languages. This allows efficient storage and
easy i/o for diagnostic computations.
3) Ability to draw manual analyses (contours) using mouse, do shading,
annotate with text, etc. (currently utilized in NMAP2, used by National
Centers and synoptic classes)
4) Ability to save a manual analysis in gridded digital form (available
in NMAP2)
5) Ability to construct meteorograms for surface station data or other
data sources
6) Display and contouring of observed sounding cross sections
7) Replace trajectory capability (GPTRAJ) and enhance to allow full 3-D
trajectories if possible
8) Easy ability to generate graphics (e.g., for web pages) in Unix/Linux
scripts. The ability to write scripts quickly and easily that will allow
one to setup web pages so data can be accessed from remote locations
where a datafeed is not possible (Sweden, Antarctica, Australia).
9) Ensemble model features (displays and diagnostics)
10) SVG/PS output (publication quality)
11) Additional grid diagnostics
12) Careful checking of map-scale factors and other computations
13) Ability to interpolate between different vertical coordinates.
Especially critical is analysis in isentropic coordinates, and ability
to interpolate data between isentropic and other coordinate systems.
14) Time matching of data, such as radar overlay with surface obs- set
one display as the base time, retrieve other data based on that. Needs
to work in bundles
15) Sounding overlays ? ability to plot observed soundings, ACARS
soundings, model-forecast soundings, etc.
16) Sounding analysis package, such as currently available in NSHARP,
computation of hodographs, stability indices, etc.
17) Need to add the functionality needed to read all data distributed by
the IDD locally (e.g., GINI) and identify the "most recent" data files
regardless of data type.
18) If it is not there already, be able to set user preferences for
radar imagery, satellite imagery, etc., so that one doesn't need to
adjust map types, color scales, etc. If this functionality is already
built in, then we need to find a better way to communicate to new (and
old!) users.
19) NWS text data is also very important as well as soundings. An NWX
replacement is needed along with an NSHARP replacement. Display of MOS,
raw text obs, forecast discussions, in point-and-click interactive format
20) Ability for quick and easy display and overlay of 2-D model output,
raw observations, satellite and radar.
21) Ability to have satellite and radar loops update without manual
intervention is critical.
22) Display of Profiler Winds that are more than 24 hours old.
23) Missing Data:
- surface station model data (efficient access through TDS)
- lightning data
- watches/warnings
- ships/buoys
--
Larry Oolman
Department of Atmospheric Science
Dept. 3038
University of Wyoming
Laramie, WY 82071
ldoolman@xxxxxxxx
http://www-das.uwyo.edu
