James A. Kuiper, Timothy Allison, Charles M. Cilek, Daniel J. Miller, and Jan E. Stache

Presented at the Twentieth Annual Esri User Conference, San Diego, California, USA
June 26-30, 2000
Sponsored by Environmental Systems Research Institute (Esri)

Argonne National Laboratory, a Department of Energy research facility, has developed an emergency planning GIS to support the U.S. Army Chemical Stockpile Emergency Preparedness Program. This system provides for easy production of maps, reports, and analyses for the development and revision of emergency response plans. To develop the database, facilities and populations of concern in a six-county area around Anniston Chemical Depot, Alabama, were identified and geolocated using geocoded addresses. Geocoding accuracy was enhanced by using local databases to improve TIGER street data. A customized user interface was implemented in ArcView, with most of the database residing in Oracle.

Emergencies happen every day. Many are caused by storms or auto accidents and can be planned for, if not predicted. Emergencies resulting from natural hazards often affect a large number of people, and planning for them can be difficult, since knowledge of the needs of the people involved is generally unavailable. Emergencies resulting from accidents at industrial and military facilities can also be large scale in nature if people must be evacuated or sheltered in place. Federal planning for large scale emergencies is the responsibility of the Federal Emergency Management Agency (FEMA), which provides assistance to various emergency management agencies at the national, state and local level.

One of the challenges presently facing several local emergency management agencies in Alabama is preparing for the possibility of an accidental release of hazardous chemical agents stored at a local military base. The issue is particularly important because in 1986, Congress directed the U.S. Army to destroy its entire stockpile of chemical weapons (Public Law No. 99-145). Although studies show that an accidental release is unlikely and that risks associated with chemical weapons are greater during storage, emergency planners must also anticipate the possibility of an accident occurring in the process of moving, disassembling, and destroying these weapons (U.S. Army, 1988). The United States unitary chemical weapons stockpile is stored at eight installations in the continental United States and includes both nerve agents and blister agents. Nerve agents are the most lethal of the chemical warfare agents with lethal intoxication resulting in the failure of the nervous system to operate properly. Blister agents affect the eyes and lungs and blister the skin and can be lethal if inhaled in large enough doses (Tanzman and Olshansky, 1994).

In August 1988, under the terms of a Memorandum of Understanding (MOU) signed by the Army and FEMA, the Army is responsible for developing on-post preparedness plans, while FEMA is responsible for developing off-post preparedness plans, upgrading off-post response capabilities, and conducting off-post training. These obligations were integrated into a program called the Chemical Stockpile Emergency Preparedness Program (CSEPP) (see FEMA, 2000). Although the CSEP Program presents some unique emergency planning challenges, the lessons that can be learned from this effort can be applied to other hazards as well. This is immediately apparent from the May 27, 2000 derailment in Eunice, Louisiana of 34 train cars loaded with hazardous chemicals to see that many of the problems posed by emergency planning for a chemical weapons agent release are shared by other hazards as well (New York Times on the Web, 2000). The notion that emergency planning shares common functions underlies the decision by the Federal Emergency Management Agency to include the CSEP Program in its "all-hazards" planning approach (CSEPP, 1993). The CSEP Program’s official planning guidance operationalizes this approach by suggesting that state and local CSEP emergency plans "should be appended to the existing all-hazards emergency plan." (CSEPP, 1998).

Argonne National Laboratory (ANL), supported by the State of Alabama Emergency Management Agency (AEMA) under a FEMA grant, is presently developing the Alabama Planning Toolkit (APT). APT is a Geographic Information System (GIS) based planning system designed for one of the CSEPP sites, the Anniston Army Depot in the northeastern part of the state (Figure 1). Some 2,254 tons of chemical weapons agent, including most agent and munitions types, are stored at the Depot. APT is designed to support emergency planners as they address emergency management issues, and includes capabilities that support the collection and importing of data, the review of data in a spatial context, and GIS tools for emergency planning.

Figure 1. Location of Anniston Chemical Depot located within a six-county project area.

The requirements for APT were developed through a series of meetings and workshops at which staff from the AEMA and the Emergency Management Agencies (EMAs) in the six counties surrounding the Depot met with ANL staff and others. The emergency planning effort includes the installation of Tone Alert Radios (TARs), sirens, emergency radio messages, and cable interrupt messages that will be used to alert the proximate population in the event of an incident at the Depot. Because it is highly likely that not all people will be able to comply with government instructions that will follow an alert made using these methods, a public safety survey was included as a part of FEMA’s strategy to identify all such persons subject to an alert at the Depot. The purpose of the survey was to identify individuals with special needs, including the mobility impaired or persons too young to drive. Groups needing special assistance included those at public congregation areas (churches, shopping malls, hotels, etc.), facilities with controlled populations (hospitals, schools, nursing homes, etc.), and places of employment. Some groups, such as hospital patients, require specialized assistance. The sheer size of other groups requires emergency plans, for example, large businesses in the area have as many as 500 employees, high schools often have as many as 800 persons at any given time, and the Talladega Superspeedway can attract nearly 200,000 people during a race.

