1. INTRODUCTION

The Forecast Systems Laboratory has a history of developing meteorological workstations designed for use by operational weather forecasters. WFO-Advanced is the latest of these workstations, and will be the basis for the site component of AWIPS. A companion paper to this one discusses the software design of the WFO-Advanced software as a whole (Grote and Biere 1998). In contrast, the goal of this paper is to address the workstation display software component D2D (Display 2 Dimensions) in more depth. This discussion is based in part on the more detailed WFO-Advanced Design document available on the Web (FSL 1997). A large number of people have contributed both to the design, and to that document.

2. SYSTEM CONTEXT

D2D was designed to run in a high-end computer workstation hardware environment. The target platform is an HP-UX workstation with 256 Megabytes of RAM (even more memory can be productively used) running the X window system (X11R5 at present) with two HP CRX-24 family display cards driving two color monitors. Although we have not done so, we are confident that the software could be ported to other UNIX environments with relative ease, provided they have lots of RAM, and 24-bit X Window display capabilities.

The software supports two dual-headed X server configurations: one X server driving two displays sharing a single keyboard and mouse; or two X servers each driving a dedicated display, keyboard, and mouse. In the two-server configuration, an optional keypad for each display is supported, allowing the two keyboards to be put aside to reduce desktop clutter. (The software will also run on a more typical single-headed, single X server workstation.)

Of course, D2D is coupled to the rest of the WFO-Advanced system, and depends on it to supply meteorological data. From a process view, the coupling is very tight, since most D2D processes include a large number of data management and other WFO-Advanced libraries. From a design view, the coupling is less severe, since most of the services provided by the rest of the system have explicit and limited software interfaces.

3. PRINCIPAL PROCESSES

When D2D is started on a display, the user is presented with a single large window containing five major panels, each displaying a map background. Each of these panels is a separate instance of an Interactive Graphics Capability (IGC) process. The rest of the top-level window, including all of the visible user interface widgets, and the sashes between the IGC panes, is run by a single process, called the UI (User Interface) process. For a large category of products, the UI process delegates product selection user interface responsibility to the volume browser, an independent process that is run as a regular application.

The UI process is constantly communicating with the 5 IGC processes. When the UI requests a service supplied by one of the IGCs, it does so by calling a member function of an object of class IGC. The IGC object is a proxy (Gamma et al. 1995, p 207) for an object of class IGC_Impl in the actual IGC process. The proxy class IGC is responsible for forwarding the message on to the correct process for which it is the proxy. The IGC and IGC_Impl classes are both inherited from class IGC_ABC (for Abstract Base Class), which defines the methods supported by the class.

Communication from an IGC process to the UI is done in a similar manner, but the proxy pattern is not implemented as explicitly as in the other direction. Each IGC process has a singleton object (Gamma et al. 1995, p 127), of class UI_WorkspaceManager. There is also a single workspace manager in the UI process, but no abstract base class to link the two.

4. USER INTERFACE PROCESS (UI)

The UI process has the primary responsibility of collecting user product requests from various menus and dialog boxes, and forwarding them on to the process driving the large IGC pane. It also coordinates between the two IGC panes involved in a swap between a small pane and the large pane.

4.1 User View of the UI Process

The UI process controls the layout of the user interface widgets within the main window, including the resizable IGC panes. The main user interface components within the top-level UI window are (from top to bottom) menu bar, toolbar, IGC panes, and status bar. The menu bar implements a set of pull-down menus, in the usual Motif-like way.

The toolbar contains a set of user interface controls for the most commonly used operations. The entire toolbar can optionally be hidden to provide more viewing area in the IGC panes below it. In most cases, the functions available via the toolbar are also available (redundantly) from the menu bar. Availability of the commands in the menu bar allows for keyboard accelerators to be added for common commands, and facilitates browsing of the menus to learn the user interface. Providing the commands in a toolbar allows immediate one-click access to the most common commands. To save space, many of the buttons in the toolbar use icons rather than text labels. To help learn the icon functions, context-dependent labels pop up automatically whenever the cursor hovers over one of the icons longer than one-half second.

