GPS tracking of rescue teams: what works in the field, and what only works in the demo

Ask any coordinator who has switched from radio check-ins to a live map what changed, and you get a version of the same answer: the arguing stopped. No more "we are about two hundred metres below the ridge, maybe", no more two teams discovering at dusk that they searched the same gully. You look at the screen and you know.

Then you take the same system into a limestone gorge with no mobile coverage, in February, with phones that have been in a cold pocket for three hours, and you learn the rest of it.

Both of those are true at once. This is what tracking actually does for a search, where it breaks, and what you have to get right — technically and legally — before it earns your trust.

01What live positions actually give you

The obvious answer is "you know where your teams are". The useful answer is more specific, and it is worth being precise about, because it tells you which features are worth paying for.

Coverage you can verify

A recorded track shows where the team actually walked, not where they were assigned. The difference between the two is the most honest coverage assessment you will ever get, and it frequently surprises the team leader as much as the coordinator.

Assignment without a map briefing

The sector is on the searcher's phone with their own position on it. This removes an entire category of error: the team that searched a neighbouring drainage because the briefing map and the terrain did not agree.

Reassignment mid-period

A lead comes in, and you can see which of nine teams is twenty minutes away instead of asking all nine over the radio.

Accountability for people, not just ground

Someone has not moved in forty minutes and has not answered. On a paper board that is invisible until the debrief. On a live map it is a question you can ask now.

A record that writes itself

Tracks, timings and sector coverage end up in the after-action file without anyone transcribing anything at 03:00.

That last one is quietly the biggest. The parts of an operation that get abandoned first under pressure are the parts that require someone to write something down. Tracking removes the writing.

02Where it breaks, part one: the physics

A modern phone using GPS together with the other constellations gets a position within a few metres under open sky. That figure is real, and it is also the number that misleads people, because search and rescue work does not happen under open sky.

Under dense conifer canopy, accuracy degrades. In a steep gorge it degrades badly, because the receiver can only see a narrow strip of sky and picks up signals that have bounced off the opposite wall — a phone can confidently report a position on the wrong side of the river. Next to a rock face the same effect puts a searcher inside the mountain. None of this is a bug in the app, and no software fixes it.

What good software does instead is tell the truth about it: show the reported accuracy, show the age of the fix, and make a stale position look different from a fresh one. A dot on a map with no timestamp is a lie waiting to be believed. A coordinator who sees "last position 18 minutes ago, ±40 m" makes a different and better decision than one who sees a confident dot.

03Where it breaks, part two: the network

Here is the distinction that most discussions of this get wrong. GPS is a receiver. It works with no mobile network, no SIM, no signal at all — the phone knows where it is. Sharing that position with the operations centre is a completely separate problem, and it is the one that fails.

Mobile coverage in the terrain where searches happen is patchy at best. Your teams will spend long stretches with nothing. If the tracking system needs a live connection to record a position, everything from those stretches is simply gone — and those are exactly the sectors nobody can otherwise account for.

So the requirement is not "works offline" as a marketing line. It is specific: the app records positions locally on a schedule regardless of connectivity, and when the phone reaches coverage again it uploads the whole buffered track, timestamped, not just the current position. A team that walks out of a dead zone should fill in the last two hours of map, retroactively. Ask any vendor to demonstrate exactly this, in airplane mode, before you believe anything else in the demo.

Most organisations end up with a mix, and that is the correct answer, not a compromise. Phones for the many, satellite for the exposed tasks, radio as the layer that never fails, and a coordinator who knows which teams are on which.

04Battery is the actual limit

Continuous positioning with the screen occasionally on, in the cold, on a two-year-old phone that also has to run the radio app and take photographs, is a real drain. Nobody in the field cares about your reporting architecture at hour seven; they care that the phone died at hour five.