Two planning zones are used for emergency planning for the Anniston Army Depot (Figure 2). The Immediate Response Zone (IRZ) is an area 8-10 miles from the Depot where the response to an accident would be the most urgent. The Protective Action Zone (PAZ) is an area up to 30 miles from the Depot, beyond the IRZ, that would still be affected by a chemical release at the Depot, but where the response may not require the same level of urgency as would be the case in the IRZ.

Figure 2. CSEPP Emergency management planning zones for the Anniston Army Depot.

Other software designed to support emergency management near CSEPP sites is available. The Emergency Management Information System (EMIS) and the Federal Emergency Management Information System (FEMIS) (Pacific Northwest National Laboratory, 1995) are two of the systems that serve this purpose. APT differs from these systems in that it is not designed for response, only for planning to assist those with special needs, and contains a great deal of data to support planning for the six-county area around the Depot. APT is designed to co-exist with other ArcView-based systems such as FEMIS.

The Alabama Planning Toolkit (APT)

APT is used to create plans for responding to conceivable emergencies. It is designed to simplify preparing and maintaining maps that include selected evacuation routes, selected control points for managing traffic flows, and descriptive text regarding actions to be performed by emergency response personnel. APT presents relevant information to the planner in a graphical interface to reduce the effort needed to prepare plans that include evacuation routes and traffic flow control points. Although APT was explicitly designed for preparing response plans for conceivable events at the Anniston Army Depot, it is a general-purpose tool suitable for planning for other emergency events.

The system has three main components: 1) databases of persons, locations, and facilities needing special emergency planning efforts; 2) map locations of these persons, locations and facilities; and 3) the interface containing the tools that allow planners to integrate these features with existing databases and systems. The general structure of the data tables and the queries they needed to support were determined at a series of workshops undertaken in the spring of 1999.

One of the challenges faced in developing APT was locating persons and facilities based upon the list of addresses developed from public data, the surveys, and other project-specific data collection efforts. The process of locating persons on a map using their address (geocoding) requires an accurate map with accurate addresses. This information is rarely available at the quality this work requires, and so it was necessary to develop a process and tools to support the development of a street layer of sufficient quality.

The customized user interface is designed as a set of ArcView extensions containing the tools needed to support two basic activities. These are 1) updating the data, and 2) using the data to prepare response plans. Maintenance of the data is accomplished by either loading external files or directly editing existing files. The process of preparing and editing plans involves using the tools to present the data in an easily viewed map format, with the routes and control points then selected or drawn in. Text notes for each plan are used to clarify the graphics. Reports generally consist of maps from the main interface or tabular reports drawing from the Oracle database. The tools take advantage of existing Oracle databases installed at each of the six county Emergency Operations Centers (EOCs) and at the State of Alabama EOC. Because existing systems at these locations include Oracle databases running on SUN servers, the clients specified the use of this support structure for the tools.

The users of these tools are often self-supporting when it comes to daily computer operations. Although the State and a few of the county EOCs have dedicated staff expertise in some of the technologies upon which these systems are based, in general, the counties do not have sufficient personnel to dedicate staff to the areas of Oracle administration, SUN Solaris administration, ArcView development, and general desktop computer support. It is expected that staff turnover at these organizations is inevitable and training may need to be done by the existing staff. While some training will be given upon delivery of the system to each county, for these reasons, it was necessary to produce self-sufficient, standalone training, help, and system documentation.

The remainder of this paper is in five sections. The next section describes the capabilities of APT and the user interface, followed by sections covering database development and maintenance, street editing and geocoding, and the electronic help file documentation.

System Components

The APT is designed to make data tables and GIS layers that were compiled and produced for the project more accessible and more useful to planners. The interface has two main components that operate as ArcView extensions. The first is the planning toolkit, which allows the user to query and examine data, create and retrieve emergency response plans, and generate maps and reports. The second is for database maintenance, including tools to edit street addressing, look up supporting information efficiently, and maintain the supporting database tables.