The status bar at the bottom of the main window provides two status announcement widgets: one for general system status messages, and a second dedicated to local radar acquisition status messages.

Most of the screen real estate in the top-level window is dedicated to the set of 5 IGC panes. The frames separating the IGC panes from one another are active user interface sashes, that can be dragged by the user to reallocate screen space between the IGC panes. The vertical sash separates the main IGC pane on the right from a stack of 4 small IGC panes on the left. The horizontal sashes between the small IGC panes are also moveable. The main IGC pane is always the focus of product selection and other commands from the menu bar and toolbar. The main IGC can be immediately swapped with any of the small panes by clicking the right mouse button over the desired small pane. This resizable paned strategy has been adopted to provide some flexibility in the use and sizing of the IGC panes, while avoiding the user interface confusion and window management overhead of multiple independent top-level IGC windows.

4.2 UI Process Decomposition

The UI process is a Tcl/Tk script (Ousterhout 1994), run with a specialized Tcl interpreter built with various extensions. Following are some of the more important components that are linked into this interpreter, which provide the efficiency of compiled code, with the flexibility of an interpreter:

• TclDataMgmt - provides access to the basic data management services. Tcl commands are implemented for each of the various tables that drive D2D, and for Depictable inventory services.
• TclLogStream - implements a Tcl command for each of the standard WFO-advanced logging levels: logProblem, logBug, logEvent, etc.
• TclIGC - provides a Tcl command interface to the IGC proxy class, and a Tk widget to contain the IGC.
• TclWorkspaceMgr - implements a single Tcl command (workspace_mgr) that allows the caller to register for categories of messages from the IGC processes UI_Workspace manager objects, for IGC pane and user interface Widget control and synchronization.
• TclTextBuffer and TclInfoFileServer - provide Tcl commands for a simple interface for finding and reading some D2D configuration text files.
• TclStatusMgr - handles the status messages that are written to the status bar at the bottom of the main window.
• TclConfig - provides access to the standard WFO-Advanced configuration file mechanism.

5. VOLUME BROWSER

For a large category of data, including gridded products, the user interface to product selection and inventory times is via the volume browser, which looks like a UI dialog box, but is actually implemented as an entirely independent process. The volume browser uses the standard D2D application interface (Kelly 1997), which provides a lightweight mechanism for adding independent processes to the UI menu bar and controlling their execution.

6. INTERACTIVE GRAPHICS CAPABILITY

The IGC is the data integration and visualization heart of D2D. There are two main aspects of data integration in the IGC: multiple datasets loaded to an IGC pane are visually collocated to a common map projection, and are temporally synchronized within frames when animating.

Responsibilities of the IGC include loading data, animation, zooming and roaming over the data, auto-update of the display as newer data are available, toggling visibility and unloading of individual datasets. The IGC also provides a context-dependent pop-up menu user interface within each pane, allowing direct control of its operation.

6.1 User View of the IGC

The data within an IGC are presented in two layers: a set of vector graphic products drawn on top of one another, and an opaque image background. On some hardware (including the HP CRX-24 display card family), the two layers can be implemented in two physically different 8-bit windows (sometimes called graphic overlay window, and image underlay window, respectively). In 24-bit color mode, the IGC simulates the two layers in a single 24-bit window. Where available, two 8-bit windows generally provide better performance than 24-bit windows, but 8-bit color tables are usually a scarce resource that must be managed by the IGC. When it runs out of 8-bit color tables, the IGC switches to using 24-bit windows.

The background image can be either a single 8-bit deep image, two images combined together or a multicolored vector graphic. The IGC provides dynamic color table modification for the background image, including the fraction of an image combination that is contributed by either of the two component images. The IGC provides a color bar keyed to image intensities.

Vector graphic products are each a single, unique color, modifiable by the user. Default color is based on the order of loading. Map backgrounds are treated specially by the software, and are always visually below any meteorological graphics.

