How AI LiDAR classification works: deep learning for point clouds
A LiDAR scan lands on your desk as millions of 3D points that mean nothing yet. Classification is the step that gives each point a label: ground, vegetation, building, water. Once every point has a class, the cloud stops being a blob and becomes layers you can actually use. AI changed how that label gets decided. Instead of rules a person tunes by hand, a deep learning model learns the patterns from clouds that experts already labeled.
Here is how that works, in plain terms: what the old rules did, what a learned model reads in your data, what pretrained means for your team, and why the whole thing can run on an ordinary desktop.
From hand-tuned rules to learned classification
In a LAS file, every point has a classification field with a standard ASPRS code: 2 is ground, 3, 4 and 5 are vegetation by height, 6 is building, 9 is water. Blocks in, classes out. The only question is how each class gets decided.
The classic way is geometric rules. Filters like progressive TIN densification or the cloth simulation filter find the ground using slope and height thresholds. They work, and they are still useful. But every threshold is a bet on one kind of terrain. Settings that behave on flat farmland fall apart on a steep forested slope, so someone ends up re-tuning parameters block after block. The real cost is not computing time. It is the hours spent chasing settings.
A learned model skips the tuning. It was shown a very large number of correctly labeled points, and it worked out for itself which combinations of shape, height and echo pattern separate a roof from the tree hanging over it. That is the same judgement a good reviewer makes by eye in a profile view. The model just applies it to every point at once.
What the model reads from your data
Four signals do most of the work. Shape: is this neighborhood flat like a road, sharp like a roof edge, or scattered like foliage? Height above ground: a point two metres up is probably not bare earth. Echo pattern: a laser pulse that hits canopy splits into several returns, while pavement gives one clean echo. Intensity: how strongly the surface reflects, which hints at the material. A reviewer reads the same four clues by eye. The model reads them at every single point.
The model also reads context. A flat patch five metres up, surrounded by a sharp drop on every side, is a roof and not a small parking lot. Context is how it keeps a wire apart from the trees right behind it, and a roof edge out of the vegetation class.
Rules vs learning: where each one wins
Neither approach is magic. Rules are transparent and predictable. Learning handles messy, mixed scenes without per-scene tuning. Put them side by side on the things that actually eat production time:
| In production | Rule-based filters | Learned classification |
|---|---|---|
| Setup | Pick an algorithm and parameters first | Load a pretrained model and run |
| Per-terrain tuning | Re-tune scene by scene | None; the model adapts on its own |
| Dense canopy, complex roofs, wires | Where single thresholds break first | Held more steadily, learned from many scenes |
| Consistency across a project | Drifts as settings change block to block | Same model, same behavior on every tile |
| Review effort | Heavy cleanup in the hard zones | Focused on known trouble spots |
What pretrained means for your team
A model is only as good as the labeled clouds it learned from, and building that training set is a huge, specialized job. The point of a pretrained model is that someone already did it. Your team assembles no training data and builds no model. You load one that already works and try it on your own tiles.
Why does knowledge from one project carry over to another? Because the signals are physics, not geography. A roof is a flat patch above the ground everywhere on Earth. Canopy always splits the pulse into several returns. That said, data still varies. Sensors, flight heights and point densities differ, and a model used to dense drone data can stumble on sparse high-altitude data. Airborne scans look straight down; mobile scans look from the side. Different views, different model.
Reading the output
The output is the same cloud with a class on every point. How good is it? Two per-class numbers answer that. User's accuracy: of the points labeled building, how many really are building. Producer's accuracy: of the real buildings, how many the model found. Beware the single overall number. Ground dominates most tiles, so a flattering overall score can hide a rare class quietly failing.
The mistakes follow patterns. Low vegetation bleeds into ground on slopes. Wires merge with the trees behind them. Water drops out over dark, wet surfaces. Because the patterns repeat, a reviewer knows exactly where to look first, and the review pass goes fast. That pass is part of the job, not an apology for the model. It is what turns a strong prediction into a deliverable someone signs.
It runs on your own desktop
None of this needs a data centre. A pretrained model processes a block one tile at a time on a GPU workstation of the kind most mapping teams already run. Compare that with a cloud service: upload a multi-gigabyte block, wait in a queue, download the result. Running locally means the data never leaves your machine, there is nothing to upload, and the cost of running one more block is zero.
This is the pattern Vecten Desktop is built around: pretrained classification that runs locally on the operator's own machine. VClassify covers the core semantic classes, VGround the ground and terrain, VUtilities the corridor assets. The output is a standard classified LAS or LAZ block, ready for the review pass any classified deliverable receives.
That is the whole arc. Raw points in, learned shape and context in the middle, a class on every point out, and a person to sign off. Once you see the path, it is much easier to judge where AI classification saves you the most time, and where your eyes are still the best instrument on the project.
