What GPS does under bridges and between towers
Short answer
A phone in a tunnel rarely loses position so much as it accepts a worse one, because a signal that arrives after bouncing off a wall is still a signal. That is why a run under a bridge often records a track that wanders sideways instead of stopping, and why a downtown loop can read long while a covered section reads short. Nothing an app does afterwards can recover the position it never had.
A phone under a bridge usually keeps reporting a position. It just reports a worse one. That single fact explains most of what shows up on a track afterwards: the sideways wander through an underpass, the downtown loop that reads long, the covered stretch that reads short.
Four environments break a run in four different ways.
Why a blocked signal is not the same as no signal
Losing the fix completely is rare. The common case is a fix that is still there and is wrong. GPS.gov lists the usual causes of degraded positioning as satellite signal blockage from buildings, bridges and trees, indoor or underground use, and signals reflected off buildings or walls, which it names multipath (GPS Accuracy, GPS.gov, checked 2 August 2026).
The same page puts a number on the everyday case and on the exception in one breath. GPS enabled smartphones are described as "typically accurate to within a 4.9 m (16 ft.) radius under open sky", followed immediately by "their accuracy worsens near buildings, bridges, and trees" (GPS Accuracy, GPS.gov, checked 2 August 2026). Open sky is the number most people remember. The sentence after it is the one that describes city running.
There is a further sentence worth reading in the government's own performance document. Section 2.4.5 of the GPS Standard Positioning Service Performance Standard, 5th Edition of April 2020, is headed Excluded Errors, and states that the published standards "do not take into consideration any error source that is not under direct control of the Space Segment or Control Segment". The list of specifically excluded errors includes "Multipath and receiver multipath mitigation" (Performance Standards and Specifications, GPS.gov, checked 2 August 2026). Whatever GPS is committed to deliver, it is committed in space. What the signal runs into in its last few hundred metres, between a bridge deck and a glass facade, was never part of that commitment.
That gap has a practical shape. A fix arrives as a position together with a reported accuracy radius, and the radius is the receiver's own estimate of its own uncertainty, worked out from the same measurements as the position. An error the receiver cannot detect therefore lands in the position without widening the radius. The number that reaches the app looks exactly as trustworthy as the one before it.
Nothing warns you.
Multipath in one paragraph
A satellite signal that bounces off a wall has travelled further than the direct one, so the range it implies is too long. Multipath is the case where the direct signal arrives as well as the reflection. Non line of sight reception is the case where the direct path is blocked and only the reflection arrives, and the receiver then solves a position from a range that is simply wrong. Hsu, Gu and Kamijo put it plainly: "The high buildings and skyscrapers can easily block or reflect the GNSS signal to induce the signal delay, which are well-known as the multipath effect and non-line-of-sight (NLOS) receptions." In their field tests a conventional weighted least squares solution had a mean horizontal error of 24.28 m in a middle urban canyon and 23.99 m in a deep urban canyon (Sensors, 2015).
These errors are not the random noise you can average away over a lap. The reflections come from the geometry of the street, and that geometry does not change between Tuesday and Thursday. A simulation study of urban canyons found reflection delays following gamma distributions whose shape parameters decrease as the canyon gets deeper, which is to say the error profile is a property of the place (Ollander, Bode and Baum, 2020).
The riverside underpass
A short covered section is a geometry problem. It is not necessarily a full outage. Part of the sky disappears and fewer satellites are usable. Some of what still arrives has come off a wall. Runna's support documentation lists what weakens or blocks the signal in the same terms: "Tall buildings, Dense tree cover or forests, Tunnels, Adverse weather conditions" (GPS Data Inaccuracies, Runna Support, checked 2 August 2026).
You get one of two pictures. Either the line stays continuous and pulls to one side, which normally adds distance, or the fixes stop and the app joins the two ends. Runna describes its recording as relying on "a continuous stream of location points to calculate your distance, speed, and route" (Runna Support, checked 2 August 2026), and a stream with a hole in it has to be joined somehow.
What to do about it: do not judge an underpass segment by the map. If a route you run weekly passes under the same bridge, the error repeats, so week to week comparisons on that route are still meaningful.
A single split through it is not.
The downtown grid
Grids are the hardest case. The sky is reduced to a strip and the walls on both sides reflect. Nothing is blocked outright, so the phone keeps producing positions built partly from ranges that are too long, and that is the environment the urban canyon figures above were measured in.
On the map you see corners rounded off and the line sitting on the wrong side of the street. It also jumps between two parallel paths. Distance can land either way. Cut corners take it out. A track that oscillates between two lines puts it in. Two apps recording the same city run can therefore disagree without either being broken, a problem with its own separate causes covered in why two apps measure different distance.
What to do about it: keep one reference loop away from tall buildings and use it whenever you need a pace number you can trust. Downtown loops are still useful, because the same error repeats each lap.
They are just not comparable with a park loop.
Covered markets and station concourses
A roof at ground level is where a phone is most likely to stop using satellites at all. GPS.gov lists indoor and underground use as a cause of degraded positioning in its own right (GPS Accuracy, GPS.gov, checked 2 August 2026), and with satellites unavailable a phone can still place you from Wi-Fi and cell towers, which is a coarser answer delivered under the same label as the good ones. Runna names that substitution as a downside of battery saving modes, which "rely more on WiFi or cellular signals, so this could also reduce GPS accuracy" (GPS Data Inaccuracies, Runna Support, checked 2 August 2026). Under a market roof the same substitution can happen without you having chosen it.
The signature is a position that parks in one spot while you keep running, then jumps to wherever you came out. Elapsed time is unaffected.
Distance for that stretch is either missing or assumed.
What to do about it: treat covered stretches as unmeasured. If you can, put the turnaround of an out and back outside the covered section, so the part you use for pacing is the part that was measured.
Dense tree cover
Canopy attenuates. It rarely blocks outright, so the fix survives and quietly degrades. It also changes with the season, which is the detail that catches people out. A study of smartphone positioning in forests reported root mean square errors of 4.96 to 11.45 m in leaf on conditions and 4.51 to 6.72 m in leaf off conditions, against 1.90 to 2.36 m in open areas (Tomaštík et al., Forestry, 2017).
What to do about it: compare summer trail runs with summer trail runs. If the same wooded loop measures differently in July than in January, the leaves are a likelier explanation than your fitness, and switching apps will not settle it.
What you will see on the map afterwards
Most of the time the cause is legible in the shape of the line.
| What the line looks like | What it usually means | Likely effect on distance |
|---|---|---|
| Continuous but drifting sideways off the path | Positions were still arriving and were still being accepted, built partly from reflected ranges | Reads long, because the sideways wander is counted as movement |
| A straight chord across a section you ran | Fixes stopped and the two ends were joined | Reads short if the real path curved |
| Sharp zig zag between two roughly parallel lines | Consecutive fixes solved from different satellites or different reflections, so the answer flips between two candidates | Reads long |
| The line parked in one spot while time passed | No usable fix, or a position from a non satellite source that did not update | Reads short, or nothing at all for that stretch |
| The line running along the opposite side of the street | Non line of sight reception putting the solution on the wrong side | Roughly the right length in the wrong place |
None of this can be repaired afterwards. Smoothing changes the drawing, not the measurement, and a position that was never observed is not recoverable. An app that draws a tidy line across a tunnel has made an assumption.
What an app can honestly do about it
It cannot improve the fix. What it can do is be exact about which parts of the run it actually measured, and refuse to make claims that rest on readings it does not trust. In practice that comes down to four behaviours.
- Store "we had no basis to measure this" as a different value from zero, so a screen can say which one happened
- Record how much time was dropped from the distance. The total is then a lower bound, not a measurement
- Suspend any judgement that depends on knowing where you are, instead of making that judgement on readings it has already decided are unusable
- Keep recording elapsed time
On a curated route Runflake does the third of these explicitly. When the signal drops it stops judging the course rather than declaring you off it, and the screen says "No usable signal, so the course is not being checked. Your run keeps recording." A gap of up to 5 seconds between usable fixes does not reset the off route evidence, and turn cues are not pushed forward while course judging is suspended, so a signal gap cannot make the app skip past a corner.
The other two show up in what gets stored. Elevation is an estimate from GPS, so the database deliberately keeps "no basis to measure" distinct from "flat", and a screen can tell the two apart. When gaps caused distance to be dropped from a run, that run records how much time was excluded, which is what lets the distance be presented as a lower bound instead of a measurement.
Hold the environment constant when you want to compare. Keep one clean loop for pace work, and read covered or canyon sections by time and effort instead of by the map. A run you can interpret is worth more than a run that looks tidy.
Common questions
- Does a run keep recording when the GPS signal drops?
- The clock does not depend on satellites, so elapsed time keeps running in most apps. What stops is distance, because there is nothing to measure movement against until usable fixes return. Whether the missing stretch is later filled in with a straight line or left out entirely depends on the app.
- Why does one run read long in the city and short in a tunnel?
- Degraded positions wander sideways while the app keeps treating each step of that wander as movement, which adds distance you did not run. A covered stretch with no usable fix is usually joined with a straight line instead, which understates a path that curved. The same run can be inflated in one place and understated in another.
- Can I repair a bad GPS track after the run?
- Editing the file changes the drawing, not the measurement, because the position was never recorded correctly in the first place. The practical response is to repeat the same route so you are comparing like with like, or to judge the affected section by time and effort rather than by distance.