As data are loaded to the IGC, a set of legends are maintained in the lower-right of the pane, color-keyed for vector data, showing the name and time information for each product in each frame. Legend information is reduced for small IGC panes.

The IGC uses the left and middle mouse buttons for zooming in and out, roaming, and sampling displayed data. The right button selects from a set of context-dependent popup menus. For example, the popup menu over a graphic legend allows one to change the color or unload the corresponding product.

Further, each IGC pane can operate in a four-panel mode, in which the pane is split into four equal-sized panels, each of which can display a different set of products, over the same geographic area. Four linked cursors display within the four panels, and the panels zoom, roam, and sample in unison.

6.2 IGC Process Decomposition

The IGC process is a large C++ program, linked to most of the WFO-Advanced libraries. Access to data is provided via the Depictable class mechanism, described in the next section. Here we will discuss some of the major C++ classes within the IGC process.

• EventDispatcher - implements the "main event loop" of the IGC, dispatching all events through a common interface, whether they are X window system events, WFO-Advanced interprocess communication messages, or other events like system timers.
• IGC_Impl - is the recipient of all requests from the UI process. It can be thought of as a facade (Gamma et al. 1995, p 185) to the other objects in the IGC process.
• UI_WorkspaceManager - is a proxy to the UI process. Any object in the IGC process that needs to communicate with the UI process will call a public member of this singleton object.
• LoopingMgr - manages the timing of animation looping by telling the FrameSeq what frame to display.
• DisplayMgr - controls single vs. four-panel mode, by managing one or four DisplayPanel objects; handles the cursor, including associated X resources, and synchronization when in four-panel mode; decides when a DisplayPanel should operate with an 8-bit X window vs. a 24-bit one; and in general, arbitrates resources that are shared between DisplayPanels.
• DisplayPanel - displays meteorological data (from a Depictable), managing the associated X windows, in either an 8-bit or 24-bit mode.
• ViewMgr - manages the scale and map projection, including zoom and roam information, used by all loaded products within an IGC.
• FrameSeq - manages the time-matching of products to specific frames of an animation loop, for temporal data integration.
• Frame - represents a single frame of an animation loop. Each frame has a nominal time associated, and a set of objects (DepictTuples) for maintaining information about products loaded to the frame.
• DepictTuple - is an abstract base class from which two variants are derived: GraphicDepictTuple and ImageDepictTuple. The DepictTuple can be thought of as a container for two objects: a Depictable and a DepictSeq.
• DepictSeq - is an abstract base class from which two variants are derived: GraphicDepictSeq and ImageDepictSeq. The DepictSeq class encapsulates information about a Depictable that is common to all frames of the Depictable, such as color information, load attributes, and visibility.

6.3 Depictables

Depictable is an abstract class used by the IGC, that encapsulates a way of rendering a particular meteorological dataset. A Depictable knows both how to read the dataset, and how to draw it. A Depictable has a time associated with it, and so represents the data at a particular time. It also generally has information about what subset of information to display. For example, the satellite image Depictable class knows how to display any GOES satellite imagery in the database, but a particular instance will display data for a particular time and spectral channel.

There is an extensive Depictable class hierarchy, the most significant use of inheritance in the WFO-Advanced design. Depictable is the original abstract base class of the hierarchy, from which GraphicDepictable and ImageDepictable (also abstract) are derived. There are over 50 concrete classes derived from Depictable. The Depictable class hierarchy is specialized by data source, rendering strategy and frame of reference. For example, the concrete class SatPVImageDepict displays satellite data as an image, in a plan-view projection, and GridTHContourDepict displays gridded data as contours in a time-height display.

Part of the power of Depictables is that the IGC does not need to know much about a particular Depictable to use it. To the IGC, a Depictable is an instance of either GraphicDepictable or ImageDepictable, but it does not care beyond that. This gives us great flexibility to add new types of data or rendering techniques without modifying existing IGC code, by just creating a new class of Depictable. To further isolate the IGC, individual depictables are created by a parameterized factory method (Gamma et al. 1995, p 110) of the DepictableServer class.