The lever is the reporting interval, and the right setting is not the fastest one. A map that updates every thirty seconds looks impressive in a demo and buys a coordinator almost nothing over one that updates every two minutes — teams move at walking pace. Set it against the operational period: the phone must survive the shift with margin, on a cold day, on the oldest handset in the team.

• Set the interval per mission, not once globally. A vehicle-based task and a slow grid search do not need the same rate.
• Brief power banks as mandatory equipment, at the same level as a headtorch. This is a cheap fix that organisations postpone for years.
• Keep the phone warm. Lithium cells lose a large fraction of their usable capacity in the cold, and an inside pocket recovers most of it.
• Make it obvious in the app when tracking has stopped. Silent failure is worse than no tracking, because the coordinator keeps trusting a position that stopped updating twenty minutes ago.

Click to enlarge

05Consent, GDPR, and what volunteers are actually worried about

Location data about identified people is personal data, and continuous location is among the more sensitive kinds of it. If you operate in the EU or a country aligned with the GDPR, this is not a formality you handle with a checkbox during onboarding.

The first thing to get right is the legal basis, and the intuitive answer is the weak one. Consent has to be freely given, and consent given by a volunteer to the organisation they belong to is questionable on exactly that point — the person cannot easily refuse without consequences for their standing. Many organisations are on firmer ground relying on legitimate interests, or on a public-task basis where rescue is a statutory function, with a documented assessment of why tracking is necessary and proportionate. That assessment is also what you show a regulator, and writing it takes an afternoon.

On duty only, and visibly so

Collect position while a rescuer is deployed on a mission and at no other time. The app should make the state unmistakable — a persistent indicator, a clear start and a clear stop. Continuous tracking of volunteers off duty is indefensible and, more practically, is the thing that will get the system rejected by your own members.

Purpose limitation, in writing

Location is for coordinating the operation and for the safety of the searcher. Not for performance review, not for checking who was slow, not for attendance. State it, and mean it, because the first time it is used for something else the trust is gone permanently.

A retention period you can defend

Tracks are part of the operational record and there are good reasons to keep them — coverage evidence, after-action review, occasionally a formal inquiry. There is no good reason to keep them forever. Set a period, write down the reasoning, and delete on schedule automatically.

Access on a need-to-know basis

Coordinators on the active mission see live positions. Not every member, not indefinitely. Role-based access is a data-protection control before it is a product feature.

Transparency that a person actually reads

One page, plain language: what is collected, when, who sees it, how long it is kept, how to ask for it or object. This is a legal requirement, and it is also the document that gets your members on side.

The concern members actually raise, when you ask them properly, is rarely about the regulation. It is "is my employer, or the person I had an argument with last year, going to see where I was on Sunday". Answer that question directly and most resistance disappears.

06Introducing it without a mutiny

The failure mode is predictable: the leadership buys a system, announces it at a meeting, half the members install it, a third of those never open it again, and six months later the map in a real callout shows four of the eleven teams. At that point the map is worse than no map, because it looks complete.

1. 01Run it on a training exercise first, with no operational dependency on it. Let people see the map afterwards — the recorded tracks of a training search convince people better than any presentation.
2. 02Solve the phone problem before launch, not after. Someone will have a five-year-old handset. Decide what you do about that person now.
3. 03Write the one-page transparency note and hand it out before the first install, not in response to the first complaint.
4. 04Make the on/off state impossible to misread, and tell people how to verify it themselves. Trust here is built by verification, not by assurances.
5. 05Give it one operational period of patience in the first real callout, with radio check-ins running in parallel. Then compare. The comparison is what converts the sceptics.

A tracking system with 60% of your members on it is not 60% useful. It is a map with invisible holes, and holes you cannot see are worse than holes you can.

None of this makes the technology less worth having. Live positions genuinely change how a search is run, and organisations that adopt them properly do not go back. But the value comes from the parts nobody demonstrates: the buffered track that fills in after two hours of no signal, the accuracy figure next to the dot, the automatic deletion at the end of the retention period, and the fact that every one of your members installed it because they were not worried about what it does.