Here are some of the basic requirements for the realtime beam-by-beam radar display:
Interactively and dynamically select the field to display from among the set of available fields.
Segment, pan, and zoom the display. For example, ELDORA usually only shows the range of useful heights, from the ground to some maximum altitude. However SPOL usually shows the entire sweep.
Future ideas:
Allow use of the display for simple post-project or post-flight or post-IOP playback, but not for analysis. Perhaps utilize the archive indexing mentioned above.
Overlays of other meteorological data, geographical data, and so on.
Interactive collaboration with other displays. For example, allow one scientist to draw annotation on screen which scientists at other stations can see.
Backtracking. Provide looks at snapshots of past data.
Include engineering-type displays as part of the standard display.
Requirements from 1994 Memo. Some discussions in 1994 about radar displays resulted in a memo from Joe which listed these requirements. Originally, these requirements applied to the scientist Zebra display, but now many of them apply to the realtime radar display design. [Several were no longer applicable, like it should run on a SPARC 10 with 64 MB of memory!].
Capable of displaying beams in realtime, as soon as they arrive, at whatever rates the radar might generate them.
Responsive to user interaction even while no data arriving.
Selectable color scales, which the user can create, edit, and recall.
Ability to display any radar data variable without requiring recompiling the display to show new variables.
Display data from disk, tape, or ethernet.
Support arbitrary gate spacing.
Pan and zoom to arbitrary levels, average multiple gates located at the same pixel.
Fast, 1/4 second toggling between multiple fields, at least 2, where the particular 2 are chosen interactively by the user.
B-scan: draw successive beams at new angles even though antenna is stationary.
Blink a particular color or range of colors.
Overlays, including flight tracks and azimuth angles.
Display of selected radar housekeeping: fixed angle, azimuth, elevation, time, transmitted power.
RHI displays with proper scaling to keep storms vertical. Zooms with different magnification in height versus range are required for a useful display.
Beams must be displayed to the nearest .1 degree azimuthal resolution, and the display must support variable beam spacing.
Hardware independence.
Speed.
Cross-platform applicability: ELDORA, DOW, SPOL, lidars, ...
Easily customizable user interface.
Loosely coupled: no more hanging the entire system when a display malfunctions.
Remote interface control.
Simple addition of new display types.
Data soure independence.
Lower-level rendering layers use OpenGL, selected for its speed and cross-platform availability. (See the section called “OpenGL”.)
Graphical user interface built with Qt. (See the section called “Qt GUI Library”
ACE. (See the section called “ACE”
DataSpace library, under development by Gary.
C++ for speed.
PPI, stacked PPI
Support multiple platforms (radar or computer?) and variables.
The implementation of the display is divided into three layers:
Base OpenGL classes.
Type-specific OpenGL classes.
Toolkit-specific classes.