Zeb:Software for Integration, Display, and Management of Diverse Environmental Data Sets

Jonathan Corbet, Cynthia Mueller, Chris Burghart, Kristine Gould, and Gary Granger

Figure 1

Abstract

This paper describes the Zeb software for integration, display and management of diverse environmental data sets. Zeb's primary use is for the superpositioning of observational data sets (such as those collected by satellite, radar, mesonet and aircraft) and analysis products (such as model results, dual-Doppler synthesis or algorithm output). Data may be overlaid on a variety of display types, including constant altitude planes, vertical cross-sections, X-Y graphs, Skew-T plots and time-height profiles. The fields for display, color tables, contour intervals and various other display options are defined using an icon based user-interface. This highly flexible system allows scientific investigators to interactively superimpose and highlight diverse data sets; thus aiding data interpretation.

Data handling capabilities permit external analysis programs to be easily linked with display and data storage processes. The data store accepts incoming data, stores it on disk, and makes it available to processes which need it. An application library is available for data handling. The library functions allow data storage, retrieval and queries using a single applications interface, regardless of the data's source and organization.

The software system runs under UNIX and the X Window system. Zeb has been used for real-time project control as well as data interpretation at investigators' home institutions. Features and implementation are explained along with examples of graphic output.

1. Introduction

The Atmospheric Technology Division (ATD) of the National Center for Atmospheric Research has developed the Zeb software system for geophysical data integration, display and handling. Zeb allows superpositioning of observational data sets (e.g. those collected by satellite, radar, mesonet and aircraft) and analysis products (e.g. model results, dual-Doppler synthesis or algorithm output). This software system may be used for project control and data interpretation both in the field and on a user's home system. Zeb was used for data display, project control and review during the Convection and Precipitation Electrification Experiment (CaPE), STORM Fronts Experiment Systems Test (STORM-FEST), Real-time Analysis and Prediction of Storms Project (RAPS `92), and TOGA Coupled Ocean-Atmosphere Response Experiment (TOGA-COARE). In addition, it serves as the real-time display for the Department of Energy's Atmospheric Radiation Measurement (ARM) program, ATD's Integrated Sounding System (ISS) facility and for the Next Generation Upper-Air Sounding System (NEXUS). Zeb supports display of data sets collected in real-time, quality-assured data, and analysis products for these projects along with several others.

Zeb allows diverse data sets to be superimposed in a variety of displays including surface plots, constant-altitude plots, vertical cross sections, X-Y graphs, Skew-T plots and time-height profiles. Display mode, time and space scales, contouring, and color schemes are under user control. The user-interface is a window-based, icon driven system. This flexibility, configurability and ease of use allows interpretation of diverse observational data sets and analysis products.

The remainder of this paper reviews Zeb's history (Section 2), system overview (Section 3), display and user-interface features (Section 4) and the data handling capabilities (Section 5). Future directions are presented in Section 6.

2. History

The early development of Zeb was oriented toward the needs of field project control. The need for real-time integration and display for forecasting and platform deployment during field programs has long been recognized (Brock and Wilson 1981; Doswell and Maddox 1986; Dirks et. al. 1988; Moore et.al. 1989). Integrated displays for operational forecasts have been developed by UNIDATA, McIDAS, and NOAA's Forecast Systems Laboratory. While these displays can be of great help in a field program, they integrate and display only a limited number of operational data sets. Other project-specific observations need to be available for real-time display. Zeb was designed to work with both research and operational datasets.

Early designs for a research oriented integrated display system for field project control were established within ATD by 1980 (Hayden et. al., 1980) and were documented by Brock and Wilson (1981). The original designs have been modified based on user requirements and increased hardware and software capabilities. User requirements have been established based on scientific input as well as the design team's first hand knowledge of field project control and subsequent data analysis gained through experience supporting all aspects of meteorological field programs. In addition, formal input was collected during the Atmospheric Technology Division Users Conference in April, 1991. Thus the Zeb design goals were based on an evolution of ideas and capabilities that have matured over 10+ years and tens of field programs. Zeb continues to evolve because of the synergistic relationship developed between scientific users and the development team.

