It may surprise both the public and the public safety industry to learn that during a wildfire response, we often lack real-time information on the locations of our wildland firefighters. While we have mechanisms in place to ensure their safety, we have yet to establish an industry-wide approach to producing live location maps that enhance the safety of our first responders.
This is because it is difficult to plot firefighter locations in the disconnected and rugged environments in which we operate. In fact, I’ve often heard the mapping of real-time locations of firefighters referenced as the “holy grail” of fire data. Comparing this data to the “holy grail” is meant to conjure thoughts of a supremely difficult task fraught with insurmountable roadblocks and describe a feat nearly impossible to achieve. Much to the chagrin of Indiana Jones fans everywhere, I disagree with this comparison. I disagree because I think that our quest for location data is much simpler. The technology to enable this capability exists, and its adoption is within reach for many.
For any organization, deciding how to implement location-sharing workflows is a significant decision that requires intentional planning. Solving this problem will necessitate commitment, effort, research, and likely funding from the implementing agency. Those who disagree likely have a bridge to sell you – I’ll be looking forward to those silver bullets getting dropped into the comments! To sustainably implement location sharing within your organization, several questions need to be addressed: Which vendor should we select? Where will the data reside? How will we visualize it? How can we integrate it with data already in our GIS? Can we enrich the data? While reputable vendors can readily answer most of these questions, agencies also need to consider business rules and data schemas. In fact, I would wager that the main barrier to the widespread adoption of location-sharing technologies is often not the technology itself but a lack of best practices, standardized data schemas, and administrative and business rules surrounding its use.
Since most public safety agencies use ArcGIS daily, it is valuable to frame the issue from this perspective and provide a pathway forward. The architecture we have developed also retains an agency’s flexibility in how to populate firefighter (or mobile worker for those of you not lucky enough to be a wildland firefighter) locations within the ArcGIS ecosystem.
To begin, we need to understand the major environments in which we need to achieve location-sharing capability. For a complete location sharing solution, organizations need to ensure that they can see their field personnel across the following environments:
- Connected: In this environment we assume that our responders are operating within cell or Wi-Fi connectivity where we leverage that connectivity to populate ArcGIS with location data. This is by far the easiest of scenarios to achieve location sharing and can be accomplished with the appropriate user type and any of the field apps you already own.
- Disconnected – Responder to Responder (Disconnected to Disconnected): In disconnected environments (no cell or Wi-Fi service) responders need to know where one another is located. To achieve this, we need technology that creates a local area network (LAN) of sorts – a mesh network. This ensures that location data can be exchanged between the devices in the field. As a result, responders can visualize one another on a common map in the disconnected environment.
- Disconnected – Responder to Incident Command Post (Disconnected to Connected): While we want the responders that are operating in the field to know where one another is located, we also want to ensure their locations are visible to incident management teams or managers in connected environments. This means that we need something more than a mesh network because we need to retrieve the location data out of the field and make it accessible for decision makers in connectivity at places like an Incident Command Post. Note: Mesh is still required for offline responder-to-responder location sharing.
When we achieve location-sharing capability in each of the above environments, we can finally say we’ve solved location-sharing. Until then, we still have work to do. For the purposes of the rest of this article, we are going to focus on the third scenario as it’s one of the larger needs for public safety agencies.
The Problem
It is common for crews of firefighters to work deep within remote forests, wilderness areas, or other challenging environments—places where connectivity is limited or nonexistent. Under these conditions, even radio communication can be sporadic; thick canopies and rugged landscapes block signals, and the nearest cell tower may be miles away. This is the reality for 90% of wildland firefighting work. In such disconnected environments, tracking the location of each firefighter becomes nearly impossible.
For decades, the challenge of location sharing in disconnected areas has been persistent. Tools designed to enable communication and situational awareness—such as cell phones and radios—often fail in these environments (learn to take your maps offline here). Yet, it is precisely in these settings that location sharing becomes most critical. How can we ensure the safety of our firefighters when traditional methods of communication fail? The answer lies not in reinventing the wheel but in reimagining how we use existing technology. The challenge we face is primarily infrastructural, not technological. The question is how to capture location data without relying on traditional connectivity.
A Solution
While this may seem like an obvious solution, it is remarkable how underutilized GPS technology is in wildland firefighting. GPS has always offered a means to plot locations outside of connectivity. However, until recently, integrating real-time GPS location feeds into widely used SaaS platforms like ArcGIS Online has been challenging, and as an industry, we have not fully adopted this technology.
Leveraging ArcGIS Velocity, Esri’s real-time engine, we can now ingest live data feeds (vehicle locations, aircraft locations, etc .) via a push API and drop firefighter, equipment, and aviation locations right into your existing ArcGIS Online infrastructure. This method works with almost any GPS device whose data can be pushed out of an API. Once it’s in ArcGIS Online, it’s just a feature service – move it across the ArcGIS ecosystem anywhere feature services are accepted! It is also important to note that ArcGIS isn’t always the end-user preference for incident management applications, and that’s ok! For instance, Interra, Technosylva, Tablet Command, 3AM, and a host of others accept feature services and can easily ingest this type of data. This means that ArcGIS becomes a simple way to house and broker data between your geospatial applications of choice.
Through ArcGIS Velocity, not only do we get firefighter locations in ArcGIS Online, but we also can enrich the location data, enabling us to set up geofencing and sort firefighters by specific attributes like their qualification level. This means that I can search for a specific division/group supervisor, crew boss, engine boss, or any other qualification level as needed. If I want to visualize the locations of all the resources within a specific division on an incident, there’s a filter for that, too. As each firefighter, piece of equipment, or aircraft moves across the fire area, their location automatically (through geofencing, not magic) updates with the Division in which they’re located. This increases our situational awareness in traditionally disconnected environments. No longer are we bound by the constraints of cellular networks.
Here is a quick look at what combining firefighter location feeds, other feeds like AVL, ADS-B, firefighter location, etc., data and geofencing by Division could look like within an ArcGIS Dashboard:
For those wondering about the technical architecture required to enable this work, check out the high-level graphic below:
Cool, right? You’ll note that ArcGIS Velocity does not care about the brand of GPS you’re utilizing so long as that GPS data can be pushed into Velocity via a push API. While that’s a lot of tech talk, the main point here is that technology is no longer the primary barrier to tracking firefighters in disconnected environments. It is now an issue of agency capacity to implement this work; one of business requirements and data schemas.
For agencies ready to take the next step, start by identifying key stakeholders within your team who will manage location data and partner with vendors experienced in providing location-sharing solutions. Begin with a pilot program that tests location sharing in a controlled environment, and use this opportunity to refine your business rules and data management protocols before scaling up.
The question organizations should ask is no longer ‘Can we track firefighters?’ but rather ‘How are we going to track them?’ The focus should shift to business requirements, such as determining who is responsible for managing this data within an agency or Incident Management Team and how to integrate disparate, mutual aid agency location feeds. While I have my own opinions, these questions are for the agencies involved to answer, and I am jealous! What an exciting opportunity for organizations to be at the forefront of solving location-sharing issues.
In Indiana Jones and the Last Crusade, inarguably the best installment of the series, the key to securing the ‘holy grail’ was ultimately about ‘choosing wisely.’ As we close in on our own ‘holy grail’ of location sharing, it’s not just about having the tools—it’s about choosing to use them. With all the technology involved, it’s easy to forget that behind every GPS dot is a firefighter—someone’s colleague, friend, or family member—and each moment we track is not just a data point but a heartbeat. We have a responsibility to ensure these data points are not only visible on our screens but also make it home safely.
NAPSG Currently Utilizing ArcGIS Velocity and GPS to Track US&R Teams During Response to Hurricane Helene
I often read blogs about how things “could” be done. Hurricane Helene offers a timely and real-world example of how things “are” being done. The National Alliance for Public Safety GIS Foundation (NAPSG) is utilizing ArcGIS Velocity and GPS, as described in this article, to track US&R members during Hurricane Helene response efforts.
NAPSG is obtaining location data for over 100 US&R teams and 300 responders across 6 states to the Incident Command Post, even in areas where service is unavailable. This deployment demonstrates that the technology for tracking real-time responder locations is not a future aspiration but a current reality. Stay tuned for an upcoming case study on NAPSG’s work during Hurricane Helene.