The planning toolkit extension is centered on a set of planning zones that were identified by emergency response agencies for the Anniston Army Depot, and a table of predetermined emergency events that are to be analyzed and planned for. Each emergency event has a unique ID number and identifies the set of planning zones relevant to it. Users can also define their own emergency events, specify the planning zones they cover, and formulate plans for them. When an emergency event is selected for planning, a map of the planning zones and supporting GIS layers associated with the event is generated (Figure 3), and tools to conduct planning are enabled. The planning tools (Figure 4) include customized menus, buttons, tools, and windows, as well as standard ArcView functionality. Database activities essential to planning have been customized and made simple for the user; however, knowledgeable ArcView users still have access to the standard ArcView tools with which they are familiar. The written plan, reports, and maps generated by the system are stored and can be recalled rapidly later. Although it is essential to maintain a hard copy version of the plans, many elements of the electronic plans are dynamic and will reflect changes in the database when they are reopened on the system. Based on this information, users may revise their planning decisions that are stored but not automatically revised.

Figure 3. Example APT planning map view showing a hypothetical event covering 19 planning zones, and showing hypothetical evacuation routes and control points.

Figure 4. Examples of APT customized interface tools for emergency planning.

Tools for database maintenance were designed to support emergency planning for the Anniston Army Depot, yet also generic enough to adapt to a wider range of uses in emergency management such as responding to floods, tornados, etc. The street editing tools mentioned earlier are part of this maintenance extension. A location editor tool manages edits to coordinates in the point data themes. This tool can be used to input or edit locations based on street address, map coordinate, or by clicking within the map view. Similarly, a table editor tool manages edits to many of the supporting data tables. As the database is maintained, changes to the underlying database are available to planners as background data for planning. If changes are significant, it may be important to revisit and revise previously stored plans.

Architecture

The software is written primarily in Avenue, the ArcView scripting language, and is implemented as extensions that run under a standard ArcView 3.1 or 3.2 installation on Windows NT. The ArcView extensions use several other software programs to support file access, database access, report generation, and plan editing. These include Hummingbird NFS Maestro (or Samba) for access to a Unix server, Oracle with an ODBC connection for data storage and retrieval, Seagate Crystal Reports (bundled with ArcView) for report generation, and Microsoft Word for the plan documents (Figure 5). This design follows contractual requirements, but it would take minimal effort to tailor the system to a local file system, different database software, or different word processing software. Several other software packages were used to support system and database development. Table 1 summarizes the software components used for development and on the end user system.

Figure 5. APT system architecture.

Table 1. Software used for development and end use of APT.

Some Programming Issues and Approaches

Development of some of the editing tools for the addressed street layer was one of the significant challenges of the project. Many capabilities not existing in ArcView were added as easy-to-use tools that increase editing productivity and validate addressing input as it is being entered. Figure 6 shows the address editor tool used to revise addressing attributes for an individual street in the GIS layer. Six other tools allow users to add, delete, split, combine, reverse the direction of, and redigitize street lines directly on the map. Many of the tool elements, such as a list of valid street type abbreviations, are loaded from text configuration files that can be easily modified by the end user. During editing activities, the user often needs to consult several sources of data, either in tables or GIS layers. For these functions, the Location Finder and Table Lookup tools were produced (Figure 7).

Figure 6. APT Address Editor Tool.

Figure 7. Example windows from the Location Finder and Table Lookup tools.

Another challenge was allowing both coordinates and attributes of point layers to be stored in the database, while giving the user access to ArcView geocoding tools. ArcView event themes were used as the means of converting a table with coordinates to a map layer; however, the geocoding tools provided with ArcView do their work with Shapefiles on disk. The system also provides alternate methods of locating points (by coordinate or by mouse click) for cases when geocoding fails or the user wants to improve the accuracy of the location. APT takes advantage of standard ArcView geocoding functionality and augments it with a procedure to store the results in Oracle and display the locations as an ArcView event theme.

Crystal Reports, which is bundled with ArcView, was used for report generation in the system. This software allows attractive report templates to be designed and populated with specific results generated by the system. Reports corresponding to planning events were designed for the system, along with the interface to produce a specific report and store it for future access. The generated reports can also be reviewed outside APT, and contents can be updated against the database when the report is opened at a later time. This approach was not without difficulties, however, as it is very time-consuming to design reports, and they can be very sensitive to changes in the database or configuration of the database connection. Many files are necessary to create a report, and these must be present for the reports to be properly generated.

Many resources were used to make programming of the system interface more productive. These are summarized in a section at the end of this paper. Unfortunately, the Avenue programming resources may be of limited value to others for future projects because of the changing architecture of Esri software products and the lack of support of Avenue in future releases.

Designing and Compiling the Database