Zeb was first used for project control during the Convection and Precipitation Electrification Experiment (CaPE). During this experiment research radar, aircraft tracks, surface data, lightning position, and a variety of maps were available in real-time. By superpositioning these data, the personnel in the control center where able to quickly discern the platform status and current weather. Interactive capabilities allowed: 1) the operations director to highlight and display an area of interest on all workstations, 2) the flight coordinators to outline the proposed flight tracks and output coordinates from a variety of vortacs, and 3) the radar coordinator to interactively calculate scan strategies and send the scan parameters to the remote radars. A summary data set was collected during real-time operations. The summary data set and software were distributed at the end of the project. This distribution allowed investigators to review the data collected in real-time. The initial field test was successful (personal letters from 10 of the major PIs in the program). However, generous feedback by scientists during operations allowed ATD to identify several areas that required improvement. Field testing continued during the STORM-FEST and TOGA-COARE projects. These projects broadened the user base, expanded capabilities, and established Zeb's utility for all scales of meteorological analysis.

Besides real-time data display, a main design goal was the ability to support in-field and post analysis. Prior to Zeb, all of the ATD software was developed either for real-time or post processing. This dichotomy required users to learn and to reformat their data for separate programs. Zeb's original design allowed for post analysis of the data sets collected in real-time and of quality assured data or analysis products prepared after the end of operations. This capability was used extensively during the TOGA-COARE project. Summary displays of the data and the overall conditions associated with each of the aircraft missions were compiled after they were conducted. A record of the entire aircraft program was thus assembled, with flight tracks, infrared satellite imagery, and radar data composites superimposed. The benefits of in-field data review include the ability: 1) to evaluate platform performance, 2) to fine-tune the experiment's data collection activities, and 3) to develop an operations summary and climatology of the weather during the project.

Recently Zeb has been used to display STORM-FEST data distributed on a compact disk (CDROM). The STORM-FEST CDROM gives scientific investigators a complete set of quality controlled data and display software. The data sets include satellite, Weather Service International (WSI) NOWRAD WSR-57 radar composites, NCAR CP4 radar, composite surface and sounding data, and aircraft data. Zeb and WINDS (Horton, 1992) display software are included on the CDROM, allowing investigators to create integrated displays of the data. A sample Zeb display created using the CDROM is described in Section 3. Because the CDROM contains a variety of data sets as well as visualization software, it allows investigators to quickly review the data and start analysis.

Currently, Zeb is being used at over 30 institutions both for research and for teaching. Researchers are using it for studying data from the field projects. In the classroom it is used for illustrations and laboratory analysis of meteorological phenomena such as the structure of convective storms, squall line dynamics and cold frontal development (personal contacts).

3. Overview of Zeb

a. Sample Displays

Example displays are shown in Figure 1 (from the STORM-FEST CDROM) and Figure 2(from CaPE). Figure 1 is an example of data compiled after the project. Among other data, it contains corrected sounding, profiler and satellite data that were not available in real time. In contrast, Figure 2 shows a real-time configuration of data used by the CaPE Operations Director. Generally, each display configuration (a collection of windows on the screen along with the specification of their contents) contains the following four components; (1) the IconBar (shown in the upper left corner of Figure 1), (2) graphic windows (the data displays), (3) various widgets (widgets are small control windows which may be invoked by the user), and (4) the Event Logger (which is used for software development and diagnosis).

Figure 1 Shows a display created using data from the STORM-FEST CDROM during passage of a cold front through the U.S. Midwest. Four data display windows, and the iconbar are shown. The iconbar (explained in the text) is shown in the upper left corner. A constant altitude surface plot (lower left) contains the IR satellite image with contours of temperature superimposed. The temperature analysis was done using a Barnes analysis technique. The data used in the analysis were from hourly composites of NWS, ASOS and research surface networks. The location of the front is indicated by the tightly packed isotherms shown as color coded solid lines. Labels indicate the locations of the sounding and profile data used in the other windows. The Skew-T plot (upper left) shows data from the site labelled EAR (in the surface plot). The red lines indicate the profiles of temperature and dewpoint. Winds are shown by vectors that point in the direction of the wind. A vertical cross-section (upper right) is composed of data from the sounding sites that are shown in red (on the surface plot). Potential temperature measurements plotted at 2o K intervals are displayed. Finally, a time height profiler (lower right) contains data from the profiler station, FBYN1, labeled in orange on the surface plot.

