Preparation & Response

Commercial geospatial and location-based services — such as address lookups or routing that takes into account road conditions and traffic patterns — are becoming more popular and can also provide useful data during an incident.

By supporting several different sources for such services, you can build in redundancy as well.

Agreements

Incident preparedness often also requires one or more memoranda of understanding (MOUs) and teaming agreements with various stakeholders. Basically, the parties involved need to agree on the conditions that will be put on the shared data and services that they might provide each other during an incident. Issues may include data access, lifetime, and destruction.

Distribution Methods

Distributing data has always been a difficult task, and local data must be maintained using traditional methods — file updates, file replication, and synchronization.

However, using Web-based and distributed data allows for dynamic updates to be provided at one server, with automatic updating of clients. The adoption of standards, both open and proprietary, is making this increasingly easy.

Response

Within four hours of the Columbia Space Shuttle disaster, U.S. Northern Command (NORTHCOM) was engaged with more than 80 agencies — with many of which it had never had any previous contact. By deploying small teams with standard kits to various parts of the search area, NORTHCOM was able to coordinate and catalog a large amount of data, but sharing of that data was still limited mainly to the military network.

Similarly, the response to last year's December 26 Tsunami has created a massive need for shared geospatial capability, yet the major method of sharing information has been to use static and non-georeferenced files, such as JPG and PDF. Though these products are helpful, and provide more information than was available historically, they don't allow the sharing of information between the people responding to the disaster. Any information that individuals "mark up" on these maps and images is typically not shared, and when it is shared, the results are often not reliable in a geospatial system.

The reality of incident management is that there is a limit to how prepared any organization can be, especially when geospatial data and technology are involved. When an incident occurs there are often new players involved, and it is likely that a lot of the preparation that has been done is out of date. Therefore, the most important aspect of using geospatial technology and data for response is flexibility.

Being flexible allows teams to work together without being handcufffed by using a rigid system that doesn't quite meet their needs.

Many of the following items can be validated and examined during the incident response exercises that should occur in the preparation phases.

Deploy Teams

Field teams and other deployed personnel need to be at various locations to work — ideally with network communications, or some limited access to networks when required.

Geospatial support teams may need to be located at various sites, including sites that don't have reliable communications (see the section on communications, below) and they must all be capable of operating if they rely on a geospatial system.

Deploy & Maintain Data

Once an incident has occurred, the teams need to deploy with their data. Field teams and remote members need access to local data in the event that their network connections are not available. Updating team members in the field and adding new layers and services are non-trivial tasks that should be supported by a geospatial system.

Field Updates

Updates from the field need to be examined for several factors, including:

• Relevance: is the update relevant to others?
• Criticality: critical updates need to be dealt with differently than non-critical ones.
• Temporality: is this update only important for a specific time period?

Based on these various factors, updates to the base information would be made using appropriate workflows and processes.

Add Layers & Services

As an incident progresses, and the needs of the responding teams become more clear, more layers of specific information can be brought to bear as a better understanding of the situation develops. Different situations warrant different responses. To benefit most from a geospatial system, one must be able to add information as it becomes available, and as its relevance is discovered.

Integrate External Data & Services

To be properly supported during an incident, a deployed team needs to have access to various data and services that may be hosted by different organizations. Geospatial experts can provide these linkages to the team — allowing the team to focus exclusively on its incident response tasks. Only the experts need to know exactly how a certain service is connected.

Most importantly, the integration of external data and services should not require additional effort on the part of the incident responders. If it does, they are likely to discard the data and services rather than take on the additional effort.

Logging and Snapshots

An incident response system should allow responders to take snapshots of the situation as the incident proceeds, for use later in logs and post-incident analysis.

Briefing

Typically, sharing geospatial information for a briefing involves either printing out a map or cutting and pasting a screenshot into a PowerPoint presentation. Neither of these briefing techniques provide access to a current situation picture: they are only providing a static snapshot of an incident, which means that the people being briefed are being presented stale information. Snapshots in time are valuable, but they should not be the only method for briefing if incident responders are going to get the full situation picture.

In order for a system to provide an immediately relevant situation picture, it must allow briefing directly from a live situation picture. Live data feeds — such as resource locations and status, weather, and incident locations — provide a better context for briefing, unless the briefing topic is specifically based on a moment in time that has passed.

Communications

Communications in incident management are critical, but they are typically voice-based. Geospatial technology requires network communications, which are often a scarce resource in a crisis.

Information Flow

In an incident that involves more than one organization, there are typically four types of information flow/sharing:

Organized Information Routes — pre-established information flows, usually planned well ahead of time in the preparation phase, and consistent with the operations of a given group.

Planned or Temporal Events — groups establish information sharing guidelines to support a given incident.

Persistent and Dynamic Communities of Interest — groups that form to share information in general ways, constantly changing the way they share information and how it flows. This is an adaptable group that maintains a certain level of capability, which may transfer to one of the other modes.

Unplanned and Ad Hoc — when there is no planned method of exchanging information at the time that an incident occurs. Ideally this team would move into another mode, either during the incident, or in the post-incident follow-up.

Be Flexible

In the response phase of incident management, one of the most important aspects to using geospatial technology and information is to be flexible. Communications may not work, but responders may find alternate means of exchanging information — such as direct connections, using a computer as a relay, etc.

Link, Don't Duplicate

One of the major tenets of good geospatial systems is that we should never duplicate information unless we absolutely must. Another way to say this is "Own only what you have to, influence the rest."

By leaving ownership with other agencies, data can likely be kept more current. If another agency's information is mission-critical to your team, then you will want to influence it, and likely replicate a copy to your own site.

Duplicated data is one of the first items that is cut from IT budgets, and if incident preparation assumes that the database is local (and current) but it isn't, the response to an incident may be compromised at some level.

Summary

Base data can be prepared but plans should be made to update and augment this data as the incident proceeds. Establishing a set of services to access for new and more detailed data will allow this to happen quickly.

Agreements set out beforehand will increase the quality and timeliness of data getting out to teams in the field. Setting up approved, secure, and reliable distribution channels will also make sure that data flows properly between organizations.

Teams can be deployed with a standard kit that allows them to cooperate. This kit includes a set of base data that can be maintained and updated in the field. As the incident proceeds, new layers of data can be added. This data can come from several sources, including commercial services. These updates should be made as easy and seamless as possible, allowing the teams to concentrate on their main task.

Briefings should incorporate live data as much as possible. The system should allow logging and snapshots of the data for review of the progress of the incident or post-incident analysis.

The field systems should be as flexible as possible. Information flow and communities of interest are going to change and paths of communication will change with them. Even the underlying networks and infrastructure may evolve in unexpected ways.

About the Author

Darrell O'Donnell is the Chief Technology Officer and co-founder of Black Coral Inc. He has created incident management systems for mission-critical areas such as military response, and search & rescue (both civilian and military). He may be reached atdarrell.odonnell@blackcoral.net.