There is an associated DepictableInventory class which provides information about valid times for which Depictables may be instantiated. Depictables often depend on more than one dataset, so the Depictable inventory is a function of the dependent data inventories.

Depictables do their drawing by using the public interface of abstract class Painter. This allows the Depictable to use the same rendering code whether drawing to the screen, or printing to a PostScript file.

7. D2D INTERFACE TO DATA MANAGEMENT

D2D relies on a large set of software interfaces to the services provided by the data management component of WFO-Advanced.

7.1 Data Retrieval and Inventory

To access the data they depict, Depictables usually rely on a data accessor class specific to their data type. For example, the satellite image Depictable class uses the SatAccessor class. Accessors generally provide both inventory information about what data are available, and retrieval functions for reading the data.

7.2 The Notification Server

D2D processes are notified of the availability of new data by the notification server process. The notification server receives messages from data acquisition processes after they have stored new data, and notifies D2D clients about any new Depictables that can now be displayed.

8. CONFIGURATION FILES AND KEYS

Many aspects of the run-time behavior of D2D are determined by a set of configuration files, or tables. Most of these configuration files are text files, maintained manually via a text editor. A common format is to separate a set of fields within each line by vertical bar characters, with the first field containing a unique key to the contents of its record. There is a C++ class for every such configuration file, implementing an interface to one record of the file. The constructor of each class takes the key as an argument. The contents of the files are stored in memory as associative arrays, resulting in very rapid access, at the expense of physical memory. A number of variations to this basic approach exist, depending on the characteristics of the individual table. Among the most commonly used configuration files are those providing information about Depictables and data.

8.1 Depictable Information

Every instance of a Depictable that can be displayed by D2D has an entry in the depictInfo.txt file. This file is an aggregate of several other files, some of which are automatically generated. The primary key into this table is called a DepictKey, implemented as an integer for space and hashing efficiency. To retrieve information about a particular Depictable, its DepictKey is passed to the constructor of class DM_DepictableInfo. Available member functions include information about the specific type of Depictable, legend information, and the specific datasets needed to create it.

8.2 Data Information

Among the public member functions of DM_Depictable is one returning a list of DataAccessKeys, which in turn are passed to the constructor of class DM_DataAccessInfo to retrieve information from file dataInfo.txt. This data information is generally used by data accessors, and includes information needed to access a particular dataset, such as the directory name in which it is stored.

9. CONCLUSION

In this broad-brush coverage of the D2D software design, we have only hit on the most prominent features. For those interested in further details of the D2D design and, more broadly, the WFO-Advanced design, the suggested starting point is the WFO-Advanced Overview document. The overview is actually quite extensive in its coverage of certain components of the design, including the IGC. It is always a struggle to keep the documentation updated, though, so parts are likely to be at least somewhat out of date. As of this writing, the UI process discussion still reflects an earlier implementation.

D2D is a work in progress, and continues to evolve and expand to meet new requirements. The underlying object-oriented architecture is sufficiently robust to allow such evolutionary development and modification to continue well into the AWIPS era.

10. REFERENCES

FSL, 1997: WFO-Advanced Overview. http://www-sdd.fsl.noaa.gov/~fxa/overview/WFO-A-Overview.book.html. Hardcopy also available from the author.

Gamma, E., R. Helm, R. Johnson, J. Vlissides, 1995: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

Grote, U. H., M. Biere, 1998: The WFO-Advanced System Software Architecture. 14th International Conference on Interactive Information and Processing Systems (IIPS) for Meteorology, Oceanography, and Hydrology, Phoenix, AZ, Amer. Meteor. Soc., 321-324.

Kelly, S., 1997: The Application Interface for the WFO-Advanced Forecaster Workstation, D2D. 13th International Conference on Interactive Information and Processing Systems (IIPS) for Meteorology, Oceanography, and Hydrology, Long Beach, CA, Amer. Meteor. Soc., 328-331.

Ousterhout, J., 1994: Tcl and the Tk Toolkit. Addison-Wesley.