Figure 2 A sample real-time Zeb display from the CaPE project is shown. The upper-left window shows the following data sets (listed in the order that they are represented by the Icons in the lower-left corner of the window); PAM gridded winds (red arrows), a road map (purple), the locations of the Cape radars (white circles), the map of florida (yellow) and the location of the operations center (green cross). During field operations this window was used to monitor the large scale surface winds. The window on the right is a surface plot of the CaPE network. The data shown are; radar reflectivity at 0.3o elevation (the elevation angle was fixed such that it was only updated with another 0.3o scan), a azimuth/range grid (beige), the locations of CaPE radars (white circles), the florida map (beige), the 30o dual-Doppler lobes (beige), PAM winds (orange), lightning data (none displayed), locations of sounding sites (white triangles), the Scan Optimizer box (yellow-see text for details), the spotlight (orange line), Storm 1 flight track (green), and the left and right azimuth limits from CP2 (white). The last graphics window shows the CP4 radar reflectivity, CP4 azimuth/range grids, the Storm 1 aircraft track, the scan optimizer box, the spotlight and the CP2 azimuth limits. The widget in the lower left is used for time-lapse data display.

Zeb can be run in real time, history or pseudo-real-time modes. History mode generates a static display for any given time; pseudo-real-time mode runs the system in a playback mode, simulating real-time events which happened in the past. In general, users prefer to work in history mode, moving backward and forward in time using the time control widget (shown in the lower right corner of Figure 1) or the "data available" pulldown menu. The time control widget allows the user to quickly control the reference time for one or all of the display windows. The reference time is used to determine which data sets are displayed by showing data collected at or before the reference time. The data available menu shows a list of times for which data from one or more platforms are available, and allows the user to select a reference time from that list.

b. Software structure

The Zeb system is a group of several independent, cooperating programs that run simultaneously. These processes are categorized by the following functions:

The processes are connected through a message-based communication system. The features and a brief description of the implementation of (1) the graphics and user interface and (2) the data store are highlighted in Secs. 4 and 5, respectively. To date, Zeb has been primarily used for display and data handling. However, capabilities designed into the system allow analysis programs to be linked to Zeb but maintained independently.

The bulk of the system was developed on Sun Microsystems workstations under the Unix operating system. Almost all of the code is written in the C programming language. The graphics and user interface are implemented with the X window system (Scheifler and Gettys 1986) and the Athena Widget Set. In addition, publicly-available tools from the Free Software Foundation, The X Consortium, and other sources are extensively used.

4. Graphics and User Interface

a. Display Windows

Any number of data displays may be present in any configuration. Figure 1 and 2 show three and four window configurations respectively. These windows show a variety of display types including surface plots, constant altitude plots, vertical cross-sections, Skew-T and profiler time-height plots. In all cases, data sets for display are interactively defined. The locations for the vertical cross-sections are interactively defined either by drawing a line on a constant altitude plot using the cursor or by entering positions using a widget (small windows with information or commands). Detailed descriptions of the data shown in each window can be found in the figure captions. Table 1 lists the types of displays currently available along with example data sets that can be represented in each window.

TABLE 1. Display types and corresponding data sets.

The Zeb display system was designed to provide maximum flexibility to the user. Thus, almost any aspect of a display window may be interactively changed, from large items like the types of platforms and fields that are displayed, down to details such as the width of lines, sizes of fonts, and colors. Display configurations may be stored on disk for use at a later time. This flexibility works to the advantage of the user by helping to clarify and emphasize any part of the display at any time, and is invaluable to the process of overlaying data sets. A complete list of Zeb's current display features is shown in Table 2.

Table 2. Zeb Functions

Superpositioning data often necessitates shifting one or more data fields in space. This need arises due to: 1) errors in navigation, or 2)data collected at different times. When datasets are not sampled at the same time, it may be necessary to shift one of them spatially to account for advection. A special widget provides an extensive constant and time-based spatial shifting capability.

b. Implementation of User Interface

The best displays are not useful if they are difficult to operate. Accordingly, much effort was put into the Zeb user interface. The intent from the beginning was to provide a highly-interactive, direct manipulation interface (Schneiderman 1983) with little or no need for users to remember keywords or commands. In order to implement such an interface, the software had to be flexible enough to allow several iterations in it's development and allow modified configurations for various applications.

User interface development requires an iterative process of development followed by user feedback (Gould and Lewis 1985). The first step in Zeb's implementation was to develop a prototype system that highlighted the functionality of the user interface. This system enable the development team to seek scientific input into the functionality of the interface before it was put into the field. Modifications have continued during field deployments where users and developers work together for long periods of time and exchange ideas. In-field changes are possible because of the flexibility of the interface.

In addition to easily modifying the interface, flexibility is required because Zeb needs to run under a variety of conditions. In a convective storm operations center, a high-speed situation develops where data needs to be displayed quickly and in a manner that is easily interpreted. In contrast, at an investigator's home institution the display flexibility required to examine specific features of interest is of highest priority.

