Guest perspective by Winston Wen, founder and CEO of Tersus GNSS
Walk the floor at any geospatial conference this year — Geo Week included — and you will see the same demo: a handheld scanner sweeps the booth, a dense, colorful point cloud blooms on a screen, and someone says “look how accurate.” The cloud is thick, the colors are vivid, the crowd nods.
Almost nothing in that sentence is right — because “accurate” is doing the work of three different numbers, and the demo has shown none of them.
I run a company that makes these scanners, so consider this a confession as much as a complaint. Our industry — vendors like mine included — has let one comfortable word blur three measurements that behave completely differently in the field. That blur has consequences: procurement specs that no instrument can be tested against, deliverables that get disputed because client and contractor were quoting different numbers, and rework that a ten-minute conversation would have prevented.
The three numbers
Relative accuracy is internal consistency: if two doorways are 12.40 meters apart in the building, are they 12.40 meters apart in the cloud? This is the number SLAM is naturally good at, because loop closure keeps the model self-consistent. It degrades with drift — long unclosed trajectories, feature-poor corridors — and it is the number spec sheets most often quote, measured under conditions the spec sheet rarely states.
Absolute accuracy is a different question entirely: is that doorway where the ground truth says it is, in a real coordinate system? A cloud can agree with itself to a few millimeters and still sit twenty centimeters off datum, or lean a degree from vertical. Absolute accuracy does not come from the SLAM algorithm at all. It comes from anchors — RTK when the sky allows it, ground control when it does not — and it is the number most contracts are actually judged by.
Point-cloud noise is what the demo crowd is actually looking at. Scan a flat painted wall and the points do not lie on a plane; they form a fuzzy shell with a thickness — often a centimeter or two for this class of instrument, growing with range and shallow incidence angles. Noise is a property of the sensor and the geometry, not of the trajectory.
Here is the uncomfortable part: on a screen, noise reads as density, and density reads as quality. A thick, busy cloud looks more impressive than a thin, quiet one — even when the opposite is true.
These three numbers are independent. A scanner can score well on any two and fail the third. That is not a defect; it is the nature of the measurement. The defect is in how we talk about it.
The fourth thing, which is not a number at all
The newest source of confusion is 3D Gaussian Splatting. The output is spectacular — a photorealistic scene you can fly through, with reflections and lighting a point cloud could never carry. Clients love it, and they should: for walkthroughs, stakeholder presentations, and context, it is the best visualization this industry has ever had.
But a splat is a rendering optimized to look right from every viewpoint, not a measurement constrained to be right in space. Even when it is built on the same SLAM trajectory as the point cloud, the optimization rewards photographic plausibility, not metric fidelity. Quoting “sub-centimeter accuracy” on a 3DGS deliverable is a category error — like quoting the accuracy of a painting.
The honest formulation is simple: the point cloud is the measurement; the splat is the presentation. They can come from the same walk through the same building, and they should never be sold with the same number.
What the field can check, today
None of this requires a laboratory.
Noise: scan a flat wall, cut a thin section, and measure the thickness of the shell. Relative accuracy: tape two well-defined features — door frames, columns — and compare against the cloud. Absolute accuracy: withhold two or three surveyed points from the adjustment as independent check points — the distinction the ASPRS positional accuracy standards insist on — and report residuals against them. “An RMSE of 18 mm against independent check points” is a defensible sentence in a way “accuracy: 1 cm” never will be.
Each check takes minutes. The table below is the version I wish every spec sheet — and every project report — led with.
| The number | The question it answers | What degrades it | Field check |
| Relative accuracy | Is the model consistent with itself? | Drift, missed loops, degenerate scenes | Tape known distances; compare |
| Absolute accuracy | Is the model where the world says it is? | RTK pseudo-fix, weak anchors, poor control layout | RMSE on independent check points |
| Point-cloud noise | How fuzzy is each surface? | Sensor class, range, incidence angle, reflective materials | Section a flat wall; measure shell thickness |
| 3DGS output | How convincing is the picture? | Capture coverage, lighting, motion blur | Not a measurement — do not quote accuracy |
What should change
Three things, none of them difficult.
Vendors should quote the three numbers separately, each with the conditions under which it was measured, and label 3DGS outputs as visualizations — a standard my own company should be held to as much as anyone. Buyers should make “which number is that?” the first question of every demo, and ask to see the wall section, not the flyover. And professionals should write deliverable reports that name the number being claimed and show the check behind it.
Handheld SLAM is becoming a standard field tool, and it has earned that place. The technology does not need inflated language to be compelling. What it needs is for the industry to stop letting one comfortable word do the work of three honest numbers — because the professional difference between a measurement and a picture is not the hardware. It is the verification.
Winston Wen is the founder and CEO of Tersus GNSS, a Shanghai- and Melbourne-based positioning company that develops chip-level RTK engines, GNSS receivers, and handheld SLAM scanners. His team’s open 55-page field guide, “Handheld LiDAR SLAM Guidance — From First Scan to Professional Deliverable” (2026), covers the verification workflows described here.
Figure 1 — Three numbers, one word: relative accuracy (feature-to-feature consistency inside the model), absolute accuracy (the model against real-world coordinates), and point-cloud noise (the thickness of a scanned flat surface) — three independent properties that a single “accuracy” claim conflates.