Emergency planning database information was organized into three categories and stored as a series of database tables (Table 2). The first database category pertains to persons who may need assistance in the event of an accident. This table was populated using six complementary data-gathering methods. An explanation of the survey goals, data collected, and methods used was provided to participants in the survey (Argonne National Laboratory, 1999c). The second database category contains two data sets: places of employment and special facilities. Noise was an important factor for places of employment because of the audible alarm systems being used. The third category contains data on emergency events and control points used by emergency response personnel during activities. The confidentiality of this data is being protected in accordance with Alabama law.

The primary source of data in the Event table and Control Point table is FEMIS, which contains models and data related to Anniston Chemical Activity. Tools in APT allow emergency planners to define and add their own event descriptions to the data in FEMIS according to their needs. These user-defined events might include man-made events or natural events such as tornadoes, floods, and fires. The Control Point data is important for planning evacuations and other protective actions. Traffic control points, for example, are road intersections on an evacuation route where a police officer or other official controls the direction of traffic. The information associated with these points includes the maximum traffic throughput and the estimated time for a responder to reach the point. While event and control point tables were compiled from existing FEMIS tables, they will be augmented and revised by EMA personnel who use the system.

Table 2. Main APT database tables with functional descriptions and data sources.

The data tables are designed to be as self-explanatory as possible by using descriptive field names and descriptive data in fields rather than codes found in many of the source databases. For example, instead of using a FIPS field containing "121" corresponding to Talladega County, a CountyName field was populated with "Talladega." Also, there were numerous ways of coding employment information in the various data sources. Some facilities included a letter code for the number of employees (e.g., B = 5-9) and also a reported number (e.g., 7). As this code would be cryptic to a user and difficult to use in a query, this information was converted to fields containing the minimum and maximum number of employees. If an exact number was specified, it would be used for both the minimum and maximum. If only a range code such as "B" was provided, it was also converted to a minimum and maximum value. A relational design with lookup tables for codes was considered, but the added complexity was not practical for use with Crystal Reports or with the interface tools to edit the data.

Oracle was chosen as the database backend, both because of its capabilities and its compatibility with FEMIS used at the EMAs. The Oracle database for APT will run as a separate Oracle instance. Client Windows NT systems running ArcView require an Oracle driver and an ODBC connection to access the Oracle database, which is on a Unix server.

Maintaining the Database

Database maintenance is essential to keep the database viable for future planning activities. Maintenance involves many levels of the system, such as updating the addressed street layer used for geocoding, adding or deleting geolocated points in one of the planning data layers, revising tabular information such as a contact name, and updating emergency plans that are dependent on the underlying data.

Maintenance of the Facilities table will involve comparing existing data with yearly updates from commercial and state agency databases (R. L. Polk, Dunn and Bradstreet, Alabama Department of Education). Mismatches will be flagged for manual checking, rather than using an automated update, so that corrections made previously by Argonne and CSEPP planners will be preserved. For the Persons table, the procedure will use a Microsoft Access database with forms to standardize data from various sources, which include license plate data, surveys, and local knowledge. The data will then be exported into Oracle and checked against existing APT tables for duplicates.

Street Layer Sources and their Limitations

In order to make collected databases more useful for emergency planning in a GIS context, the mailing addresses in the tables were geocoded against a GIS street layer with addressing ranges defined. TIGER/Line DATA files (Topologically Integrated Geographic Encoding and Referencing), produced by the U.S. Census Bureau, were obtained in ArcView Shapefile format from Cross Streets, Inc. (www.cstreets.com). These files were used to develop the initial base layer of streets with address ranges for all six counties. Later in the project, two of the counties provided street layers for their areas with addressing attributes superior to the publicly available TIGER data. Other commercial sources of addressed street layers were considered but were prohibitively expensive for delivery of the system to the seven final installation sites.

TIGER/Line DATA files form the base map for the collection, organization, and reporting of census data by the U.S. Census Bureau. The files were developed for the 1990 decennial census and were created by using a compilation of data sources. Ninety-eight percent of the territory covered by TIGER was created by digitizing USGS 1:100,000 scale maps. Features for the urbanized portions of Metropolitan Areas was obtained from the Bureau’s GBF/DIME files, and remaining information was acquired from various other map sheets (U.S. Census Bureau, 1996). Additional information regarding TIGER files can be found on the Internet at http://www.census.gov/geo/www/tiger/overview.html.

Although TIGER street layers are frequently used for geocoding addresses, there are many problems inherent with the data files. Many street segments do not have names or address ranges, have incorrect names or address ranges, have inconsistent names for the same street, use alias names that are not mail-deliverable street names, are not spatially accurate or even representative of the actual street, and have incorrect or missing zip codes.