This flexibility in the user interface is achieved through use of a command-based layer between the icon user-interface and the rest of the system. All the sytem capabilities are available as commands. In addition, a set of tools are provided that allow the definition of menus, actions and widgets at the command level. Therefore, an experienced user can reconfigure the interface at will.

c. User Interface Features

Almost all configurations of Zeb include an icon bar which provides for global control. The icon bar is shown in the upper left hand corners of Figs. 1 and 2. The icon bar generally contains: (1) a "help" icon (shown in Figure 1); (2) the "Zeb" icon used to change display configurations, "pop up" various data management and display widgets, and exit; and (3) the field icons, which represent the data that are available for display. A new data type or overlay may be added to any window by simply picking the desired platform and field from the icon bar, then clicking on the target window with the mouse. The icon bar can easily be configured to suit the individual user and project needs. Note, for example, that the icons for CaPE (Figure 2), are different from those used during STORMFEST (Figure 1).

The icons at the bottom of each graphics window are used to control the display of the data currently shown in that window. There is one icon present for each overlay in the window. Pulldown menus may be accessed in each icon through use of the mouse buttons. The left mouse button provides general control of the associated data field, with options including removal of the associated overlay, adjustment of plot limits, or changing the stacking order of overlays. Other mouse buttons access platform-specific menus to perform tasks such as changing fields, popping up special widgets, changing colors, and so on.

Various widgets are an important part of the user interface. When a function requiring a widget is requested from one of the icons, the widget "pops up" onto the screen and is available for use. Widgets may be kept on-screen if desired, or dismissed and recalled later if needed.

One of the more important widgets is the movie controller, shown in the lower-right corner of Figure 2. Time-lapse displays (movies) are extremely important in meteorological analysis. Features that are difficult to see in a still display often become obvious when the data are put in motion. The movie controller allows the user to set the time, time-interval and display speed for a movie, then to start and stop it as desired. The scrollbar at the bottom allows the user to manually display each movie frame. The time-lapse feature allows data to be superimposed and color tables modified before the movie is initiated, or while it is running.

Many other widgets exist to perform various functions. Since the user interface allows new widgets to be defined at will, without the need to change the source code, a new widget tends to be created whenever somebody thinks of a new capability they would like to have. In fact, many of the widgets which now form an integral part of the user interface were quickly developed to fill an immediate need during a field campaign.

The user interface makes customization of the display to a particular user's needs easy. Several tools exist for editing display configurations and the contents of display windows; these configurations may be saved to disk for recall at some later time.

In the field, the user interface has proven to be quite easy to learn and use. Training of users was a major concern in the early field tests of Zeb. Our experience was instead that most users learned by watching another user for a short period of time; most required no formal training at all. The Zeb interface encourages exploration, and users are quick to find and make use of even relatively obscure features.

d. Project Control Features

Figure 2 shows the Operations Director's display on an active day during the CaPE project. This set of graphic windows was the primary display for deployment and forecasting during the project. In this example, the experiment centered around two boundary-layer convergence zones that are shown by lines of enhanced radar reflectivity. The radar data in the upper right window of Figure 2 was updated whenever a new low-level surveillance scan was collected. The Operations Director entered a "spotlight" (shown as an orange line that crosses both boundaries) where the Director wanted the aircraft to sample. The spotlight was sent to all the workstations allowing all researchers to know the location of the prime area of study.

Real-time aircraft operations are aided by a wide variety of overlays and position information. Aircraft locations may be communicated to the operations center by (1)\x11telemetry systems on the aircraft, (2) phone line from FAA radar facilities or (3) voice over a radio. These locations are displayed as tracks. Tracks can be displayed as a fixed color or color-coded based on any available field (such as altitude). They may contain wind vectors or time markers at user-defined intervals. Overlays of restricted airspace and VOR/DME's are available. In addition, the exact position of any point on the screen relative to an aircraft or a user-chosen VOR/DME is available. In Figure 2, aircraft tracks are shown on both the upper right and lower left display windows. The aircraft data in the lower-left window was constantly updated so the aircraft coordinator could watch for thunderstorm growth near the aircraft.

The yellow box in Figure 2 shows the area to be scanned by the CP4 and CP3 radars. This box was entered interactively by the Radar Coordinator and input to the scan optimizer program (Burghart et. al., 1989). The scan optimizer calculated and displayed a set of scan stategies for the CP3 and CP4 radars. The Radar Coordinator would then choose and issue a single scan sequence. The scan parameters were sent via phone line to the radars where they were automatically ingested and used for the next volume scan. The scan optimizer program provides an example of how analysis software may be linked to Zeb. In this case, data from the data store (the locations of the box) was moved to an external analysis program (the scan optimizer) where calculations were made to determine scan strategies.

