GPS is a distribution not a position

GPS is a distribution, not a position

navigator.geolocation hands you a latitude, a longitude, and an accuracy radius. Two of those three are a polite fiction. The device does not know where it is; it knows where it probably is, and it is summarising a probability cloud into a single point because that is what the API signature demands.

Most of the difficulty in outdoor AR comes from taking that point literally.

What the reported point actually is

A GNSS fix is the solution to a system of range equations with more error terms than most people expect: satellite geometry, ionospheric delay, multipath off the building you are standing next to, and the receiver's own smoothing. The accuracy field is a radius within which the true position probably lies — not a bound, and not a guarantee. Altitude, when reported at all, is typically worse than horizontal by a meaningful factor, which is why serious outdoor AR treats height as a channel to be inferred rather than trusted.

None of this is a defect. It is a receiver doing something genuinely hard, well. It just means the number is a sample from a distribution, and the right question is not "where am I?" but "what does this sample tell me about a thing I am estimating?"

The thing you are actually estimating

In an AR session you have two coordinate systems.

One is the local frame: the tracking space the WebXR runtime gives you. Its origin is wherever the session started; its orientation is wherever the phone happened to be looking. Within it, your pose is known extremely well over short intervals — visual-inertial odometry is very good at "how did I move in the last two seconds", which is precisely what GNSS is bad at.

The other is the world frame: latitude, longitude, altitude.

What you need is the transform between them. That transform is a small, fixed-ish quantity — a translation and a heading — and every GPS reading is a noisy measurement of it, taken from a different vantage point in the local frame. Which reframes the whole problem. You are not tracking a position; you are estimating a transform, and each reading is evidence.

This is why the estimate improves as the user walks and does not improve while they stand still. Twenty readings from the same spot mostly tell you about the receiver's noise. Twenty readings taken along fifteen metres of walking constrain the heading, because only some rotations make the shape of your GPS track agree with the shape of your odometry track. Motion is information.

What that means for the numbers you can quote

The honest formulation splits into two claims, because they behave differently:

• Global placement is GPS-accurate. No amount of odometry invents absolute accuracy that GNSS never provided. Sub-metre in representative outdoor conditions — good enough to put a label on a bench, not good enough to put it on a specific slat.
• Local stability is what fusion actually buys. Once the transform is estimated, a placed object stops moving relative to the world, because small corrections are applied to the transform rather than to the object. This is the part users perceive as "solid", and it is why "sub-metre" and "rock steady" are not in tension.

The temporal qualifier matters too, and it deserves more care than it usually gets. Short rules of thumb circulate — "give it fifteen seconds" — and this project's own corpus is less flattering than that: measured across 51 recordings, the median time to come within a metre of the estimate's own final answer was closer to two minutes. The two numbers are not measuring quite the same thing, which is exactly why quoting either one loosely is a bad habit — the measurement piece sets out what each one covers.

What is safe to say: before you have moved, you are watching an estimator with insufficient evidence do its best, and it improves as you walk.

Design consequences

Treating GPS as a distribution changes what you build:

• Do not snap to readings. Refine the transform; leave the content alone. A user who sees content jump has learnt that your app is guessing.
• Reject outliers rather than averaging them. One multipath reading off a glass façade can be tens of metres out, and a mean is not robust to it.
• Bootstrap from a median, not a mean. When placing a new anchor from live readings, the median of a handful of samples is dramatically better behaved.
• Prefer relative claims in your UI. "12 m ahead" degrades gracefully; "you are here, exactly" does not.
• Give the estimator a reason to improve. An onboarding step that gets the user walking a few metres is not a gimmick — it is data collection.

The uncomfortable part

There is a failure mode no amount of fusion removes: the user who opens your experience, stands still under a balcony, and judges it in the first three seconds. They are sampling the estimator at its worst moment, and the architecture cannot argue with them.

You handle that with product design rather than mathematics — an onboarding that moves them, an indicator that is honest about confidence, or a printed marker that gives you an accurate fix from the first frame. What you should not do is claim a precision the distribution does not contain.