Ask a scanning provider how accurate their scanner is and you will get a number off the specification sheet. Ask how accurate your finished deliverable will be and you should get a longer, more careful answer.
This article does not quote a single accuracy figure, because any figure quoted in isolation would mislead you. What matters is understanding where accuracy comes from, what erodes it on site, and how it gets proven. Once you understand the chain, you can ask a provider the right questions and read their answer properly.
What the specification sheet actually tells you
Manufacturers publish accuracy figures measured under stated conditions: a defined range, a cooperative target, and a controlled environment. Those figures are real and they are useful for comparing instruments.
What they describe is the performance of a single measurement, to a single point, in near-ideal conditions. Your site sits below that ceiling. Every condition that differs from the test environment moves you further from it, and the finished deliverable passes through several more steps before it reaches you.
Accuracy is a chain, not a number
There are four distinct things people mean when they say scan accuracy, and they compound:
- Range and angular accuracy. How precisely the instrument measures to one point. This is the specification figure.
- Registration accuracy. How well the separate scans are stitched into one cloud. Error accumulates across the links between scans.
- Georeferencing accuracy. How well that cloud is tied into the project control network and the correct datum. This step inherits whatever error already sits in the control.
- Deliverable accuracy. How accurate the thing you actually receive is, whether a surface, a set of feature strings, or a model. The extraction step adds its own uncertainty on top.
The final result is governed by the weakest link. A high-specification scanner tied to poor control produces a poor deliverable, and the brochure figure will not save it.
That third link is the one that catches projects out. The scan cannot be more accurate than the control it is referenced to.
What erodes accuracy on site
Real conditions pull the result away from the laboratory figure:
- Range. Accuracy falls away with distance. A point measured across a wide site is not as well defined as one measured close in.
- Incidence angle. A laser hitting a surface at a glancing angle spreads the return across a larger footprint, which blurs the position of that point. Scanning a long floor or wall from one end produces exactly this.
- Surface reflectivity. Dark, wet, polished, or transparent surfaces return weak or scattered signal. Wet asphalt, glass, and dark steel are all harder to measure than a clean concrete wall.
- Edges. A pulse landing on the edge of an object returns energy from both the object and whatever sits behind it, which produces noise along every edge in the cloud.
- Movement. Traffic, plant, and people walking through the scene during a scan all leave artefacts.
- Atmosphere. Heat shimmer over a hot pavement, dust, rain, and fog all degrade returns.
None of these appear on a specification sheet, and together they matter more than the difference between two competing instruments.
Registration drift, the quiet error
Every scan-to-scan link carries a small error. Chain fifty scans down a tunnel or along a corridor, and those small errors compound into a real one at the far end.
Registration by cloud-to-cloud matching, where software aligns overlapping geometry, is quick and convenient. It also drifts on long chains, and it struggles in featureless spaces such as a straight tunnel or a bare corridor where each scan looks much like the next.
Target-based registration and, better still, tying scans to surveyed control targets along the route, stops that drift from accumulating. On a long or high-tolerance job, this is the difference between a cloud that holds and one that quietly bends.
Mobile capture adds links to the chain
The same logic applies to mobile LiDAR, with more links in the chain. A moving sensor’s position comes from GNSS and an inertial unit, and the accuracy of that computed trajectory feeds straight into the accuracy of every point captured. Where the sky view is poor, the trajectory degrades, and so does the cloud. Ground control along the route is what keeps it honest.
How accuracy is actually proven
Not by the brochure. By independent checkpoints.
A checkpoint is a point of known coordinate that was not used in the registration or georeferencing. Comparing the cloud against those points gives the achieved accuracy of the job in front of you, under the conditions it was captured in. That comparison is what should be reported, and a provider who verifies and reports it is telling you something the specification sheet never could.
What to ask your provider
- What accuracy do you commit to for this deliverable, not for the instrument?
- How will the cloud be georeferenced, and to what control?
- How is registration controlled on long runs?
- How will the achieved accuracy be verified, and will you report the checkpoint results?
- Does your accuracy statement cover the point cloud, or the model extracted from it?
Clear answers to these five questions tell you far more than any instrument comparison.
Match the accuracy to the purpose
Over-specifying costs money for no benefit. A visual record of an existing structure has a very different accuracy requirement to a model that will drive fabrication or clash detection. Setting a tolerance the deliverable does not need means paying for scan density, control, and processing that nobody will use.
Decide what the data must do, then set the accuracy target from there.
The bottom line
The honest answer to how accurate laser scanning is: as accurate as the weakest link in the chain from instrument to control to deliverable, verified against known points, and stated in writing.
Good 3D laser scanning is a controlled process, not a single instrument reading. To talk through the accuracy your project actually needs and how it will be proven, get in touch with our team.