For the six-county area covered by the project, the TIGER data were categorized by addressing status to better understand the capability of the layer to support geocoding. Figure 8 shows a map of the initial six-county street layer with the streets categorized by street addressing status. In this initial layer, only 27% of the streets had both name and address attributes. As indicated in Table 3, there was quite a variation between counties with regard to the completeness of the TIGER files with a high of 58% and a low of 0.26%. Figure 9 shows the percentage of miles of fully addressed streets in the six-county area by county, after replacing TIGER data for Cleburne and Etowah counties with the layers they provided. This was essentially the best available street data for this region, and the starting point for extensive editing of these data. Not depicted in these figures and tables are many inaccuracies beyond the simple presence or absence of street attributes that required extensive editing and updating.

Figure 8. Map of the initial six-county street layer with the streets categorized by street addressing status.

Table 3. Mileage of streets in publicly available TIGER files for the six-county area, listed by addressing attribute status and county.

Figure 9. Percentage of miles of fully addressed streets in the six-county area by county, including data sets provided by Cleburne and Etowah counties.

Filling the Street Layer Data Gaps

Street name, address range, and zip code editing and updating was required to obtain an improved street data layer on which to geocode the survey responses for emergency planning. Obtaining local knowledge of the addressing in a county in the form of contacts, editing assistance, data, and maps was essential to making meaningful edits to the street layer. Confidentiality procedures stipulated in the contract were an important factor in this process. Materials varied significantly between the counties, from CAD files, to E911 map books and data, to standard road maps. After a workshop attended by county personnel demonstrating the issues and editing tools, two of the counties provided editing assistance with their own local staff. The remaining four counties each provided assistance in the form of data and materials; however, it was a significant project in itself to locate and obtain this information.

ArcView provides a variety of methods for geocoding. For this project, the "US Single House with Zone Address Style" method was chosen because it takes advantage of the most detailed information in the TIGER data. The method uses both the street address and the zone (zip code) to locate an address. Using the zip code was essential to be able to distinguish addresses for street names duplicated in different parts of the project area. For example, many towns have a "Main Street" and the zip code can be used to distinguish between them. Identifying accurate zip codes for streets was a challenge as there was not a reliable source of zip code boundaries available. Zip code boundary layers provided with ArcView 3.1 and 3.2 were compared. Individual zip code boundaries were considerably different, and at least one known applicable zip code had been deleted from the ArcView 3.2 update. The U.S. Postal Service ZIP+4 Code State Directory (U.S. Post Office, 2000) was the most reliable source to consult on these issues. For each zip code, it lists all of the streets with their associated address ranges divided by block.

CAD files and E911 map books provided by several counties were very beneficial for updating street names and address ranges, but these did not contain zip codes. When adequate maps or CAD files were provided, they were used to validate the information in TIGER. Where these materials were not provided or were not available, commercial maps, road databases, and web-based mapping programs were used to help identify street names and address ranges.

Improving Geocoding Accuracy

ArcView can geocode a certain percentage of addresses with default settings and raw TIGER data. This match percentage can be raised or lowered by adjusting settings for minimum match scores and spelling variation. With lower settings, more addresses can be matched, but some can be given incorrect locations. With higher settings, locations can be more accurate, but the match percentages can be very disappointing. This project required a high degree of accuracy in matching addresses, so it was necessary to better understand the ArcView geocoding algorithm and edit the data accordingly.

ArcView geocoding requires that a street layer have fields broken up into address components (Table 4) and that the components be placed in the correct fields for good geocoding results (Table 5). Given an address to be matched, ArcView first standardizes it and breaks it into parts that coincide with the address components in the street layer. Then a scoring method is used to find the street that fits the address most closely. If the address components in the street layer are out of position, then a lower score will result even if the address and street attributes appear to match. For example, ArcView standardizes "101 West Point Dr" to "101 | W | Point | Dr" even though "West" may be considered part of the street name.

Table 4. Field names, definitions, and descriptions for the GIS street layer used in APT for geocoding using the ArcView "US Single House with Zone" method.

Table 5. Examples of GIS street layer addressing fields with comments on data arrangement to match ArcView address standardization.

Fedirp	Pre_type	Fename	Fetype	Fedirs	Fraddl	Toaddl	Fraddr	Toaddr	Zipl	Zipr
N		Main	St		100	198	101	199	36279	36279
This example is typical. Note that the left side addresses are even and the right side are odd. The direction the numbers ascend should appropriately match the direction in which the line coordinates are stored.
		County Line	Rd		1170	1388			36203
This street is only addressed on one side, including the zip code.
	USHY	431			14978	14614	14977	14613	36279	36279
