I’ve been involved in mapping wildland fires for almost as long as I have been doing GIS. In these decades, much of the technology has changed. In just a few years we’ve moved from standalone GPS units to smartphones, from ArcGIS desktop to ArcGIS Online, from ArcPad to Collector.
What hasn’t changed, however, are the basic principles of serving multiple clients in a situation of urgency. In this article I’ll explore some of the lessons learned by myself and other heroic “hidden figures” who operate behind the scenes. These stories are specific to fires, but they apply to nearly all GIS operations.
Challenges
It’s never the same day. On a large incident, temporal and spatial scales are widely variable and dynamic. A large fire may go on for months, but dramatic changes can happen in hours or even minutes. The number and variety of response resources is astounding: planes and helicopters, men and women with hand tools, fire engines, biologists, archaeologists, and of course, mapping specialists.
Mapping is critical to all elements of a fire incident, or any kind of disaster response. From the high-level managers who plan the moves of thousands of people and resources, to the crews fighting the heat and smoke on the fire line, to the residents affected by the fire, everyone needs maps. But the priorities can change quickly.
Data comes from all directions. All of us have had to integrate data from multiple sources. On a fire or other incident, it can become even more chaotic. Since fires know no geographic boundaries, we may be taking parcels data from several local counties, base data from multiple agencies, infrared heat images from the interpreters (who work night shifts) and sensitive resource data like rare plants and archaeology sites from the resource advisors.
Then, of course, there is field data from the ground crews and incident managers. I’ve been delivered paper maps with handwritten mark-ups, and GPS units with points that have no names and tracks that look like spiderwebs. The job of the GIS team is to integrate these data and turn them into maps that can be used by all of the resources on the incident.
Multiple products need to be delivered quickly and on-demand. These maps take many different forms and formats. At the beginning of each shift there is a briefing, at which every resource receives an Incident Action Plan, or IAP. The IAP contains critical information about radio frequencies, command structure, weather, fire behavior, and of course, a map of the current fire situation. This has to be an 8.5-by-11-inch map that can be easily reproduced in black and white.
Also at the briefing, there needs to be a briefing map. This is a large format map, sometimes called a BAM, short for Big A—Map. It has to be visible to dozens of people looking at a signboard or the side of a command trailer. It’s big, it’s in color, and usually has to show everything: where the crews are working, where the built and proposed fire lines are, values at risk, helispots, evacuation areas, and water points, along with the basic data of the fire perimeter, roads, and the Incident Command Post.
Then there are the specialty maps. Crews and resources often come from far away and need a map to the ICP or to the fire itself. If air resources are involved, they need a map of potential hazards to aviation as well as no-fly zones, such as around an eagle's nest. When structures are affected, maps displaying the level of damage need to be delivered both to incident staff and the public and news media.
These maps must be produced in different formats. On my assignment on a large fire in 2005, these were all paper maps. Increasingly, however, maps are delivered digitally for deployment on mobile devices and web mapping applications. Regardless of the format, the maps all require usability (since very few consumers are GIS-savvy), consistent symbology, and accurate data.
Lives, homes, and livelihoods are at stake. It’s not just the responders who are affected by a fire. As civilization expands ever farther into the wildland-urban interface, more critical infrastructure is at risk. Homes in the fire area are the most obvious example, but also consider powerlines, reservoirs, critical habitat for flora and fauna, and of course, the men and women on the ground.
The data has to be right, and it has to meet the needs of the clients. I discovered on one incident that because the coordinates of a crew’s position were reported in decimal degrees instead of degrees-decimal minutes, their location was three miles off, on the other side of a ridge. (Fortunately, we were able to locate them by a verbal description of their location over the radio.)
It is a world of acronyms. In the GIS Standard Operating Procedures on Incidents manual there are a full three pages of acronyms and their meanings. Along with all the usual GIS acronyms (.mxd, .gdb, NAD83, etc.) every role on a fire has its own code (SITL = Situation Unit Leader, IRIR = Infrared Interpreter), as do most critical locations, like ICP. Obviously not all codes are used by all resources, so blank stares may be exchanged when the crew leader says, “Here are the GPS coordinates from the READ” and I ask, “Are they NAD83 or NAD27?”
Solutions
As you can see, the challenges are daunting. The number of moving parts on even a small incident can seem overwhelming, and on a large incident, spread over tens or hundreds of thousands of acres, they multiply exponentially. But obviously, something is working. Here are some of the ways these challenges are met.
Success comes from structure. The keystone of managing any incident is the Incident Command System. Developed cooperatively by many agencies, the ICS is “a management system designed to enable effective and efficient …. incident management by integrating …. facilities, equipment, personnel, procedures, and communications operating within a common organizational structure.” (fema.gov)
The ICS is scalable, so it can be used from a single tree set on fire by lightning, to a multi-state hurricane. Roles are clearly defined, as is the reporting structure. The GIS specialist or team reports to the Situation Unit Leader, whose duty (among many others) is to help the team prioritize the many mapping needs. The SITL reports to the chief of the Planning Unit, who is responsible to the Incident Commander.
The same is true of the GIS Operations. In the nascent days of the early 2000s, the map products were fairly clearly defined, but the means of producing them were not. From incident to incident, the data structure and symbology were built from the ground up. Since then, the methodology has become much more standardized.
This is detailed in the “GIS Standard Operating Procedures on Incidents,” AKA the GSTOP. Published by the National Wildfire Coordinating Group Geospatial Subcommittee, the GSTOP was built over several years with input from fire managers, GIS specialists and field crews, among others. It contains guidelines and Standard Operating Procedures for data structure, map symbology, map products, and of course, a dictionary of acronyms.
One of the most significant developments in the standardization of GIS operations are the requirements to be a GISS on an incident. As is the case with a helispot manager or an incident commander, the GISS must be certified in certain skills. You start off as a trainee with a task book, working under a qualified GISS. As you move through the incident, required skills are checked off as accomplishments. It can take several incidents for the task book to be completed, but once it is, you are certified as a GISS and can operate independently on a team.
Soft skills are critical. As I have mentioned in previous articles, being able to speak your clients’ language is as important as knowing the software and making datum transformations. After even a few days, fatigue and adrenaline are affecting everyone. Egos and tempers may flare as hot as the fire. Everyone’s map is absolutely the most important and urgent. The command structure can mitigate this, but since everyone is constantly multi-tasking, going to the supervisor may not be an option. Knowing when to say yes, no, or maybe is a critical skill that has to be learned through experience, both good and bad.
Summary
Even if you have never been on a fire or other incident, these scenarios likely sound familiar. Hopefully your duty days are shorter and less smoke-filled, but they can be just as stressful. The lessons learned from using GIS on emergency incidents also apply to every GIS operation. Have a structure in place before you start a project. Accept that you have to accommodate the data, because they won’t accommodate you.
Know who your clients are and what they need. Be able to talk to them in their language, not just GIS-ese. But maybe you don’t speak aviation or archaeology. So, perhaps most important of all: Never be afraid to ask questions. The only dumb question is the one you don’t ask.