Leveraging Public Data and IMS for Real-Time Statewide Emergency Management and Response

Presented by Andy Sloop

The Oregon Office of Emergency Management (OEM) coordinates statewide disaster planning and response. This presentation will discuss how OEM is leveraging existing statewide GIS framework data and cutting-edge Internet mapping technologies to help establish and communicate a "big picture" view of disaster risks and emergency response efforts at the State level. It will include a demonstration of a customized ArcIMS/ArcSDE application that includes custom tools for county emergency managers to capture, map, and exchange real-time information for specific map locations.


Background

The Oregon Office of Emergency Management (OEM) is responsible for coordinating and facilitating emergency planning, preparedness, response and recovery activities with state and local emergency services agencies. This includes staffing a state Emergency Operations Center (EOC) to coordinate responses to multi-jurisdictional emergencies. In Oregon, such emergencies are usually related to flooding, windstorms, wildfires, and earthquakes. Since 9-11, of course, there is also heightened concern about terrorist attacks.

Monitoring and coordinating multiple multi-jurisdictional response efforts across the state requires access to and rapid assimilation of large amounts of detailed information from many sources into a coherent “big picture” view. The process of assimilating this information can cost precious time in an emergency situation. The ability to quickly generate real-time maps, see patterns, and understand the multi-layered geographic context of emergency situations can improve the effectiveness of response efforts significantly.

In 2000, Obhie Robinson, an emergency management planner at OEM, came up with an idea to address this need: develop a web-based system (HazardMapper) for mapping and sharing real-time information. However, he had very limited resources to do this. In fact, he had no GIS data, minimal knowledge of GIS, and $10,000 of federal grant money that was due to expire within a matter of months.

Robinson sought the assistance of the State’s GIS Coordinator, Cy Smith. Together, they leveraged a variety of resources needed to complete two phases of work on the HazardMapper application. Interestingly, the focus of this initiative changed mid-course as a result of the 9-11 attacks and Robinson’s departure from OEM. Whereas the original focus was on improving the State’s ability to respond to natural disasters, the post-9-11 focus became Homeland Security.

This paper will describe the HazardMapper application, the resources used to develop it and how they were acquired, the technologies used to build it and how they were selected, and the process used to design and develop it. Finally, lessons learned and potential enhancements will be addressed.

The Application

The HazardMapper application was developed in two phases. The initial phase needed to be completed in a matter of weeks for less than $10,000 so it was limited to installing and configuring ArcIMS using the standard HTML Viewer with minimal customization. The goal was simply to complete a prototype that could serve as a basis for subsequent development. Most of the tools in the standard HTML Viewer were enabled in Phase 1, including:

In Phase 2, the focus was on making the interface more intuitive, adding real-time data sharing capabilities, and restricting access to authorized users. The interface design was modeled after the GeoMac wildfire-tracking site. Phase 2 enhancements were as follows: Several buttons that were deemed unessential for this application were stripped out of the toolbar. These included Zoom Last Extent, Back, Query, and Measure Area. The toolbar was moved from the bottom left corner to the top center of the interface to make it more visible and accessible. A combo box was added to zoom directly to specific counties quickly and easily. The legend was displayed in a floating window instead of sharing the same frame with the Layer List. This was done so users could reposition the legend and look at it adjacent to features of interest. The size of the legend fonts was increased to make them easier to read. The ability to toggle layers on/off was replaced with scale-dependent layer display. This was done to eliminate confusion between turning layers on/off versus making them active/inactive. User authentication was added to restrict access to authorized personnel based on Username and Password. Note, though, that the initial security model was very simple. Any user with access had complete access. They could query and view all information in the system, post information to the database, and modify information that others posted to the system. A palette of tools was added to create and manage “Activity Logs”. This is described further below.

Activity Logs