Prefix types are used for numbered routes. The route number appears in the name field. Frequently used abbreviations with their meanings include: I, Interstate; USHY, US Highway; STHY. State Highway; CORD, County Highway or County Road; TWHY, Township Highway or Township Road.
	Ave	A			1191	1261	1192	1260	35160	35160
ArcView also includes Ave and Rd as prefix types.
		Prairie Creek			300	398	301	399	36279	36279
ArcView geocoding configuration files include 62 street types. "Creek" is not one of these recognized street types, so it is kept as part of the name and not abbreviated.
		Malone Point	Ln		1	179	2	180	35096	35096
"Pt" is a standard street type for Point, but since there is already a street type, Point remains part of the name.
W		Point			100	198	101	199	36279	36279
"Pt" is a standard street type for Point, but since there is already a street type, Point remains part of the name. Although "West Point" may be considered the name of a street, ArcView will look for the direction in the prefix type field. Point is not moved to street type because there should always be an entry in the name field.

There are two approaches to fixing this problem. The files that control address standardization in ArcView can be edited (Esri Technical Note, 1999), or the street data can be organized to fit the default standardization files provided with ArcView. The former approach would have been problematic for the example given, because it would affect the way other addresses like "101 W Main St" would be standardized and cause more problems than it would solve. The latter approach was used for this project, and included extensive edits to the TIGER data and designing the address editing tool to enforce ArcView standardization patterns. Following this approach, the example street would be coded with a prefix direction of "W" and a name of "Point" to accommodate the geocoding algorithm. One of the key editing changes was to add a "Pre_type" field to the street layer and convert all numbered routes such as state highways to use this field. For example, "105 State Highway 15" would have a pre-type of "STHY" and a name of "15."

Another aspect to improving geocoding accuracy is using high quality addresses for matching, which was also a challenge for many of the data tables compiled for the project. The source materials contained many incomplete addresses and misspelled street names. To assist in detecting errors and standardizing these addresses, ZP4 software (Semaphore Corporation) was obtained and used. The ZP4 program contains a national database of U.S. addresses, mail carrier route numbers, and Zip+4 codes that are updated for subscribers quarterly. This approach of using ZP4 or similar software to improve or prepare addresses for geocoding has also been used for other projects (Mills, 1999, Hodge, 1999).

Lessons Learned

A large amount of updating and editing of the street data layer was required for this project to provide accurate geocoding of the survey response data. Cooperation of local emergency organizations was a key to being able to fill data gaps and update the TIGER data accurately. An accurate zip code boundary source and a more complete and accurate TIGER street layer would have been extremely helpful in this project. However, as the result of the efforts to establish an accurate street base map, the six counties will be able to utilize an accurate street data file for a wide range of county activities beyond the initial scope of this emergency planning program.

The documentation of the APT system was designed to satisfy two broad objectives: first, to provide relevant and easily accessible information in a sufficiently concise format to enable users to quickly familiarize themselves with each aspect of the system, and second, to provide enough information to be used for training purposes once the system had been fully developed and installed on client systems. To serve both objectives, it was decided to produce the documentation both in the form of an electronic help file and in hard copy format. The RoboHELP system produced by BlueSky Software, which produces Windows-style help files with a range of printing options, was used to document the GIS planning tool.

Features of the RoboHELP Help Authoring Tool

RoboHELP is an authoring package specifically designed for producing Microsoft WinHelp help systems for Windows 3.x, 95, 98, and NT. The help file can be designed, authored, distributed, and printed as a standalone document using this software. The software uses Microsoft Word as the host text editor and includes all the functionality contained in this word processor. Word is used to develop topics, hotspot links, and buttons in Word text. Full-text searches of related topics are possible, together with browse sequences for particular topics, window designs that can be customized, and topic links that can be visually represented.

A major advantage of the software is that a table of contents is created automatically as the help file is developed. Multilevel indexes can also be developed and keywords added as the help file is developed. Both the table of contents and the index can be routinely accessed by the user to aid in understanding the APT system.

Images can be directly imported into RoboHELP, edited, and used to create hotspot (SHED) images. Screen-captured images can also be imported directly into the Word files created in RoboHELP, either in BMP form or as JPEG files that are then converted to BMP format.

Components of the Help File

The APT help file, which is under development, contains a variety of information to enable the user to quickly understand the system as well as to place the tool in the context in which it was developed. General aspects of the CSEP program are described, together with the role of FEMA in local CSEPP planning. Information is also provided on the surveys that were used to collect data on individuals with disabilities, including examples of the survey instruments, descriptions of sampling methodologies, and general survey features, such as response rates.

