Figure 1. MetGen AIRMET Generation Tool on WFO-Advanced.
Using MetGen as an illustration, this paper describes the types of additional functionality the workstation supports, and the high level requirements for creating such a tool.
Figure 1. MetGen AIRMET Generation Tool on WFO-Advanced.
The extension framework supports multiple overlays of editable shapes. This is useful for handlingtime-sequenced series, such as matching the path of a storm with a series of time-stamped data displayed on the workstation. Editable shapes can belong to more than one overlay, easing housekeeping overhead for the developer and minimizing interprocess communication.
MetGen also has a graphical user interface (GUI), a window containing menu bars, buttons, selection lists, etc. (widgets, in GUI terminology), to allow forecasters to specify other AIRMET details.Thus, there are two ways in which a user interacts with MetGen: via interaction with the editable shapes, or via the GUI.
Finally, MetGen creates most of the AIRMET text automatically, and also provides editing capabilities for forecasters to add free form text to the final product.
Object-Oriented Programming - This is a style of programming where a program models a suite of interacting objects. Objects interact by sending each other messages. An object's behavior, the list of messages it recognizes, is defined by the object's class. An object of type X is an instantiation of class X. A new class may be subclassed (also called derived) from an existing class, allowing it to inherit all the functionality of the parent class. WFO-Advanced is written mainly in C++, an object-oriented programming language. In the upcoming discussion, class names and messages, as well as bits of C++ code, are printed in bold face.
Process - In the computer science sense, a process is a program - a separate and distinct piece of executable code. Since it is often desired that processes interact, the operating system provides mechanisms for processes to communicate with each other. WFO-Advanced uses these mechanisms to provide higher level abstractions for developers to use for interprocess communication.
Interactive Graphics Capability - The WFO-Advanced display capability is designed around the concept of an Interactive Graphics Capability (IGC), which is a process that retrieves and displays data. Each display monitor hosts five IGCs, one for each data display pane. A single "user interface" process manages the five IGCs and their interaction. See Biere (1998) and Grote and Biere (1998) for more information about WFO-Advanced software structure.
Extension - In WFO-Advanced, an extension is a process that provides the interactive graphics functionality described earlier. In addition to MetGen, WFO-Advanced extensions include WarnGen and Baselines. Although many extensions can be loaded at one time, only one extension can be active at a time.
Application - In the context of WFO-Advanced, an application is simply a separate program that can be invoked from the workstation. Much simpler in concept than an extension, an application is only minimally integrated into the workstation. In particular, only limited communication between the workstation and the application is supported. Applications will not be described further in this paper,and are mentioned here only for completeness. See Kelly (1997a) for more information.
Why require an extension to be a separate process? WFO-Advanced designers wanted to support extension of the workstation functionality. At the same time, it is necessary to protect the core workstation code from breakage, performance hits, etc. For this reason a limited set of messages is provided for communication between an extension and an IGC. Thus, it is not necessary to recompile the workstation to build an extension. Also, an extension problem or crash will not affect the core workstation, although it is still possible for the extension to overwhelm the CPU, as there is no protection in the workstation against this.
To illustrate IGC/extension interaction, recall that there are two ways in which a user may interact with an extension: via the graphics and via a GUI.
Each language has its own strengths and weaknesses. C++ is a compiled language, and therefore relatively fast for execution. Python is an interpreted language, thus it is slower in execution than C++; however, development can be faster since changes can be tested immediately without recompilation. Often, developers prototype in an interpreted language like Python, then do final coding in a compiled language for speed. However, interpreted languages can be quite sufficient for handling user interaction as user-generated events are relatively slow.
This new Extension object must contain one or more interactive depictable objects, instantiated from the class InteractiveDepictableExt. This object is the blank canvas on which editable shapes are drawn and displayed. In particular, an extension may use a multiple InteractiveDepictableExt objects to create a sequence of time-stamped displays.
The way AIRMETs are currently defined, a single from line describes a forecast over a 6-hourperiod, a "smearing" of the phenomenon over time. (Text is added to describe the position of the phenomenon more precisely over the forecast period.) Since there is no need to define a from line for more than one time period per issuance, MetGen uses only one InteractiveDepictableExt. If, likeMetGen, an extension does not require a sequence of time-stamped displays and thus uses only one InteractiveDepictableExt, it is called a static extension.
However, if operational requirements were to change, multiple time-stamped from lines could be created to track a single hazard more precisely over the 6-hour time period. In this case MetGen would instantiate multiple InteractiveDepictableExt objects, one for each time period, and become a nonstatic extension. Nonstatic extensions are more complex than static extensions, as the developer must manage the InteractiveDepictableExt sequence when the number of frames in the underlying data display changes (due to user actions or automatic updates).
An InteractiveDepictableExt will contain one or more EditableElements, the editable shapes inan extension: Points, PointSequences, Lines, Polylines, and Polygons (all of which are subclasses of EditableElements). EditableElements are defined in world coordinates, and can be used to represent a variety of data. MetGen uses EditablePolygons to represent from lines and EditablePoints to create the state IDs that are displayed and toggled graphically.
MetGen keeps a list of anchor points and affected states for each from line from which text is generated. Thus, in the class IGC_Interface, MetGen redefines the editedPolygon method and the editedPoint method to track changes to from lines or state labels so that the lists are always current. As an example of MetGen specific behavior, when the IGC_Interface object receives an editedPolygon message from the IGC indicating that the user edited a from line, it massages the respective edited polygon to meet operational requirements as follows. First the anchor points are ordered clockwise. Then, for each anchor point, the nearest VOR is determined, and the point's position in latitude and longitude space is mapped to a distance and bearing relative to that VOR using a 16- point compass. Finally, the point is snapped to the nearest 10-mile increment along that bearing. These tasks are computationally intensive, thus better handled by C++ than by Python. Finally, the adjusted polygon information is sent to the Python side for text generation purposes.
Other supporting classes on the C++ side of MetGen include IGC_FromLine and IGC_FromLineList, both of which help manage from lines.
Python classes defined for MetGen include:
The AGenMgr (for AIRMET generation manager), the first object instantiated, is the top manager in the hierarchy of managers. It instantiates a FromLineMgr, MetMgr, and a FrameMgr. The FromLineMgr instantiates and manages FromLine objects as the user creates them graphically via the IGC. If the user interacts with the GUI, the FrameMgr reports that back to the AGenMgr. As the user requests AIRMETs to be generated, the MetMgr instantiates Met objects. FromLine objects are managed separately from Met objects as a from line may appear in more than one "met."
Once the extension process is invoked, the AGenMgr passes control to the Tkinter event loop. This loop simply waits for the user to interact with the GUI via mouse buttons. Each mouse event is received by the widget invoked by the user. The widget responds and subsequently eports to the FrameMgr,which then sends a message to the AGenMgr where the request is handled appropriately.
The main difficulty in building an extension is attending to all the details so that interaction between the IGC and the extension is successful. Once this is achieved, creating and manipulating shapes and managing time sequences is easy.
Note that the existing software does not support mixing colors in a single extension. Also, users may not create editable shapes by graphically "poking" their initial location. Instead, all initial points for an editable shape must be provided to the IGC at one time, and the shape will appear at that location on the screen. Then one may move the shape or add or delete vertices.
MetGen incorporates two different programming languages. Integrating two languages into a single executable can be tricky, but for MetGen the flexibility is well worth it. However, there are GUI toolkits available written in C, such as Motif, that would obviate the need for any compiler or interpreter other than the C++ compiler.
When an extension creates or modifies an editable shape, the IGC will perform the modification immediately. For large batches of such requests, it can be more efficient and produce a better response time if requests are buffered so that they are all handled at once.
The IGC recognizes a message that will buffer requests - InteractiveDepictExt::refreshIGC(false,igcProcess()).
Buffering can be turned off via a different form of this same message -InteractiveDepictExt::refreshIGC(true, igcProcess()).
Python is recommended as an easy language to learn to read and write. With it, one can practice object-oriented programming skills. It is freely available from http://www.python.org/.
Biere, M., 1998: WFO-Advanced Two-Dimensional Display Software Design. 14th International Conference on Interactive Information and Processing Systems (IIPS) for Meteorology, Oceanography and Hydrology, Phoenix, AZ, Amer. Meteor. Soc., 376 - 379.
Grote, U. H., and 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., 1997a: 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.
Kelly, S., 1997b: An Object-oriented Framework for Local Extension to the WFO-Advanced Forecaster Display Workstation, D2D. 13th International Conference on Interactive Information and Processing Systems (IIPS) for Meteorology, Oceanography and Hydrology, Long Beach, CA, Amer. Meteor. Soc., 324 - 327.
Lutz, M. 1996: Programming Python, O Reilly & Associates, Sebastopol, CA.
Rodgers, D. M., A. Wilson, G. Pratt, and J. Frimel, 1999: An Update on the Development of Forecaster Productivity Tools for the Aviation Weather Center. Eighth Conference on Aviation, Range, and Aerospace Meteorology, Dallas, TX, Amer. Meteor. Soc.