Skip to main content

Point cloud classification software: what it does and how to evaluate it

Sep 7, 20266 MIN READClassification
Classified airborne LiDAR block with ground, vegetation, and buildings as distinct classes.
The output of classification software: the same points, each carrying a class code.

A LiDAR survey lands as millions of points with coordinates, intensity, and return information, and nothing that says which points are ground, which are trees, and which are a roof. Point cloud classification software writes that answer into the file: a class code on every point, using the scheme the LAS format has carried since its early versions [1]. Everything downstream, from the terrain model to the corridor clearance report, reads those codes. This piece explains what the software actually does, the four jobs it has to do well, and how to test one on your own data before you commit to it.

What classification software actually does

The input is a LAS or LAZ file, or a COPC file, which is LAZ organized for streaming [2]. The output is the same file with the classification field set on each point. The codes are standardized: 2 for ground, 3 to 5 for low, medium, and high vegetation, 6 for building, 7 for low noise, 9 for water, 17 for bridge deck, 18 for high noise, and for utility work 13 to 16 for guard wires, conductors, transmission towers, and wire-structure connectors [1]. Codes 64 to 255 are left for user-defined classes in the modern point record formats [1]. A good tool writes these codes and nothing else it was not asked to touch: coordinates, return numbers, GPS time, and flags come out as they went in.

Two families of method do the work. Rule-based filters classify by geometry: a point well below a fitted surface is ground, a point far above its neighbours is noise. They are predictable and remain the backbone of terrain work. Learned models classify from examples and separate what geometry alone struggles with, a roof edge from a tree crown, a conductor from a branch. Most production tools now combine both, and the practical question is not which method a vendor names but which classes come pretrained and how well they hold on your terrain.

The four jobs it must do well

  1. Ground, reliably. Every terrain product inherits the ground class, so an error here propagates into the DTM, the contours, and every height measured above ground. Test it on steep, vegetated, and built terrain, not on a flat field.
  2. The semantic classes. Vegetation splits, buildings, bridge decks, water, and for corridor work the wire and structure classes. The class list the vendor ships is the class list you get on day one; anything else is training you will do yourself.
  3. Round-trip fidelity. Read LAS, LAZ, and COPC; write them back without dropping the header, the variable length records that carry the coordinate system, or the point flags. A tool that silently rewrites the coordinate system or strips the withheld flag corrupts work done upstream [1].
  4. Review. Classification is never the last step. The software should make the check fast: a way to see doubtful points, re-run a tile with changed settings, and hand a reviewer something to sign off on.

How to evaluate it on your own tiles

Vendor demos run on the vendor's data. Bring three tiles of your own: one with steep or broken terrain, one dense urban block, and one corridor or forest edge, whichever your contracts lean on. Classify them with default settings and time the whole loop, including the export. Then check the results the way a reviewer would.

CheckWhat to look atWhat it tells you
Ground surfaceResiduals at surveyed check points; hillshade of the DTM for ridges and pitsWhether the ground class holds on your terrain
Per-class agreementProducer's and user's accuracy on a reference tileWhich classes leak into which
Round tripHeader, coordinate system records, flags, and point count before and afterWhether the tool preserves the file
Loop timeRun, review, adjust, re-run on one tileWhat a real block will cost in hours

Producer's accuracy answers, for each class, how many of the reference points in that class the tool found; user's accuracy answers how many of the points the tool put in that class really belong there [3]. Read them per class, not as one overall number, because ground and high vegetation hold most of the points and can hide a building class that is quietly failing. Our note on measuring classification accuracy walks through the confusion matrix behind both figures.

The questions that decide deployment

Some classification software runs on a workstation, some in a browser, some both. The right answer depends on where your blocks land, what your contracts say about where data may be processed, and how often you re-run. A clause that names controlled machines rules out browser-only tools; a small firm without GPU workstations may prefer them. Licensing follows the same split: perpetual or subscription licences on the desktop side, metered processing on the cloud side, where every re-run is billed again. We laid out the trade-offs in where LiDAR classification should run.

Classified urban block with roads, buildings, and vegetation separated by class.
A dense urban tile is the second of the three trial tiles worth bringing.

What to ask a vendor before the trial

  • Which classes are pretrained, on what kind of data, and what happens to points outside that set?
  • Which point record formats and LAS versions are read and written, and are extra bytes and coordinate system records preserved?
  • How is a re-run priced or licensed, and does the answer change with block size?
  • What does the reviewer see: a class layer, a doubtful-point layer, per-tile reports, or only the final file?
  • Where does processing run, and can that satisfy the data clauses in your contracts?

Vecten answers those questions with pretrained models for ground, vegetation, buildings, bridge decks, noise, and utility corridor assets, and with review layers written alongside every classified block. Vecten Desktop runs them on your own workstation; Vecten Cloud runs the same models in the browser.

Frequently asked questions

Is point cloud classification the same as segmentation?
No. Classification assigns a class code to every point. Segmentation groups points into objects, such as one building or one tree, which may then be classified or extracted. Production LiDAR deliverables are specified in classes, so classification is the step contracts name.
Which classes should the software support?
At minimum the ASPRS standard classes your deliverables name: ground, the vegetation splits, building, water, noise, and bridge deck for mapping work; the wire and structure classes for corridor work. Check that the tool writes the standard codes rather than its own numbering.
Can classification software work on LAZ directly?
Most production tools read and write LAZ, and many now read COPC. What matters is that the compressed round trip is lossless and that the header and variable length records survive it.
How long should a trial take?
Three tiles, one afternoon. If a tool cannot classify a representative tile and let you check it in that time, the loop is too slow for production regardless of how the demo looked.

References

  • [1] ASPRS, *LAS Specification 1.4 – R16*, The American Society for Photogrammetry & Remote Sensing, LAS Working Group, 2025. github.com/ASPRSorg/LAS
  • [2] *Cloud Optimized Point Cloud (COPC) specification*. copc.io
  • [3] R. G. Congalton, "A review of assessing the accuracy of classifications of remotely sensed data," *Remote Sensing of Environment*, vol. 37, no. 1, pp. 35-46, 1991, doi: 10.1016/0034-4257(91)90048-B.

Evaluate Vecten Desktop on your own LiDAR blocks.

Classify LAS, LAZ, and COPC blocks on your own workstation and publish review-ready outputs.

Request Early Access