The LiDAR data arrives without context. Maybe it came with a site you bought, or with a programme handed over from a team that's been disbanded, or with a contract you took on from a predecessor. The files open in the GIS tool, the point cloud renders, the DTM looks fine. You're about to make engineering decisions on data you didn't commission and don't know the provenance of. One working day of diagnostic checks tells you whether the dataset is fit for purpose or whether you need to commission a fresh capture before going further.
If you've ever inherited a LiDAR dataset and started working with it without knowing exactly what it represents — what accuracy it actually achieves now, when it was captured, what's been classified, what's missing from the deliverable bundle — you've met the inherited-data problem. The data exists. You can open it. But you don't know what it's worth as the basis for the decisions you're about to make.
The diligence checks below take about a working day to run on a typical inherited dataset, cost nothing beyond your own time (plus modest cost if you commission a few new control point checks), and produce a clear go/no-go answer on whether the dataset is fit for your purpose or needs replacement. The cost of doing the checks is negligible against the cost of either committing to engineering work on bad data or unnecessarily commissioning a fresh capture when the inherited data is genuinely fine.
This article walks through the eight diagnostic checks that constitute the inherited-data audit, what each one tells you, the order they're sensibly done in, and the decision pattern that follows from the results.
The most important check. Survey 8-12 ground control points across the project area using independent survey (GNSS, total station) and compare the surveyed positions against the inherited LiDAR.
What it tells you. The dataset's current absolute accuracy — not what the original QA pack claimed at delivery, but what the data actually delivers against current ground truth.
How to do it. Place the new checkpoints in a mix of bare-ground, edge-of-project, and any cover types relevant to your use case. Each point costs $200-500 to survey (varies by access and operator) so the total cost is $2k-6k for 10-12 checkpoints.
What you're looking for. Residuals within the spec the inherited dataset claims to deliver. If the dataset claims ±20 mm RMSE and your independent checks show ±60 mm, the data has drifted (or never was at spec) — re-evaluate.
(See residuals article for what residual patterns reveal beyond the single RMSE number.)
Look up the capture date in whatever metadata accompanies the dataset and compare against site change history.
What it tells you. Whether the dataset represents current site state or past site state.
How to do it. Check current aerial imagery (Google Maps, Bing Maps, state aerial photo services, Nearmap if available) against the inherited DTM/DSM. Look for new construction, demolition, vegetation regrowth, earthworks, infrastructure changes.
What you're looking for. Material changes since capture date. Vegetation growth, building additions, earthworks. If the use case requires current state, age may disqualify the dataset regardless of original quality.
Spot-check the classified point cloud. Sample 50-100 points from each class and verify the classification is correct.
What it tells you. Whether the classification labels match reality and how the dataset will behave for downstream classification-dependent work.
How to do it. Open the cloud in CloudCompare, ArcGIS Pro, QGIS or similar. Filter by class. Visually inspect random samples. For ground class, also check that ground is being identified under canopy where canopy exists.
What you're looking for. Misclassified points (buildings labelled as vegetation, ground points labelled as low veg, etc.). Patchy or sparse classification under canopy. Missing extended classes if any are expected.
(See quality vs speed classification article for what classification quality tiers typically look like.)
Generate a density raster from the inherited cloud (most LiDAR tools have this built in) and check that density is consistent across the project area.
What it tells you. Whether the capture is spatially uniform or whether some areas (perimeter, specific zones) have substantially lower density that affects deliverable quality.
How to do it. Density raster at 1 m or 5 m resolution. Render with colour-coded thresholds. Look for systematic patterns — perimeter zones sparser than interior, specific azimuths sparser than others, large patches with very low density.
What you're looking for. Edge effects (see edge effects article); density that varies more than 30% across the project; ground-return density that drops sharply under canopy.
From whatever metadata accompanies the dataset, work out what was done to it.
What it tells you. Whether the dataset has been processed in ways that affect your intended use — hydro-enforced or not, classification method, software versions used, ground extraction approach.
How to do it. Read the LAS header (which can encode processing software metadata), examine any manifest or QA pack included, look for breaklines or hydro-enforcement features in any included vector deliverables.
What you're looking for. Documented hydro- enforcement if your use case needs it. Specific classification software (TerraSolid, LP360, etc.) and parameters if you're trying to match the processing in subsequent work. Date and version of the processing if you're considering re-processing.
(See pre-built vs custom pipelines article for what processing decisions to look for.)
Confirm the coordinate system the dataset is actually in, and validate that any transformation to your target system has been applied correctly.
What it tells you. Whether you're working in the datum you think you're working in, and whether transformations introduce errors.
How to do it. Check the LAS header VLR for CRS information. Check any included PRJ sidecar file. Cross-check against the source metadata documentation. Open in a tool of known coordinate-system behaviour and see if the data lands where it should.
What you're looking for. Consistent CRS declaration across all deliverable components; match between declared CRS and actual data position (rough verification against any known location); GDA94 vs GDA2020 distinction preserved.
(See coordinate transformations article for the failure modes here.)
List what's in the deliverable bundle. List what should be in a complete deliverable. Identify the gaps.
What it tells you. Whether the inherited bundle is a complete deliverable or a subset of one — and what the gaps mean for your use case.
How to do it. Compare against the 10-section QA pack standard (see QA report article) and the complete-deliverable checklist for your project type. Missing items don't necessarily mean the data is bad; they mean documentation is incomplete.
What you're looking for. Missing QA pack sections, missing manifest, missing classification documentation, missing accuracy report, missing processing-chain documentation, missing raw archive references.
If the dataset was originally produced by an operator who's still operating, check whether the raw archive (RINEX, sensor logs, trajectory) is still available.
What it tells you. Whether re-processing is an option if the inherited dataset turns out to need it.
How to do it. Contact the original operator (if identifiable from metadata) and ask. Get a documented yes/no answer plus retention timeline.
What you're looking for. Available archive gives you reprocessing flexibility; unavailable archive means any future change to the deliverable requires re-capture.
(See re-fly decisions article for what the archive specifically enables.)
The eight checks produce a decision tree:
All eight pass cleanly. Inherited dataset is fit for your purpose. Proceed with engineering work; document the validation in your project record so subsequent users can rely on it.
1-2 checks marginal, rest pass. Likely fit for purpose with caveats. Document the marginal items; constrain downstream use accordingly (e.g., don't use for sub-millimetre work if accuracy validation showed ±50 mm).
Currency check fails. Site has changed materially. Inherited dataset describes the past; re-capture needed for current state. Inherited data may still be valuable as the historical baseline.
Accuracy validation fails. Dataset isn't performing at claimed spec. Two options: re-process if archive is available and gap is explainable (e.g., outdated control); re-capture if not. Don't proceed on engineering decisions against the inherited data.
Multiple checks fail. Inherited dataset isn't fit for your purpose. Re-capture is the honest answer. Inherited data may have residual value (historical baseline, vegetation reference) but shouldn't drive current engineering.
Three common inherited-dataset patterns:
You buy a development site; the vendor supplies LiDAR commissioned during their due diligence. Typical inherited-data characteristics:
Validation focus. Accuracy check, currency check, manifest gap analysis. Often the right answer is "use as broad context, commission fresh for design work".
You access free or licensed LiDAR from a council or state geospatial portal. Typical characteristics:
Validation focus. Currency check, density consistency for your specific AOI, classification adequacy for your use case. Often fit for planning work, not for engineering.
(See hyper-local terrain article for the regional-data decision framework.)
Your team inherits an ongoing capture programme from a predecessor team. Typical characteristics:
Validation focus. Processing-chain consistency across cycles (do they compare validly?), operator continuity (same operator across cycles?), archive accessibility, gap analysis.
(See multi-year vendor relationships article for what to look for in long-running programmes.)
Three patterns we see when inherited datasets are used without proper validation:
Assuming the QA pack claim is current truth. The inherited dataset claims ±25 mm RMSE; you trust it; downstream work fails because the actual accuracy is ±60 mm against current control.
Skipping currency check. Dataset is two years old; site has been substantially redeveloped; engineering work proceeds against the old data; construction discovers the data is stale and re-baselines mid-project.
Treating absence of QA pack as 'data is fine'. The deliverable lacks documentation; nobody can say what's been done; default assumption is "must be okay since it's been used before"; the unverifiable claim becomes an assumption that fails when tested.
data
The diligence pattern:
The discipline of running the validation explicitly is the difference between data that supports engineering decisions defensibly and data that's just convenient.
Inherited LiDAR datasets — from site purchases, programme transfers, council/state acquisitions, or contract changeovers — arrive without the context that lets you trust them for engineering decisions.
Eight diagnostic checks form the inherited-data audit: independent control validation (most important; $2-6k for 10-12 checkpoints), capture age vs site change, classification quality audit, density consistency, processing- chain reverse-engineering, datum and projection verification, manifest gap analysis, archive accessibility check.
The eight checks take one working day. Cost is negligible against the cost of either using bad data for engineering decisions or unnecessarily re-commissioning when inherited data was fine.
Decision pattern: all eight pass = use; 1-2 marginal = use with documented caveats; currency fails = re-capture for current state; accuracy fails = re-process if archive available or re-capture; multiple fail = re-capture.
Three common inherited-data patterns: site purchase with vendor LiDAR (often fit for context not engineering), council/state acquisition (often fit for planning), programme transfer between teams (validate continuity between cycles).
Three common mistakes: trusting the QA pack claim without current validation, skipping currency check, treating absence of QA pack as evidence the data is fine.
The diligence discipline distinguishes data that defensibly supports engineering from data that's just convenient. Always validate before committing.
If you've inherited a LiDAR dataset and want a structured validation before committing to engineering work on it, send through the dataset metadata. We'll run the eight diagnostic checks and produce a documented fitness-for-purpose report — typically a working day's worth of analysis, output is a clear go/no-go on whether to proceed with the inherited data or commission fresh.
The interpretation guide for what your validation residuals are telling you. Useful prerequisite for understanding the accuracy validation step in this article.
The operator-side decision framework that applies when validation surfaces issues. The companion to this buyer-side validation piece.