Numerous other project control tools exist. A heavily-used tool is a widget for manual entry of positions (i.e. sounding vans, ships, or aircraft). Widgets also display the status of specific observing platforms, tools for monitoring the status of data input streams, and tools to monitor the Zeb system as a whole.

5. Data Handling Capabilities

a. The Zeb data store

The data store is the database of the Zeb system. Its task is to accept incoming data, store it on disk, and make it available to processes which need it. The data store system is also responsible for distributing data over the network.

The features of the Zeb data store include:

The core of the data store is implemented in two parts. The first, the data store daemon, is an independent process which has control over the data store on a particular workstation. The data store daemon: (1) keeps track of all data in the system, (2) informs interested processes when new data has arrived, (3) coordinates access to data, and (4) occasionally ages data off the disk (only in real-time mode). Almost any sort of data store operation, such as storing or fetching data, requires interaction with the daemon process.

The second part, the application library, is a set of routines used by Zeb clients (independent processes) to access and retrieve data from the data store. The majority of the data handling is done by the application interface library. This library makes the capabilities of the data store available to the rest of the system. It is here that the actual handling of the data is done. The functions available in this library include:

For the rest of the system, the data store application library is the only means by which the data store may be accessed.

The actual data are stored in a set of directories, one for each platform. The platform may correspond to a physical sensor such as radar, satellite and aircraft or to a particular data set such as model output, dual-Doppler synthesis or an analysis product from an independent program. A set of files exists for each platform containing the actual data differentiated by time and field. Thus the three indices [platform, field, time] uniquely identify any data within the system. Breaks between files are used to delimit logical breaks in the data; thus, for example, radar data are stored with one scan volume in each file, and soundings are stored with one flight in each file. All access to the data within the files is performed by the access library.

An additional component of the data store is the Network Transfer (NetXfr) process. NetXfr distributes data over the network between machines, in real time. When it is configured in a simple mode, NetXfr sends data through the message system as a series of messages. However, when high-bandwidth data are involved, the capacity of the local network may be exceeded (a certainty, when real-time radar data are being transferred). In this case, NetXfr can be configured to broadcast the data over the network using the User Datagram Protocol (UDP) (Postel 1980). The use of UDP broadcast means that the data travel over the network only once, even if a large number of machines are receiving them.

b. Data Store Features

