Appearance
Ground Control Points
A survey deliverable is not just a point cloud — it is a point cloud with a stated accuracy. Lidarvisor lets you upload the control points you measured on the ground, compares them against your point cloud before you process anything, optionally corrects the cloud to sit on them, and puts the resulting accuracy figure on your project report.
The comparison is always free and runs automatically. Correcting the cloud is an optional processing step.
What Are Ground Control Points?
Ground control points (GCPs) are marks whose position and elevation you measured on the ground — typically with a GNSS rover or a total station. Because they were measured independently of the flight, they are the reference you check the LiDAR data against.
Lidarvisor uses them for three things:
- Checking — how far does the cloud sit from your survey, point by point?
- Correcting — optionally moving the cloud so it sits on your points, before any terrain model, contour, or vector is derived from it.
- Reporting — a computed accuracy statement in the project report, in the form a client's surveyor expects.
Importing Control Points
When and Where
Control points are uploaded with your project. In the Create a project panel, tick "Add ground control points (optional)" and pick your file. Uploading them at creation is what lets the check run before you decide how to process — you choose whether to pay for a correction with the error in front of you instead of guessing.
Control points are free: importing them and checking against them never costs credits, and your own survey data is never treated as a paid deliverable. The point cloud itself is not modified by the import.
Accepted Files
One delimited text file: .csv, .txt, .asc, or .pts.
You do not need to prepare the file in any particular layout. The importer handles what survey software actually exports:
| Variation | Handled |
|---|---|
| Delimiter | Comma, semicolon, tab, pipe, or whitespace-aligned columns |
| Decimal separator | Decimal point or decimal comma |
| Header row | With or without — headerless files are read too |
| Column order | Any — including Northing-before-Easting files |
| Thousands separators and quoted fields | Read correctly (e.g., "1,520,756.705") |
| Header hidden behind a comment marker | Recognized (e.g., CloudCompare's #Label ... line) |
| Point names | Any ID/name column; unnamed points are numbered P1, P2, ... |
Instrument-native binary formats (Leica GSI, Trimble JOB, and similar) are not supported — every instrument can export delimited text, so export that instead.
Rows without three readable numbers are skipped, and the import tells you how many were.
How the Columns Are Read
The importer works out which column is which — and then shows you what it understood rather than committing silently.
Column names help (English and French vocabularies are recognized: Easting, Northing, Elevation, X, Y, Z, Nord, Altitude, and so on), but names alone cannot catch the most common failure: a headerless file with Northing before Easting, which reads as plausible coordinates in the wrong place. So the deciding test is your point cloud itself: a candidate reading either drops the points inside the cloud's footprint or it does not. That one test catches transposed axes, a wrong coordinate system, and wrong units.
After the import you get a confirmation stating how many points were read and which column was taken as ID, X, Y, and Z. If the reading could not be confirmed against the cloud — or two readings fit equally well — you get a warning explaining exactly what was found, so a wrong axis order never rides silently into an accuracy figure.
Quality columns that sit next to the coordinates (X_error, Accuracy_X/Y/Z, sigma, and similar) are recognized and never mistaken for the coordinates themselves.
Coordinate Systems, Units, and Datums
- Horizontal: your control points should be in the same coordinate system as your point cloud (the EPSG code you declared at upload). The cloud-footprint test catches a file in the wrong system — you get a message naming how far off the points fall, not a generic parse error.
- Units: a file in feet against a metric cloud (or the reverse) is detected and converted. When a column heading names its unit (for example
Easting_ftUS), the heading wins — this is the one case the footprint test cannot decide, because the US survey foot and the international foot differ by only a few meters over a whole site. Elevations follow the Z column's own heading, never the horizontal unit: a file with US-survey-foot coordinates and meter elevations — a real configuration — converts nothing it should not. - A coordinate system declared in the file itself is read. Many packages (CloudCompare among them) write the full coordinate system on the first comment line of the export. Lidarvisor reads both halves: the horizontal system, and — importantly — the vertical system (the datum your elevations are measured from, such as NGF-IGN69 or NAVD88).
Vertical datums are declared, never transformed. Lidarvisor does not apply geoid corrections silently. When your file states its vertical datum, a common offset between survey and cloud can be attributed with confidence. When neither the cloud nor the points declare one, the check still measures the spread of the differences, but it refuses to call a common offset an "error" — it may be a datum difference — and the report says so. A genuine datum mismatch is flagged for you to fix at the source.
The Preliminary Check
What It Is
Shortly after your point cloud finishes uploading, Lidarvisor automatically compares every control point against the cloud. No classification exists yet at that moment, so the ground around each point is estimated from the raw cloud: a small plane is fitted through the nearby returns and evaluated at your point's exact position, so a slope does not bias the reading.
This early figure is always labeled "Preliminary, from the unclassified cloud". The final figure, measured after processing against properly classified ground, is labeled "Measured after processing". They will differ by centimeters, and they are never presented as the same number.
The preliminary check has one job: to tell you whether aligning is worth paying for, before you press Process.
In the Viewer
Your control points appear as a "Control points" entry in the project tree and as large pink markers in the 3D viewer, each placed at its surveyed position and elevation. Because the marker sits where you measured, a pin floating above or below the cloud surface is the vertical difference made visible.
The Control Points Panel
Click the control points button on the "Control points" row in the project tree to open the panel. It docks along the bottom of the viewer, so the map stays visible while you read the numbers.
The Headline
The panel leads with one sentence:
Your cloud sits X from your survey, somewhere between low and high, on N control points.
- The figure is measured honestly: every point is predicted by a correction computed without it, so no point ever marks its own homework.
- The range beside it says how precisely that figure can be known from your number of points. On a handful of control points, the range is wide — that is a fact about the survey, not about the software. When the numbers cannot support a firm conclusion, the panel states the numbers and does not manufacture a verdict.
When the differences have a shape no whole-cloud correction can fix, the headline is followed by: "A correction is not the right fix here. See the detail below."
The Correction Options
Expand "Correction options" to see what each possible correction would achieve, each measured the same held-out way:
| Option (as shown in the app) | What it does to your data |
|---|---|
| Leave it alone | Your cloud is delivered as it was measured. |
| Shift (default) | Moves the whole cloud up or down. Nothing inside it changes. |
| Shift and tilt | Also corrects a lean. Distances and angles are preserved, but slopes and drainage directions change. |
| Match every control point | Warps the cloud locally. Nearby features move by different amounts and internal geometry is not preserved. |
Each row shows its Expected accuracy, a Could be range (95% confidence), and What it does to your data. Click a row to choose that correction yourself; left alone, the default is the Shift — the one correction that cannot change the shape of your data.
Things the table tells you honestly:
- An option that would probably make your cloud worse than leaving it alone says so on its row.
- "Match every control point" only acts near your marks and fades to nothing away from them, so its figure is measured beside the marks, and what it does between them is stated on the same row. If it would leave the cloud worse between your marks, it is not suggested.
- Options that cannot be trusted on your number of points are grayed out with the reason. The Shift works from a single point; the tilt and the warp need at least 7 usable points.
- If no correction is appropriate at all, the table says: "No correction is offered for this survey: the shape of the differences says a correction would not be the right fix."
- If "Align to control points" is not ticked in the processing options, the table warns you that picking a row will not run anything until it is.
The Point Table
Expand "The N points" to see every control point, one per row: Point, Surveyed Z, Cloud Z, Difference, Status, and Use. Every column sorts. The footer counts read, for example, "12 used · 2 excluded" — used points are the ones that feed both the correction and the accuracy figure.
- Surveyed Z is the elevation you measured. Lidarvisor never changes it.
- Cloud Z is the cloud's elevation at that exact spot, interpolated from the ground around it.
- Difference is Surveyed Z minus Cloud Z: positive means the cloud sits below your measurement.
Point Statuses
A point that cannot be measured fairly is excluded from every figure and every correction — individually, with its reason in the Status column. It never fails the whole set.
| Status (as shown in the app) | Meaning |
|---|---|
| Compared | Measured normally and included in the figures. |
| Outside the data | The point falls outside the point cloud. |
| Outside your area of interest | The point falls outside the area you asked to process. |
| Too few ground points nearby | Not enough ground around the point to measure against — common under dense vegetation. |
| Ground is not flat enough here to measure against | The surface is too uneven for a reliable reading. |
| A kerb or edge is within reach — the ground here cannot be measured | A break in the surface (curb, step, bank) would bias any elevation read there. |
| Sits above the local ground — on a structure? | The cloud here is well above your point: probably a roof, a vehicle, or canopy. |
| Disagrees by more than any survey error — check units and datum | Far too large to be a survey error — usually a unit mix-up or a typing mistake. |
| Metres from the rest of your survey — check this mark | This mark disagrees by an amount the other marks rule out: a moved target, a transcription error, a wrong antenna height. It is shown, and kept out of every figure. |
| You excluded this point | Your own decision — see below. |
Use and Exclude
Each measurable point carries a Use / Excluded toggle:
- Use — the point counts, in both the correction and the accuracy figure.
- Excluded — the point is ignored entirely. Use this for a point you know is wrong: a blunder, a target that moved, a feature that was not what you thought. Not for a point you simply do not like.
Points the check itself rejected display as excluded and cannot be toggled — including them would change nothing, since they reach no figure either way.
Seeing the Ground Under a Point
The table says a point is out by some amount, or that the ground there cannot be measured — and you should not have to take either claim on trust. Click the ground icon on any row to cut two cross-sections through that exact mark — one north to south, one east to west, each about 10 meters long — using the same profile tool you use everywhere else in the viewer.
Your surveyed point is marked on the section, at its surveyed elevation, so you can see at a glance whether the point sits above the ground, below it, or on a curb the estimator refused. The viewer zooms to the sections, and clicking the row again reopens them rather than cutting duplicates.
Exporting the Residuals
The download button in the panel header exports the per-point residuals as a CSV — point name, surveyed and cloud elevations, difference, role, and status, with a header stating the stage and the sign convention.
The "What am I looking at?" button opens a built-in explanation of every column, figure, and status.
Correcting Your Cloud
The Processing Option
"Align to control points" is a processing option in the left panel, alongside the other deliverable choices. When your project has control points, the box comes pre-ticked — visibly, before you press Process — and unticking it sticks. Alignment uses processing credits like other optional outputs; the accuracy check itself is always free.
Under the checkbox, a summary states exactly what the next run will do — for example, that it will try a vertical shift only and keep it only if it improves the measured accuracy — with an "Open the control points" link to the panel where you can pick a different correction.
What Actually Runs
Two things decide everything: the checkbox, and the correction selected in the panel.
| You did | What the run does |
|---|---|
| Ticked the box, touched nothing else | Tries the default Shift. If it measurably improves the cloud, it is kept; otherwise your cloud is delivered exactly as measured. |
| Ticked the box and picked a correction | Applies your pick — subject to the same safety rule. |
| Unticked the box | The cloud is never moved. The check still runs and the report still carries the figures. |
The one rule: no correction ever ships that measures worse than doing nothing. Before the cloud is touched, the chosen correction is re-measured on classified ground, each point predicted by a fit that did not use it. If it fails that test — even if you picked it explicitly — it is dropped, the cloud is delivered uncorrected, and the report states that a correction was fitted and rejected. On a scattered survey, this is the honest outcome: ticking the option correctly does nothing.
A shift of a meter or more is almost always a vertical datum mismatch rather than a data problem. Check the vertical datum of your file and of your cloud before aligning, or the mistake gets baked in.
Where the Correction Happens
The correction is applied inside the processing pipeline, before anything is derived — so the terrain models, contours, breaklines, vectors, tiles, and reports all come from the corrected cloud natively. There is no second cloud to reconcile and no re-tiling. Your raw uploaded file is never modified.
Changing the decision later means reprocessing the project.
After Processing
- The check is re-measured against classified ground — the figure labeled "Measured after processing" — and that is the figure that reaches the report. Where the classification allows it, accuracy is also reported separately over vegetated and non-vegetated ground.
- Control points freeze once they have been used to align the cloud. The panel shows what was applied and the measured result, the correction table is gone (choosing a correction for an already-corrected cloud has no meaning), and the Use/Excluded toggles lock: "This set was used to align the cloud. Reprocess the project to change it."
The Accuracy Statement in Your Report
When control points could be compared, the project report gains an "Absolute accuracy" section. When there are none, the section is simply absent — never a placeholder, never an invented value.
What the section contains:
- A formal accuracy statement following the ASPRS Positional Accuracy Standards for Digital Geospatial Data, 2nd Edition (2023) — the wording a client's own surveyor will recognize. It reports the measured vertical accuracy (RMSEz), names the number of checkpoints, and, where the classification allows it, reports accuracy separately over non-vegetated (NVA) and vegetated (VVA) terrain.
- Honest wording about independence. If your points were used to correct the cloud, they cannot also serve as a fully independent check of it — so the statement says the figure was measured a different way: each control point compared against a correction calculated without it. The report never claims a test that was not performed.
- The full statistics: smallest, largest, and median difference, mean, standard deviation, and the RMS with its 95% range. On few points, the RMS is labeled indicative.
- A per-point table — the residual at every checkpoint, so a reader can see which point drove the figure and take it to the field.
- Every excluded point, with its reason — a section that compares 18 of 22 points and reports 22 would be misstating the test.
- What was done to the cloud, in plain terms: whether it was raised or lowered and by how much, shifted and tilted as a rigid block, or warped to meet the control points — and, for a warp, how far beyond the outermost points it reaches before the cloud is left untouched. If a correction was fitted and then rejected, the report says that instead — silence would read as "the option did nothing."
- Cross-sections of flagged points — the ground around each point the check rejected, so the rejection can be verified rather than trusted.
Next Step
The accuracy statement is one part of the full project deliverable. See what else is in it: head to Reports.