LiDAR classification classes explained: from ASPRS codes to production outputs

Every point in a LiDAR block carries a classification code, and that single integer is what turns a raw scan into something a survey, mapping, or infrastructure team can use. It is the difference between millions of undifferentiated returns and a deliverable where the ground, the tree canopy, the rooftops, and the powerlines are each held as their own layer.

The codes themselves are not arbitrary. They follow a published convention maintained by the American Society for Photogrammetry and Remote Sensing (ASPRS) as part of the LAS specification, so a file classified by one team can be read the same way by the next. This guide walks through what those codes are, which standard classes actually show up in production work, what each one is used for downstream, and what a reviewer looks at before a block is signed off.

What a LiDAR classification code actually is

In the LAS format, every point record stores a classification value alongside its coordinates, intensity, return number, and other attributes. In older point record formats the classification field was a 5-bit value, which capped the usable range at 0 to 31. LAS 1.4 introduced extended point record formats where classification is a full byte, so a point can carry any value from 0 to 255. The lower numbers are reserved for the ASPRS standard meanings; the higher range is left open for user-defined classes agreed on a per-project basis.

It is worth separating the class from the point's status flags. Alongside the classification value, LAS points carry independent flags such as synthetic, key-point, withheld, and (in extended formats) overlap. A point can be classified as ground and also be flagged as withheld, for example. The class describes *what the point is*; the flags describe *how it should be treated*. Reviewers read both, but they are stored and edited separately.

The ASPRS standard classes used in production

The ASPRS list defines many codes, but a smaller set carries most production work. The table below covers the classes that show up on the majority of airborne and UAV jobs, together with the downstream product each one feeds. The names are the standard ASPRS names; the codes are stable across projects.

Two more codes are worth naming even though they are not products in themselves. Code 1 (Unclassified) is where returns sit before anyone has assigned them a meaning, and code 7 (Low Point) marks low returns that behave like noise and need to be kept out of the ground surface. Both are part of the everyday vocabulary of a classified block.

What each class is used for downstream

Classes are not an end in themselves — each one exists because a downstream product depends on it. Reading a class list is easier when you know which deliverable each layer feeds:

• Ground (2) is the foundation of the digital terrain model. Contours, slope, drainage, and cut-and-fill volumes all derive from it, so ground is the class most other work leans on.
• Vegetation (3, 4, 5) is split by height so that low undergrowth can be stripped from the bare earth while canopy metrics — tree heights, forest structure — are built from the high vegetation returns.
• Building (6) feeds footprints, roof planes, and 3D city models, and it keeps structures out of the terrain surface where they would otherwise create artifacts.
• Water (9) drives hydro-flattening: lakes and rivers are held to a consistent surface, and shorelines and drainage networks are drawn from the boundary.
• Wire conductor (14) and transmission tower (15) are the backbone of corridor work — conductor geometry supports clearance analysis, and tower locations anchor the structure inventory.
• Bridge deck (17) is separated from ground so the terrain model stays continuous under the deck and hydro and road products read the crossing correctly.

What production reviewers check, class by class

A classified block is rarely accepted on first pass. Review is where a class list becomes a dependable deliverable, and each class has its own failure modes a reviewer looks for:

• Ground: no vegetation or building returns left in the surface, no gaps under dense canopy, and a smooth transition across tile edges.
• Vegetation: the low, medium, and high splits are consistent, and low vegetation is not eating into ground on slopes.
• Building: roof edges are clean, walls are not misread as ground, and small structures are not dropped into vegetation.
• Water: the surface is flat and the shoreline follows the real boundary rather than drifting into ground.
• Corridor: conductors and towers are separated from vegetation and from each other, since a merged span defeats clearance work.
• Bridge deck: the deck is lifted off the ground surface so the terrain model does not sag or bulge at the crossing.

How Vecten Desktop modules map to class groups

The class groups above line up with how classification tools are organized in practice. In Vecten Desktop the work is split across three modules so a team can run only what a job needs. VGround focuses on the ground class and the terrain surface that depends on it. VClassify covers the core semantic set — ground, the vegetation splits, buildings, water, and bridge decks where they apply. VUtilities handles corridor assets: wire conductors, poles, and transmission towers.

Whichever tool produces them, the classes are the shared language of the deliverable. Knowing what code 2 means, why vegetation is split three ways, and what a reviewer checks for each class is what lets a LAS, LAZ, or COPC block move cleanly from a raw scan to a product a downstream team can trust.