Activity Logs are essentially notes that emergency personnel can enter into the system and associate with a location on the map. This feature enables real-time information sharing about field observations, resource deployment, etc. Logs are represented on the map as points. In an effort to keep the toolbar simple, one button was added to it to invoke the Activity Log toolbar and one was added to toggle Log points on/off. The Activity Log toolbar enables users to create, edit, move, or delete Logs. It was important to enable users to move Logs if necessary because some disasters are mobile (e.g., oil spill in a river, wildfire, etc.). To create a Log, the user clicks the Add Log button then associates the Log with a location by clicking the location on the map. This brings up a simple form to enter the Log. Submitting this form creates a new record in the database. The user enters the Log and a label to display on the map. The application automatically populates the County Name, Author Name, Date, and Time fields. Logs are represented on the map as generic points to minimize cost and complexity at this stage of development. Below is a screen shot of the Phase 2 interface that shows Activity Log Details and the Activity Log Toolbar at the bottom.

Screen Shot of Phase 2 Interface

Data

Since OEM had virtually no GIS data, the HazardMapper application used framework data available from the Oregon Geospatial Data Clearinghouse. The Clearinghouse has or can easily acquire and integrate approximately 70% of the geospatial data pertaining to what the State generally views as “critical infrastructure”. The following critical infrastructure layers are readily available from OGDC:

Other statewide critical infrastructure layers that will take more effort to acquire or develop include:

Technology

The Phase 1 application published shapefile data using ArcIMS deployed on an NT Server. ArcSDE was used in the Phase 2 application instead of shapefiles to support real-time data. The Activity Log entry form was implemented with JSP. The information in the form is written to ArcSDE using Java. AXLDOM is used for manipulating XML to add a point to the ArcIMS map service as an acetate layer. The ArcIMS HTML Viewer was customized using Java Script to enable users to select a county from a combo box and zoom to that county on the map.

There was discussion early on in this project that it might be possible to use the Map Notes and Edit Notes features in the ArcIMS Java Client instead of adding custom Activity Log tools to the HTML Client. GeoNorth investigated this and the Project Team ultimately rejected it because the Java Client would exceed the RAM available on most county emergency managers’ computers.

Design and Development Process

GeoNorth, LLC, an Esri Strategic Alliance Partner specializing in Internet mapping and Enterprise GIS for governments and utilities, was hired to develop the HazardMapper application and assist with design. The design and development process involved iterative prototyping. Initial prototypes were developed with input and feedback from OEM staff and management.

Because of the Phase 1 schedule and budget constraints, OEM staff provided all input regarding user needs and Phase 1 functional requirements. County emergency managers and other potential users were not asked for input.

In Phase 2, GeoNorth met with OEM staff, OEM management, and the OEM Director to obtain input and feedback regarding application prototypes. The Manager of the Oregon Geospatial Data Clearinghouse provided input regarding the availability of pertinent GIS data. The OEM Project Manager and the OEM Director left the agency before OEM was ready to obtain external feedback on the prototype. This arrested the design and development of the HazardMapper application and resources were channeled into developing OGDC infrastructure to host state agency Internet mapping applications such as HazardMapper.

Resources

All data was provided by OGDC. OEM funded Phase 1 with federal grant money. The Oregon State Police hosted the Phase 1 prototype on one of its servers. The Oregon Department of Administrative Services, Information Resources Management Division (IRMD) commissioned GeoNorth.

Successes

Lessons Learned

Potential Enhancements

Query Activity Logs (e.g., by date created, author, county, type, etc.). Associate photos and documents with locations Associate Activity Logs with GIS features Extended authentication permissions, user management, or tracking information. Enhanced graphic selection of Activity Logs (e.g., select by rectangle) Mark-up tools for labeling maps Add real-time data feeds (e.g., road conditions, weather, status of resources) Add real-time database and collaboration capabilities to the parent web site (e.g., resource requests, workflow management, etc.) Integrate this application with other databases (e.g., facilities maintenance management, accounting, etc.)

Acknowledgements


Information About The Author

Andy Sloop
Project Manager
GeoNorth, LLC
921 SW Washington, #777
Portland, OR 97205
Tel. 503-827-0827
Fax 503-827-0735
Email: asloop@geonorth.com