The ability to ingest and display diverse data sets stemmed from the desire to provide a powerful display tool that could be used by multiple investigators. Although analysis methods vary between data sets and investigators, often display types are generic (for example, there are several objective analysis schemes and programs for remapping radar data to Cartesian space. However, once the data have been remapped, the required horizontal and vertical displays of the data are the same. Thus, Zeb has added several features to aid in incorporating data from outside analysis programs and to manage datasets.

Data may be ingested into or exported from Zeb by direct access of network exchange files or by using library functions. These functions allow the user to store, retrieve, and query the data store. The library calls are the same regardless of the data source or its organization. Because it is relatively easy to move data into and out of the Zeb data store, data analysis can be done independently and the result displayed in Zeb.

Data are stored in the Network Common Data Format (netCDF) (Rew and Davis 1990). Through the use of netCDF and its conventions, it is possible to store a wide variety of data in a single file format. The use of netCDF should make it easier to exchange data between Zeb and other systems (such as a user's analysis packages). A few types of data (most notably, image data) are stored in an internal format for performance reasons.

Ingest modules for conversions from a variety of formats to netCDF are available. Currently, conversion software is available for (1) all the data formats that ATD supports, (2) data that have been displayed in real-time, and (3) NCAR's CEDRIC 3-D grid format (Miller and Anderson, 1993), and (4) PC-Mcidas image formats.

A "dsmanage" utility allows data to be removed or added to the disk without the need to deal directly with disk files or tapes. Users are presented with a list of data sets currently on the local disk, the amount of space they consume and the number of files. Data can be deleted by inputting begin and end times or selecting individual files. Data may be loaded from tape or CDROM under control of a similar interface that lets the user select the data of interest. The amount of space available on the local disk and the required space for the selected data are automatically calculated and displayed.

6. Future Work

Work for the near future will include: (1) interfacing the data store to a commercial database system to provide a powerful, general metadata query and display system, (2) extending the data store to provide a distributed, internet-wide data repository, where data are made available at all network sites, (3) automating the configuration processes, and (4) adding more features for editing and calculating derived fields of data.

The NCAR Research Data Program is currently making the Zeb system available to the university research community, either in the form of the STORM-FEST CDROM set, or as a source-code distribution available over the network. In addition, configuration files for all projects in which Zeb has been used are available with the source code distribution, and some quick-look datasets are available as well. The software is distributed without warranty, and may not be used for commercial purposes. Persons interested in obtaining Zeb should contact Michele Case at (303) 497-8756.

7. Acknowledgments

Without the support and encouragement provided by P. Herzegh, D. Oye, and R. Carbone, the Zeb project would have never gotten off the ground. Much useful scientific guidance was provided by J. Wilson and from the investigators - far too numerous to mention - who have used the system over the last few years. S. Yuter provided useful early design assistance. Many useful additions were provided by the Integrated Sounding System/NEXUS groups under the leadership of C. Martin. M. Case has provided a great deal of help in getting Zeb out to the users. R. Melton and D. Gracio provided input into the design of the ARM installation. M. Siedelberg and E. Miller provided data communications and real-time support during field programs. We would also like to give special thanks to the NCAR Research Application Project and Battelle Pacific Northwest Laboratories (Atmospheric Radiation Project) for the substantial support they have provided toward the development of the system. R. Houze and S. Yuter provided useful insights into describing the software. Valuable comments on an early version of the manuscript were provided by J. Wilson, D. Johnson, C. Martin, and B. Anderson. Final reviews by P. Herzegh, R. Hoffman, and R. Fox were extremely useful.

. References

  1. Asente, P. J., and R. R. Swick, 1990: The X Window System Toolkit. Digital Press, 967pp.
  2. Brock, F. V., and J. W. Wilson, 1981: MECCA: A Portable System for Real-time Acquisition and Display of Field Data. Preprints: 20th Conference on Radar Meteorology. Boston, Amer. Meteor. Soc., 700-703.
  3. Burghart, C., P. Wyngaard, P. Herzegh, and J. Wilson, 1989: A program for optimization of meteorological radar scanning. Preprints: 24th Conference on Radar Meteorology. Tallahassee, Amer. Meteor. Soc., 573-576.
  4. Dirks, R. A., J. P. Kuettner and J. A. Moore, 1988: Genesis of Atlantic Lows Experiment (GALE): An Overview. Bull. Amer. Meteor. Soc., 69, 148-160.
  5. Doswell, C. A. and R. A. Maddox, 1986: The Role of Diagnosis in Weather Forecasting. Proceedings: 11th Conference on Weather Forecasting and Analysis. Boston, Amer. Meteor. Soc., 177-182.
  6. Gould, J. D., and C. Lewis, 1985: Designing for Usability: Key Principles and What Designers Think. Communications of the ACM, 3, 300-311.
  7. Hayden, G, R. Rew, P. Treece, and G. Woods, 1980: Requirements Analysis for Event Graphical Analysis and Display System (EGADS). National Center for Atmospheric Research: Atmospheric Technology Division Document, 72pp.
  8. Horton, G., 1992: WINdow Display System Overview. National Center for Atmospheric Research: Atmospheric Technology Division Document, 36 pp.
  9. Miller, L. J., and W. D. Anderson, 1993: CEDRIC: Custom Editing and Display of Reduced Information in Cartesian Space. National Center for Atmospheric Research: Mesoscale and Microscale Meteorology Document, 120 pp.
  10. Moore, J. A., C. K. Mueller, and J. W. Wilson, 1989: A Prototype Control Center for Field Programs and Prospects for the Future. Preprints: 24th Conference on Radar Meteorology. Tallahassee, Amer. Meteor. Soc., 605-608.
  11. Ousterhout, J., 1993: An Introduction to Tcl and Tk, Addision Wesley, 390 pp.
  12. Postel, J. B., 1980: User Datagram Protocol. Request For Comments 768, DDN Network Information Center, SRI International, 3 pp.
  13. Rew, R. K., and G. P. Davis, 1990: NetCDF: An Interface for Scientific Data Access. IEEE Computer Graphics and Applications, July, 76-82.
  14. Scheifler, R. W., and J. Gettys, 1986: The X Window System. ACM Trans. On Graphics, 2, 79-109.
  15. Shneiderman, B., 1983: Direct Manipulation: A Step Beyond Programming Languages. IEEE Computer, August, 57-62.