The help file contains an overview of the development of the interface, together with a description of the objectives of the software, its relevance to issues faced by CSEPP emergency planners, and the adaptability to other areas of emergency planning, including tornadoes, hurricanes, and floods.

Hardware and software requirements for successful installation and operation of the software are fully described in the help file, together with software installation procedures, including a "getting started" section and a section on connecting to ORACLE, the database host software. A system administration section is included, outlining procedures for maintaining SUN, UNIX, and APT accounts, together with administrative procedures for backing up ORACLE databases.

A key section of the help file describes tools and procedures for updating the various GIS layers as new information becomes available on the spatial configuration of streets. Precisely how users should geocode, edit, and display this information in ArcView is described. While the APT tool already includes a large amount of current information in the ArcView street layer, these data maintenance procedures will allow additional data collected in subsequent years to be added to the database.

A second key section describes the reports generated by ArcView containing emergency event-specific planning data and maps. These reports include data on each of the data tables indicated in Table 2.

An overview of the Census TIGER files is also included, together with descriptions of each of the ORACLE data tables, including field names, descriptions, and field lengths.

Training

At the conclusion of the system development, each of the seven EMAs (state and county) will receive training in the use, data maintenance, and system administration of the system. Training for users of the APT will be provided to the EMAs only upon delivery of the system, making it important that the tool be accompanied with a highly usable help system that would allow future users to be able train themselves. An important objective of the documentation for the GIS tool was to allow enough flexibility in the help system to provide on-line help for trained users, sufficient information for printed documentation, and a usable tool for training new users. Emergency planners in rural counties often have very limited resources available to them and also experience relatively high staff turnover rates, meaning that all the advantages of the system would not be fully realized unless the help system is usable, relevant and sufficiently informative.

Although the Alabama Planning Toolkit is designed for CSEPP planning, the more generic approach used in database and interface design will allow it to be useful for other planning activities in the organizations receiving it. Some elements of the system do not contain sensitive information and have the potential to serve other purposes within these organizations. For example, the addressed street layer could support a wide variety of address geocoding applications.

The need for a county-level emergency planning system with detailed, geographically-referenced information about populations, facilities, potential events, resources, and control points is not specific to this hazard, or this location. The data collection methods, database content and design, geocoding methods and improvements, interface design, and the approaches to documentation and training are all broadly applicable.

The use of GIS to support emergency management, both in response activities and planning, is increasing. As this project demonstrates, developing such a system for a localized area is both uniquely valuable and uniquely challenging.

We would like to thank Edward Tanzman and William Metz for their efforts in managing the project and supporting parts of the technical work undertaken. Thanks also to the many others at Argonne National Laboratory contributing to the project, including staff members Leslie Nieves, Kurt Roloff, George Vukovich, and Dee Wernette; and students Ron Colnar, Matt Froelich, Christopher Metz, and Daniel Redican. Thanks also to state and county EMA staff who actively participated in the preliminary design and contract requirements meetings in 1998, and to the Spring 1999 workshop participants for their contributions to the design and requirements analysis. Thanks also to the FEMA officials who participated in the preliminary design and contract requirements meetings in 1998.

Citations

Argonne National Laboratory, 1999a. Unpublished information.

Argonne National Laboratory, 1999b. Unpublished information.

Argonne National Laboratory, 1999c. Unpublished information.

CSEPP, 1998. Emergency Response Concept Plan for the Chemical Stockpile Emergency Preparedness Program, Rev. 1, Vol 1: Emergency Planning Guide for the Anniston Chemical Activity CSEPP Site, ANL/DIS/TM-48 (May 1998), at Table 5.0.1.

Department of Defense’s Chemical Stockpile Emergency Preparedness Program (CSEPP), Hearing before the Environment, Energy, and Natural Resources Subcommittee of the Committee on Government Operations of the House of Representatives, 103rd Cong., 1st Sess., at 117 (testimony of Craig S. Wingo, Assistant Associate Director of the Federal Emergency Management Agency) (July 16, 1993).

Esri Technical Note, 1999. Editing the Geocoding Standard Abbreviations for Street Types, ArcView GIS Technical Note No: 1409, http://www.Esri.com/usersupport/support/faq/arcview/04geocode/67_2796.html, September.

Federal Emergency Management Agency (FEMA), 2000. Chemical Stockpile Emergency Preparedness Program Branch Web Pages, http://www.fema.gov/pte/csepp1.htm.

Federal Emergency Management Agency and U.S. Department of the Army, 1996. Planning Guidance for the Chemical Stockpile Emergency Preparedness Program, at p. 8-3, May 17.

