Every DTM you'll ever use passes through a ground-classification stage. The algorithms are well-understood, the manual review is the unglamorous part nobody talks about, and the quality of both lives in whether your downstream surface is engineering-defensible or not.
A raw LiDAR point cloud is a list of numbers — millions of (x, y, z, intensity, return#) tuples, every one a record of a laser pulse returning from somewhere. There's nothing in the file telling you which points are ground, which are canopy, which are buildings, which are noise. That's the classifier's job.
If you've ever wondered what's actually happening between cloud arrives and DTM ships, this article is the engineering version — the algorithm families, the standard class schema, where classification fails, and how to validate the result against something other than the vendor's assurances.
Given an unlabelled point cloud, output the same cloud with every point assigned to a classification class — usually a small set of seven or eight categories defined by ASPRS in the LAS file format specification.
Sounds simple. The hard part: ground isn't a property of a single point; it's a property of the relationship between many points. A return at elevation 100.000 m could be:
The point's intrinsic properties don't disambiguate these. The algorithm has to look at the local neighbourhood and infer which points are likely-ground given the surface they collectively suggest.
Three approaches have dominated the field since the early 2000s. Each addresses the same problem with different geometric assumptions.
The oldest approach. Sort points by elevation; for each candidate ground point, check whether neighbouring points within some radius are reachable by a "ground slope" of less than some threshold (say, 30°). Points reachable by ground slope are considered ground; points that would require a steeper slope are non-ground.
Simple, fast, brittle. Works on gently undulating terrain; fails on steep batters (real ground that exceeds the slope threshold gets mis-classified as not-ground); fails under low vegetation (low shrubs get classified as ground because they're not steep enough above the surface to filter out).
Largely obsolete for production work, but the concept underpins some manual-edit tools to this day.
The 1990s workhorse. Treats the cloud as a raster and applies a sliding-window minimum elevation filter — for each cell, the lowest point in a window around it is "probably ground". Then a window- based opening operation (erosion + dilation) removes objects smaller than the structuring element.
Better than slope-only on flat terrain. Still brittle on slopes, and the window size has to be larger than any non-ground object you want filtered out — which means very large windows for buildings and tall vegetation, which in turn over-smooths real terrain features.
Mostly historical, but the morphology concepts (opening, closing, structuring elements) survive in adjacent image-processing pipelines.
The breakthrough algorithm, published by Peter Axelsson in 2000, still the production workhorse in most commercial software (TerraScan, LASTools, MARS):
This works because the algorithm doesn't assume slope is constant — it lets the TIN tell it what "ground-like" looks like in each local neighbourhood. Steep batters get accepted because the TIN adapts to them; low vegetation gets rejected because it sits above the locally-defined ground surface.
The parameters (max distance to TIN, max angle, seed grid size, iteration count) tune the behaviour. Defaults work for most sites; specific terrain types — pit walls, vegetation regrowth, levees — benefit from tuning.
The modern challenger. Published by Zhang et al. in 2016. The concept is wonderfully physical:
The simulation has three parameters: cloth resolution (grid spacing), rigidness (how stiff the cloth is), and class threshold (distance cutoff for ground vs not-ground). Lower rigidness + finer resolution fits terrain detail better but takes longer to compute.
CSF has the elegant property of working well on steep terrain without parameter tuning — the cloth conforms to whatever shape the points suggest. It also handles edge cases (urban + vegetated hybrid, sites with mixed terrain types) more gracefully than progressive TIN.
Most modern open-source pipelines use CSF by default (CloudCompare, LiDAR360, PDAL). Commercial pipelines often use a hybrid — CSF for the first pass, progressive TIN for fine-tuning.
No automated classifier is perfect. Known failure modes:
Dense canopy is the universal hard case. When the ratio of ground returns to canopy returns drops below ~5%, all algorithms struggle to identify the sparse ground points reliably amid the abundance of vegetation. Result: holes in the DTM where canopy was densest, often interpolated across distances of several metres.
Steep batters — pit walls, road cuttings, bridge abutments — challenge progressive TIN when the slope exceeds the algorithm's acceptance angle, and challenge CSF if the cloth rigidness is set too high to conform to the batter. Result: batter surface mis-classified as non-ground; DTM smoothed across the batter break-line.
Bridges and overpasses — physically real ground exists under the structure as well as on the structure. Every algorithm treats the deck as ground because it's the topmost continuous surface. Result: the deck shows up in the DTM, the actual ground beneath doesn't.
Low vegetation — grass, low shrubs, regrowth under 300 mm height. Algorithms tuned to accept genuine micro-relief in the ground will also accept low vegetation. Tuned to reject low vegetation will reject genuine ground features.
Mobile objects — vehicles, livestock, machinery captured during the flight. All algorithms classify these as ground because they're sitting on the ground. Result: car-shaped bumps in the DTM.
The honest answer to how good is automated classification? is about 85–95% by point count. The remaining 5–15% — and almost always the most consequential 5–15% — requires manual review.
Manual review is the unglamorous classification work nobody puts in the brochure:
For a typical engineering capture, manual review adds 4–10 hours of processing work for an experienced reviewer. The output is a classified cloud that survives independent QA. The output of automated-only classification looks similar at first glance and fails at the third bridge.
The standard class numbering used by virtually every commercial pipeline:
| Class | Name | Notes | | ----- | --------------------- | ------------------------------- | | 0 | Created, never classified | Default until processed | | 1 | Unclassified | Not assigned to a known class | | 2 | Ground | The class everything else removes from | | 3 | Low vegetation | Under 500 mm above ground | | 4 | Medium vegetation | 500 mm – 2 m above ground | | 5 | High vegetation | >2 m above ground | | 6 | Building | Permanent structures | | 7 | Low point (noise) | Outliers below the surface | | 8 | (Reserved) | | | 9 | Water | | | 10 | Rail | LAS 1.4 addition | | 11 | Road surface | LAS 1.4 addition | | 12 | Overlap point | Multi-strip overlap | | 13–17 | Wires and structures | LAS 1.4 transmission categories | | 18 | High point (noise) | Outliers above the surface | | 19+ | User-defined | |
A delivery quoting "classified cloud" should specify which classes are populated. A delivery with only classes 2 and 1 (ground vs not-ground) is doing the minimum; a delivery with classes 2, 3, 4, 5, 6, 7, 9 differentiated is doing engineering-grade work.
Two separate metrics often conflated:
Positional accuracy is how close to truth each point's coordinates are. ±15–30 mm vertical RMSE on bare ground, validated against checkpoints.
Classification accuracy is how often points are assigned to the correct class. Typically reported as a confusion matrix or as per-class precision + recall. A high-quality classification has ground-point precision >99% (almost no non-ground misclassified as ground) and ground-point recall >95% (almost all genuine ground captured as ground).
A capture with great positional accuracy but poor classification produces a positionally-accurate DTM with classification errors baked in — vehicles in the surface, batters smoothed away, bridges classified as ground. The points are in the right place; the classification is wrong; the DTM is wrong.
A reputable vendor reports both. Most don't.
Three things to ask for on delivery:
The classification class histogram — how many points are in each class? A capture with 60% ground / 40% high vegetation looks plausible for an open paddock; for a dense bushland capture it's almost certainly wrong (should be ~10–25% ground / 60–80% vegetation).
The class confusion matrix from a manual-audit sample — take 200 random points across the cloud, manually verify each, compare to the algorithm's classification. Precision + recall per class drop out.
A visual inspection — open the classified cloud in CloudCompare or similar and view by classification class. The ground class should look like ground; the vegetation class should look like vegetation. Obvious problems (cars in ground, batters in vegetation) are visible in seconds.
Classification is upstream of every surface deliverable that follows. A poorly-classified cloud produces:
The downstream design team can't see the classification problem from the deliverable; they just see surfaces that don't quite match the survey marks. The diagnosis is upstream.
Ground classification is the stage between cloud and DTM that nobody talks about and that determines whether the DTM is defensible. CSF and progressive TIN are the two production algorithms; both work well at 85–95% by point count; the remaining 5–15% needs manual review. Classification accuracy is a separate metric from positional accuracy and worth reporting explicitly.
A delivery without a classification quality report — class histogram + manual-audit sample + visual sanity check — is delivering DTM on faith.
We ship every project with a classification quality report alongside the positional accuracy residuals. Both metrics — not one of the two — are how you tell whether the cloud will hold up.