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, and like every processing option it adds nothing to the credit cost.
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 correct the cloud 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. So are columns of estimated or computed values (named for example Z_est, estimated or computed) when the surveyed column sits beside them.
Coordinate Systems, Units, and Datums
- Horizontal: the importer first reads your points in the coordinate system of your point cloud, then in the system the file itself declares, then as WGS84 longitude and latitude, and keeps the reading that places them on the cloud. The panel says which one it used (for example "Read as WGS84 longitude and latitude (EPSG:4326), not the project's system."). Emlid exports are read from their coordinate system column, or from their longitude, latitude and ellipsoidal height when the Easting and Northing columns are empty.
- When no reading places the points, the panel says where they land instead (for example "Your points land 3.2 km north-east of the point cloud. Is this the right point cloud?") and asks "Which coordinate system is this file in?", with a Choose a system picker. Nothing is blocked while you decide.
- 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 control points all sit about the same distance from the cloud (half a metre or more), the check tests the usual vertical datum confusions at your site itself: ellipsoidal heights against heights above the geoid, NAD83(2011) against ITRF2014 / WGS84, the global EGM2008 geoid against a national hybrid geoid, GEOID18 against GEOID12B, US survey feet against international feet, and an antenna height left in the survey heights. See A Constant Offset below for what happens next.
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 it, before you press Start Processing.
While it runs, the panel says "Checking your control points against the point cloud...". If it did not finish, the panel says so and offers Try again; if your points have not been checked yet, it offers Check now. The Measure again button in the panel header runs the check again at any time before processing.
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 needs at least 3 usable points, Shift and tilt at least 5, and Match every control point at least 7.
- 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.
A Constant Offset
When your points all sit about the same distance above or below the cloud, a correction table would be the wrong answer, so the panel explains the offset instead:
- A known datum confusion matches. The panel names the two systems (for example, "Your cloud has ellipsoidal heights and your survey has heights measured from the geoid"), gives the predicted and measured differences, and tells you to export both with the same datum and upload again. The cloud is never corrected for a datum mismatch: the mistake would be baked into it.
- No datum confusion matches, and the offset is 10 m or less. The panel says it is not a datum mix-up and names the likeliest cause: a GNSS base station set up on its own autonomous position, which moves every point by the same amount. You can then choose Move my cloud by X to match my control points. This moves the whole cloud up or down and changes nothing else; it corrects height only and does not certify your survey, because the points that set the shift cannot also test it. With few usable points, the panel also warns that it cannot tell whether the cloud is tilted. You can Withdraw my agreement at any time before processing.
- Larger offsets, or a site where the datums cannot be tested, are treated as a datum difference, and no correction is applied.
Your agreement can only be given before the project is processed. At run time, the agreed shift is applied only if the offset measured on the processed cloud is still close to the one you agreed to (within 10 cm, or 10% for large offsets); otherwise the cloud is delivered as measured, and the panel says why.
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 Start Processing, and unticking it sticks. Like every processing option, it adds nothing to the credit cost, and the accuracy check itself is always free.
Under the checkbox, a summary states exactly what the next run will do: it will try a vertical shift only and keep it only if it improves the measured accuracy, that it will use the correction you picked, that it will move the cloud by the shift you agreed to, that a constant offset needs your agreement first, or that no whole-cloud correction can fix the shape of the differences, with an "Open the control points" link to the panel.
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 (with at least 3 usable points). 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. |
| Ticked the box and agreed to move the cloud by a constant offset | Applies that shift only if the processed cloud's offset still matches the one you agreed to. |
| Points show a datum mismatch, or a constant offset you did not agree to move | The cloud is delivered as measured. |
| 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 large constant offset is usually a vertical datum mismatch rather than a data problem. The check tests the usual confusions for you (see A Constant Offset); fix a datum mismatch at the source rather than aligning it away.
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.
The decision is made once: a project is processed once, so nothing changed in the panel afterwards can reach the delivered cloud.
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.
- One line says what the run did. Under Processing completed, the left panel reads "Control points: corrected." or "Control points: delivered as measured, see the control points panel.", and the panel gives the full sentence: corrected to your points, delivered as measured because no correction was requested or you chose none, or a correction computed and rejected because it made the cloud worse, with the reason.
- Control points freeze once the project has been processed, whether or not they were used to align the cloud. The panel becomes a record: the correction table is gone, the Use/Excluded toggles lock, and it reads "This project has been processed. These control points are the record of what was delivered."
The Accuracy Statement in Your Report
When your project has control points, or alignment was requested, the project report gains an "Absolute accuracy" section. If none of the points could be compared against the cloud, the section says so rather than inventing a value. A project with no control points has no such section.
When the cloud was moved by a constant offset you agreed to, the section is titled "Control points" instead and carries no accuracy statement: it opens by saying the cloud was shifted vertically at your explicit request, and the RMS it gives is a cross-validated residual, labeled indicative below 30 points. In every other case, it 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.