Hodge, M., 1999. Data Cleaning for Geocoding, ArcView-L Summary message archived at http://www.gfi-gis.com/en/services/avkb/avkb.htm (search for "semaphore"), April.

Mills, J., 1999. Tain't Necessarily So: Address Geocoding in the Real World, Proceedings of the Nineteenth Annual Esri User Conference, Palm Springs, CA, http://www.Esri.com/library/userconf/proc99/proceed/papers/pap623/p623.htm.

See, for example, "Train Evacuees Anxious To Go Home," New York Times on the Web, http://www.nytimes.com/aponline/a/AP-Train-Derails.html (June 1, 2000).

Pacific Northwest National Laboratory, 1995. Federal Emergency Management Information System (FEMIS). Prepared for CSEPP, U.S. Army Chemical and Biological Defense Command. http://www.pnl.gov/femis/.

Public Law No. 99-145. Department of Defense Authorization Act of 1985.

Tanzman, E. and S.J. Olshansky, 1994. Environmental Impact Review of the Chemical Weapons Convention. (authorship unacknowledged; document was submitted to the U.S. Senate as Presidential Message No. 90 by the President of the United States), at pp. 3-4. February.

U.S. Army, 1988. Chemical Stockpile Disposal Program Final Programmatic Environmental Impact Statement, Vols. 1 - 3, Program Executive Officer - Program Manager for Chemical Demilitarization, Aberdeen Proving Ground, MD, January.

U.S. Census Bureau, 1996. Understanding the Census, p. 187, Epoch Books, New York, NY.

U.S. Post Office, 2000. Alabama ZIP+4 Code State Directory, 1734 pp., Address Management, National Customer Support Center, U.S. Postal Service, Memphis, TN.

System Development Resources

Esri, Inc., ArcScripts: Useful Tools from GIS Users and Esri, http://gis.Esri.com/arcscripts/scripts.cfm.

Esri, Inc., ArcView-L Moderated E-mail Listserver, arcview-l@Esri.com.

GFI, Inc., ArcView Knowledge Base, http://www.gfi-gis.com/en/services/avkb/avkb.htm.

Greenberg, G., Avenue Programmers Reference: Avenue Classes, Requests, and Sample Scripts, http://www.gator.net/~garyg/aveclass.htm.

Greenberg, G., Avenue Script Editing (SEd) Tools Extension, http://www.gator.net/~garyg/archives/sedtools.zip, October, 1999.

Huber, B., ArcView Unmoderated E-Mail Listserver, arcview@listbot.com.

Hutchinson, S., and L. Daniel, Inside ArcView GIS, 3rd Edition, OnWord Press, Albany, NY, 488 pp., 2000

Koch, G., and Loney, K., Oracle 8, The Complete Reference, Osborne McGraw-Hill, Berkeley, CA, 1300 pp., 1997.

Ladanyi, H., SQL Unleashed, First Edition, Sams Publishing, Indianapolis, IL, 896 pp., 1997.

Osborne, S., and Esri Inc., Using Crystal Reports with ArcView GIS, in Arc User, p. 34-37 and http://www.Esri.com/news/arcuser/0199/crystal.html, January, 1999.

Razavi, A., ArcView GIS / Avenue Developers Guide, 3rd Edition updated to 3.1, OnWord Press, Albany, NY, 379 pp., 1999.

Razavi, A., and V. Warwick, ArcView GIS / Avenue Programmer's Reference, 3rd Edition updated to 3.1, OnWord Press, Albany, NY, 545 pp., 2000.

James A. Kuiper: Biogeographer / GIS Analyst
Environmental Assessment Division - 900/H03
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439-4832
Office: (630) 252-6206
FAX: (630) 252-6090
Internet: jkuiper@anl.gov

Timothy Allison: Economic Geographer
Decision Information Sciences Division - 900/I31
Argonne National Laboratory
Office: (630) 252-3209
FAX: (630) 252-5327
Internet: tallison@anl.gov

Charles M. Cilek: Computer Programmer / Database Administrator
Decision Information Sciences Division - 900/I05
Argonne National Laboratory
Office: (630) 252-4237
FAX: (630) 252-4498
Internet: ccilek@anl.gov

Daniel J. Miller: System Architect
Decision Information Sciences Division - 900/I33
Argonne National Laboratory
Office: (630) 252-5775
FAX: (630) 252-4546
Internet: djmiller@anl.gov

Jan E. Stache: GIS Analyst
Environmental Assessment Division - 900/H05
Argonne National Laboratory
Office: (630) 252-3145
FAX: (630) 252-3611
Internet: jstache@anl.gov