4 min read
EarthRay, a test bench for stated accuracy
EarthRay anchors the Earth’s graticule, latitudes and longitudes included, around whoever is holding the phone. The first lesson from the project is not about 3D, but about what an accuracy figure is worth once it leaves its context.
Since September 2026 I have been building my own augmented reality application, EarthRay. It draws the Earth’s graticule where it actually is: the user’s meridian and parallel run under their feet, the equator disappears below the horizon, the tropics and the polar circles cross the ground thousands of kilometres away. The grid is geo-anchored. It does not follow the screen, it stays put as you walk.
The object is educational. The professional interest lies elsewhere. An application like this forgives no approximation in orientation: three degrees of heading error and the North Pole is somewhere else. The fault is not open to discussion, it is visible. It is an honest test bench for what we usually claim about accuracy.
What the field answered
The application orients itself with ARCore’s Geospatial API, which corrects the phone’s pose by matching the camera image against Street View imagery of the place. Without usable coverage, it falls back on the magnetic compass, whose error easily runs to tens of degrees among buildings.
One test outing, seven sessions in the same street, less than fifty metres apart, the same afternoon, with the same phone: only one came down to 1.65° of heading uncertainty, checked against the position of the sun. The other six stayed between 10 and 26°.
The hardware explains none of that spread. What changes from one session to the next is what the camera had in front of it: façades surveyed by Street View, or sky, vegetation and a bare wall.
An accuracy figure out of context commits to nothing
The service documentation states a heading accuracy of about one degree. It is correct. It describes the case where visual localisation succeeds, and that case depends on something nobody controls from their desk: the photographic coverage of the street.
On a project, the same sentence comes back in the specification in a more polished form: centimetre positioning, heading to the degree. It commits to nothing until you have written next to it under which conditions that figure is reached, how often those conditions hold over the work area, and what the system does when they do not.
It is the third point that gets left out, and it is the one that costs. A degraded mode nobody planned for becomes a degraded mode nobody detects, and the positions it produces enter the reference dataset carrying no mark of their quality. Years later, nothing tells them apart from the good ones.
EarthRay therefore shows its pose source and its uncertainty at all times, and logs every session. Not out of transparency towards a user who does not care, but because a system unable to say how sure it is of itself cannot be relied on.
What plays out below the surface
Three decisions shape everything else, and none of them is visible on screen.
The geodetic computation is held in double precision and kept separate from the rendering engine. The semi-major axis of the WGS84 ellipsoid is 6 378 137 m: at that distance from the origin, a 32-bit float, the standard format of 3D engines, resolves no better than the metre. The scene is therefore built relative to the observer. This is the trap a GIS runs into when asked to stack projected coordinates inside a tool designed for scenes a few hundred metres across.
The receiver’s altitude is a height above the ellipsoid, not above the ground. In France, the gap to the geoid runs to tens of metres. A grid placed at the stated altitude floats or sinks: it is anchored on the plane detected by the camera.
Finally, the geodesy module does not depend on the engine: it can be verified without a phone. Twenty-three unit tests are replayed on every change pushed. On a subject where the error is silent, that is the only way to know a transformation is still correct after being reworked.
Where the project stands
The mathematical core and the graticule rendering are validated on device. Continuous integration replays the tests on every change and builds the application on demand. The signed package for release is produced with a single command, and the store listing is in preparation.
This is not a client engagement and this note does not claim to be one: it is a personal project, in progress, whose lesson I am publishing because it applies as-is to the projects I support. The best place to test an accuracy assumption remains a system where the error becomes visible.