Effective integration of a stand-alone GIS (e.g., ArcView 3.x) into a complex distributed software application requires an efficient, reliable mechanism for passing data and function requests to and from the GIS component. This paper describes the use of dynamic data-sharing and inter-process communication mechanisms to integrate GIS capability into a multi-jurisdictional distributed emergency management information system. These mechanisms include dynamic map layer updates from spatial and attribute information shared via a distributed relational database across multiple sites; storage of private and shared spatial viewmarks to facilitate consistent GIS views; and both synchronous and asynchronous inter-process communication using function queuing and a data sharing library.
During the initial software development and subsequent evolution of a distributed emergency management information system for the U.S. Army's Chemical Stockpile Emergency Preparedness Program (CSEPP), it became quickly apparent that one of the keys to the success of the system was effective communication of data and function requests between the emergency management application (written in Visual Basic for execution on a Windows-based PC) and the customized stand-alone GIS component (initially ArcView 2.0; currently ArcView 3.x). This paper describes the data sharing and inter-process communication mechanisms that were developed to more cohesively and reliably integrate the GIS component into the emergency management system. The paper also briefly addresses the interrelationships among the GIS, the distributed relational database, and the automated notification system that informs users at multiple jurisdictions of changes in data items.
Software development for the initial version of the Federal Emergency Management Information System (FEMIS) began at the Pacific Northwest National Laboratory (PNNL) in 1993 under a contract from the United States Army to provide CSEPP automation support at the eight chemical weapons storage sites within the continental United States. As these sites began preparing for the dismantling and destruction of the stockpiled chemical weapons, a computer-based information and communication system was envisioned to facilitate the development and implementation of emergency preparedness plans by each CSEPP site's Emergency Operations Center (EOC) and the affected civilian jurisdictions (municipal, county, and state EOCs).
The FEMIS development team designed and implemented a client-server architecture to provide access to site operational and planning information stored in a distributed Oracle relational database. Each EOC maintains its own database on a UNIX server, which is accessed by multiple PCs running the FEMIS client software. At each CSEPP site, data sharing is accomplished by data replication transmissions between database servers over a high-speed network, thus allowing each jurisdiction to share relevant data with the other EOCs on the network. Data-driven notification software is used to pass messages between servers and from the servers to the client PCs to notify users whenever changes occur to key items in the database. Event notification allows users at all jurisdictions to be notified of the occurrence of a real or simulated "event" involving the possible accidental release of chemical agents to the environment.
The FEMIS software has evolved and improved through a series of version upgrades over the past eight years. The most recent version of FEMIS was released in April 2002.
This section briefly describes the major requirements for Geographic Information System (GIS) capabilities within FEMIS in support of CSEPP objectives. Some of the GIS requirements have remained virtually unchanged since their initial formulation, while others have evolved through time. As these requirements have been addressed by the FEMIS software implementation, this section also describes major elements of the currently implemented GIS functionality.
Among the most crucial GIS requirements are those that address the ability to display, on a background map of the area surrounding each CSEPP site, the predicted spatial distribution of the effects of an accidental chemical release. A key component of the hazard analysis capabilities of FEMIS is an atmospheric dispersion model that predicts the concentration and spatial distribution of a chemical plume released to the atmosphere as a consequence of a real or hypothetical accident at or near a chemical storage facility. The GIS must depict this plume in the form of multiple contours representing designated threshold levels of chemical concentrations and the resulting dosage or health effects to the population (e.g., no effects, no deaths, one percent lethality).
The GIS must also be able to display a map representation of other components of the hazard analysis. One of these components is the Threat Area polygon that typically extends the model-predicted plume to include a larger area that may be threatened by the hazardous chemical release. The Threat Area allows for uncertainties in the model output due to factors such as variations in wind speed and direction over space and time. Figure 1 shows a model-predicted plume with three dosage levels and an associated Threat Area polygon.
Model-based hazard analysis may also include the identification of the Emergency Planning Zones that are affected by the hazard. Emergency Planning Zones are administrative areas defined for the purpose of planning and carrying out protective actions (e.g., sheltering or evacuation) and other immediate response measures in the event of an accidental release. Figure 2 shows a map representation of the set of zones at risk (outlined in red) and the proposed protective actions for each zone as indicated by the colors shown in the theme legend.
Some additional key FEMIS GIS requirements and functionality are listed below:
Underlying all of these requirements is the need to effectively communicate data and status changes between the GIS and multiple FEMIS run-time processes, and to allow the FEMIS application processes and the GIS to request services of each other in a reliable and seamless manner. The following paragraphs address the methods and mechanisms that were implemented to achieve this goal.
Early versions of FEMIS relied solely on the Dynamic Data Exchange (DDE) inter-process communication method for sending data and function requests from the Visual Basic application to ArcView and for returning information from the GIS to the FEMIS application. However, as FEMIS evolved and new functionality was added, the volume and complexity of communication traffic between the FEMIS application and the GIS in a typical user session began to increase, and the limitations and restrictions associated with the use of the DDE method began to affect performance and reliability. These limitations included a small (256-byte) upper limit on the length of character strings passed between processes; transaction timeouts on lengthy communication processes; susceptibility to conflicts among overlapping GIS requests from multiple FEMIS executables; and an inability to effectively coordinate multiple related GIS requests that need to be processed as a unit.
To overcome these restrictions, we developed a set of new inter-process communication tools and applied these tools to the interactions between FEMIS and the GIS. The key component is a software toolkit called AppLync. AppLync provides a set of tools for sharing data and functionality among independent software processes at run time. The AppLync tools enable multiple executables to appear to function as a single integrated application. In addition to the sharing of data and status information, AppLync provides callable routines to allow a process to request actions or services from another process and receive the results of the requested action or service. AppLync's implementation overcomes many of the limitations and disadvantages of other commonly used inter-process communication mechanisms.
The AppLync toolkit was used in the following ways to facilitate communication and data sharing between the GIS and the FEMIS application:
Figure 3 illustrates the steps that occur when the FEMIS application requests a Type 2 or Type 3 service from the GIS and information is subsequently returned from the GIS to the FEMIS application.
In Step 1 (red circle "1" on the diagram), prior to initiating the call to the target Avenue script that will perform the required GIS function, a unique identifier for the function request is generated, and that identifier along with a delimited parameter string containing the arguments for the target script are posted to an AppLync variable having a unique key (name).
In Step 2, the name of the target Avenue script and the name of the AppLync key containing the parameter string is passed to a Single Point-of-Contact (SPOC) script within ArcView GIS via a DDE LinkRequest. The use of DDE or some other communication mechanism is necessary here because ArcView 3.x is not COM-aware, which is a requirement for applications to receive and process an AppLync service request. (COM is Microsoft's Component Object Model interface standard.) The SPOC script then places the target script name and AppLync key into a first-in-first-out run queue. As the queue manager receives the next script to be run, it retrieves the target script's parameter information from the designated AppLync key (variable) and runs the script. Note that multiple script name / AppLync key pairs can be passed in a single "batch" request to the GIS, and these scripts are then placed sequentially into the run queue and are thus guaranteed to run sequentially without interruption by a function request from a different executable application. This is important for some FEMIS functions such as plume animation that need to have multiple GIS functions executed in strict sequence.
In Step 3 on the diagram, the target script runs and produces some result that is then returned to the FEMIS application via an AppLync service request. The named service request handler in the FEMIS application, to which the service request was directed, then processes the information returned from the GIS.
The overall effect of this process is that the GIS becomes a virtual extension of the FEMIS application, in which the requested function is performed by the GIS as if the function had been called locally within the FEMIS application itself. The improved inter-process communication mechanisms built around AppLync have allowed us to overcome the restrictions previously imposed by sole reliance on the DDE method. The following benefits have been found to be of particular value: (1) Very long parameter strings can be passed to the GIS via the AppLync keys, and (2) the use of the GIS run queue for processing the scripts in a set order, combined with the return of the script's results via a directed AppLync service request, minimizes the probability of collisions or other conflicts between multiple communication processes, which is especially important during time-sensitive operations such as hazard plume animation.
The FEMIS distributed database includes tables to store location and attribute information for several classes of pre-defined geographic point features, including facilities, traffic control points, warning sirens, meteorological towers, and chemical storage bunkers (igloos). Authorized users at each EOC can use an interface provided in the FEMIS application to add new features to each feature class and store the information in their EOC's local database, and they can also modify the location and attributes of existing point features or delete existing features. In addition, users can define new point feature classes and add, modify, or delete features belonging to those classes. Similar capabilities exist for polygonal classes and features. When adding a new polygonal feature, users are provided with access to the graphical drawing tools in ArcView to assist in the creation of the new polygon shape, or they may copy a polygonal feature from another theme in the GIS.
While point features need only to have their longitude and latitude coordinates stored in the database, polygonal features require storage of the two-dimensional shape of the polygon in a form or representation that is recognized by the GIS and can be converted and stored as part of the ArcView shape file for the theme. When the user defines a new polygonal feature to add to the current user-defined feature class or to replace an existing polygonal feature, an ArcView script generates the shape information for the new polygon in the form of a text string, the shape data is passed to the FEMIS application via AppLync, and the shape information for the polygon is stored in a Large Object (LOB) field in the Oracle database. This method provides the basic required spatial storage functionality without incurring the expense and overhead of commercial spatial database extension tools such as Esri's SDE or Oracle Spatial.
When the GIS is started from the FEMIS application, the static map themes are already preloaded. The dynamic point and polygon themes (shape files) corresponding to the classes of point and polygon features stored in the relational database are then automatically regenerated from information retrieved from the database by the FEMIS application and passed to the GIS via AppLync. When the current user adds, deletes, or modifies a spatial feature in the database, or when another user makes such a change and the current user is notified of the change via the data replication and data-driven notification functions, the corresponding theme in the GIS is updated to reflect the changes.
The concept of spatial viewmarks was conceived and implemented within the FEMIS GIS as a way of allowing users to name, save, and restore specific view contexts that they use frequently. This functionality is analogous to the ability provided by web browsers to save and apply favorite URL addresses. Spatial viewmarks allow the saving of view extents, visibility and activation status of themes, current legend type (simple or classified) for each vector theme, labels and other visible graphics, and other view and theme properties.
Because a named viewmark can be designated to be either private (accessible only by the current user) or shared (stored in the database and accessible by other users), viewmarks can facilitate consistent views so that multiple users can be "on the same page" in the GIS when working together on a task. As with polygon shapes, viewmarks are created in the GIS and stored in the database in an Oracle LOB field.
The integration of a customized stand-alone GIS (ArcView 3.x) into a multi-jurisdictional distributed emergency management information system has benefited from the use of a process integration toolkit and library that facilitates the sharing of data and functionality across multiple executable processes. Some of the benefits that have been realized from using this toolkit are:
Additional data sharing mechanisms, including dynamic map layer updates and shared spatial viewmarks, have also contributed to the smooth flow of data and functionality across a complex distributed client-server application.
Many of the underlying software tools and methods described in this paper are reusable, or can easily be made so, and can be applied to the design and development of other software systems involving the integration of multiple independent software components.
The authors wish to acknowledge the contributions made by past and present members of the FEMIS Project Team at PNNL to the work described in this paper. The following individuals merit special recognition:
Tzemos, Spyridon and Robert A. Burnett, Use of GIS in the Federal Emergency Management Information System (FEMIS), Proceedings of the Fifteenth Esri User Conference, Esri, Redlands CA, 1995.
Millard, W. David and Richard J. Carter, Information Sharing Challenges for Large Multi-Jurisdiction Issues, to be presented at the Sixth World Multi-Conference on Systemics, Cybernetics, and Informatics (SCI 2002), Orlando FL, 2002.