Why your location âjumpsâ even when you stand still
What youâre seeing is normal behavior for phone GPS, especially:
In a small area (like a sculpture garden),
With offline positioning (no Wi-Fi / network assistance),
And using high-frequency updates with BestForNavigation.
A few key points about GPS on mobile devices:
Typical real-world horizontal accuracy is 3â10 meters under good outdoor conditions. Near buildings, trees, or indoors, it easily gets worse.
Even if the user is completely still, the reported latitude/longitude will wander inside an error circle defined by coords.accuracy.
That means in a small map (say 30â50 m across), the natural noise of GPS can be a large percentage of the whole area. So the marker looks like itâs âjumping all overâ even though itâs just wandering within the uncertainty bubble.
So there is nothing âwrongâ with Expo Location itself. Youâre just seeing the raw limitations of consumer GPS very clearly because your map is small and your update settings are aggressive.
Issues in the current configuration
Youâre doing some reasonable things already (UTM transform, simple smoothing), but a few details make the jitter very visible instead of hiding it.
1. Over-aggressive watch settings
subscription = await Location.watchPositionAsync(
{
accuracy: Location.Accuracy.BestForNavigation,
timeInterval: 500,
distanceInterval: 0.5,
},
(newLocation) => {
setLocation(newLocation);
}
);
Problems here:
BestForNavigation is designed to be responsive, not perfectly stable.
timeInterval: 500 ms and distanceInterval: 0.5 m means youâre asking for very frequent, very fine-grained updates.
At that resolution, you see every tiny fluctuation in the GPS solution as a âmovementâ.
Youâre essentially subscribing to noise in high definition.
2. Over-optimistic accuracy filter
const acc = location.coords.accuracy;
if (acc && acc > 8) return;
Youâre discarding any reading where the accuracy is worse than 8 m. In many real environments, values below 8 m are rare. So what happens?
You ignore a lot of readings.
You occasionally accept âgoodâ ones that might still be off by several meters.
That makes your smoothed position jump from one âgoodâ estimate to another instead of drifting slowly.
3. Smoothing that doesnât actually smooth much
setSmoothedUtm(prev => {
if (!prev) return { x: rawUtm.x, y: rawUtm.y };
const dx = rawUtm.x - prev.x;
const dy = rawUtm.y - prev.y;
const movement = Math.sqrt(dx * dx + dy * dy);
if (movement < 0.3) return prev;
const alpha = 0.8;
return {
x: prev.x * (1 - alpha) + rawUtm.x * alpha,
y: prev.y * (1 - alpha) + rawUtm.y * alpha
};
});
Two main issues:
A dead-zone of 0.3 m is meaningless when GPS noise is 3â10 m. Almost every jitter is bigger than 0.3 m, so almost everything is treated as âreal movementâ.
alpha = 0.8 heavily favors the new (noisy) value:
new = 20% old + 80% new â thatâs closer to âforward the noiseâ than âsmooth itâ.
So the filter doesnât do much to hide the GPS wandering.
What you can realistically do
You cannot turn GPS into a centimeter-accurate indoor tracker with code. But you can:
Reduce how much jitter the user sees.
Make your routing logic robust to noise.
Align UX with the actual accuracy you have (meters, not centimeters).
Below are practical changes that work within the limitations.
1. Use less aggressive update settings
Relax watchPositionAsync so you donât hammer the GPS and you donât get spammed with tiny fluctuations.
For example:
subscription = await Location.watchPositionAsync(
{
accuracy: Location.Accuracy.High, // or Location.Accuracy.Balanced
timeInterval: 2000, // at most once every 2 seconds
distanceInterval: 2, // only if moved ~2 meters
},
(newLocation) => {
setLocation(newLocation);
}
);
This does two things:
In many cases, High or Balanced gives more stable behavior than BestForNavigation for walking around at low speed.
2. Filter by realistic accuracy and movement
Next, make the smoothing logic match real GPS behavior:
Accept readings up to ~15â20 m accuracy (beyond that, ignore).
Ignore position changes smaller than 2â3 m as noise.
Use a small alpha (0.1â0.3) so the filtered position moves slowly.
Example:
useEffect(() => {
if (!rawUtm || !location) return;
const acc = location.coords.accuracy ?? 999;
// Ignore very noisy readings
if (acc > 20) return;
setSmoothedUtm(prev => {
if (!prev) {
return { x: rawUtm.x, y: rawUtm.y };
}
const dx = rawUtm.x - prev.x;
const dy = rawUtm.y - prev.y;
const movement = Math.sqrt(dx * dx + dy * dy);
// Ignore small movements that are likely just jitter
if (movement < 2) {
return prev;
}
// Strong smoothing: mostly keep old position
const alpha = 0.2; // 20% new, 80% old
return {
x: prev.x * (1 - alpha) + rawUtm.x * alpha,
y: prev.y * (1 - alpha) + rawUtm.y * alpha,
};
});
}, [rawUtm, location]);
Now:
The marker will not âtwitchâ for tiny fluctuations.
Larger moves (user actually walking) will slowly pull the marker toward the new position.
You still respect accuracy constraints, but youâre not unrealistically strict.
3. Be honest about âarrivalâ distance
You currently trigger arrival when:
if (distanceToDestination !== null && distanceToDestination < 3) {
Alert.alert('Arrived!', ...)
}
If your GPS accuracy is ±5â10 m, checking for < 3 m is optimistic. The position might easily jump between 2 m and 8 m from the sculpture while the user stands in the same place.
Use a larger radius (e.g. 7â10 m) and maybe require the distance to stay under that threshold for a couple of consecutive readings:
const ARRIVAL_RADIUS = 8; // meters
useEffect(() => {
if (distanceToDestination == null || selectedDestination == null) return;
if (distanceToDestination < ARRIVAL_RADIUS) {
Alert.alert('Arrived!', `You reached ${TEST_POSITIONS[selectedDestination].label}`);
setSelectedDestination(null);
}
}, [distanceToDestination, selectedDestination]);
Itâs better UX to say âyouâre hereâ a bit early than never say it because of GPS jitter.
4. Accept that your map scale amplifies noise
Youâre mapping UTM â pixels based on sculpture coordinates that are very close together. When your entire site is, say, 30 m wide and your screen is 300 px wide:
Thatâs why the dot looks like itâs flying around.
There is no way around this from GPS alone. What you can do:
Visually de-emphasize the exact dot and focus on a âyouâre roughly hereâ indicator (e.g. circle radius = accuracy).
Optionally snap the userâs position to the nearest path or nearest sculpture when theyâre within a certain distance. Thatâs a UX trick: youâre acknowledging that the exact GPS coordinate is fuzzy and instead projecting them to a discrete point that makes sense for your map.
5. If you truly need high precision: GPS alone is not enough
For a small offline map, if you need sub-meter or 2â3 m reliable precision, you wonât get it on regular phones with only GPS, especially offline and near structures.
Real alternatives (if this were a production problem):
BLE beacons / UWB anchors indoors.
QR / NFC markers near sculptures that the user scans to âlocateâ themselves.
Letting the user manually mark their approximate location on the map as a reset.
Thatâs beyond Expo Location and outside pure code solutions.
Summary
Your device isnât âbrokenâ; youâre just seeing normal GPS error at a very small scale.
The combo of BestForNavigation, high-frequency updates, very strict accuracy filter, and weak smoothing makes the jitter extremely visible.
Use:
Less aggressive watchPositionAsync settings,
Realistic accuracy + movement thresholds,
Stronger smoothing,
A larger arrival radius, and
UI that communicates âapproximate locationâ, not exact centimeters.
You canât make GPS behave like a laser pointer, but you can make the experience look stable and usable for an offline sculpture map.
