Skip to content
LidarKit

Point cloud statistics

What the classification histogram, return numbers, elevation percentiles, intensity range and density of a LAS or LAZ file tell you, and how each one is defined.

Get these numbers for a file

Opens the viewer with the statistics panel unfolded. Nothing is uploaded.

The header of a LAS file answers most questions about it in a moment: version, point format, count, bounds, coordinate system. But it cannot answer the ones that come up when a delivery lands. Which classes are really in it, and how much is ground? Did the sensor record intensity? How dense is it, and how much of it is noise? Those need every point record, and the figures below are what reading them gives you.

The viewer on this site computes all of them in the same pass that draws the cloud, in a Web Worker on your own machine. The definitions here are the ones it uses, and they are the common ones — the same numbers come out of lasinfo, pdal info and CloudCompare, with the caveats noted where the tools differ.

Classification histogram

Points per class code, for the codes actually present. It is the first thing to look at in any delivered file, because it answers the question the paperwork cannot be trusted on: was this classified at all?

  • Entirely class 0 or 1 — never classified. Class 0 means no classification step ran; class 1 means one ran and assigned nothing.
  • A large class 2 with 3, 4, 5 and 6 — a normal airborne classification: ground, three vegetation heights, buildings. The ground share depends entirely on the landscape; 20% in a city and 70% over farmland are both ordinary.
  • Classes 7 and 18 present — a noise-cleaning step ran. Their absence does not mean the file is clean, only that nobody labelled the noise.
  • Codes 64 and above — user-defined. Their meaning lives in the project documentation or a classification lookup record, not in the standard.

Codes 8 and 12 changed meaning between point formats 0–5 and 6–10; the classification codes reference has the full table. Note that in formats 0–5 the three top bits of the classification byte are flags, not part of the code, and a tool that forgets to mask them reports phantom classes like 130.

Return-number distribution

Each LiDAR pulse can produce several returns — off a canopy, then a branch, then the ground — and every point records which return it was and how many its pulse produced. Tallying the return number tells you two things at once.

First, what kind of data this is. A cloud where nearly every point is return 1 of 1 came from open terrain, a terrestrial scanner, or photogrammetry. If the return numbers are all zero — a value the specification does not allow — it is photogrammetry, or a converter that never filled the field. Second, how much vegetation the pulses penetrated. A high share of second and later returns is forest or hedgerow; ground points under canopy exist only because those later returns do. The share of points from multi-return pulses is the single number that summarises this.

Elevation: min, max, mean and percentiles

The minimum and maximum are decided by two points, and in real scans those two are often noise — a bird, a reflection off water, a return from haze. The mean is pulled by whatever the landscape mostly is. The percentiles are what tell you about the surface.

  • p50 is the median elevation, unmoved by outliers.
  • p5 to p95 bracket the bulk of the surface. On flat terrain the range is the height of the tallest common feature; in hills it is the relief.
  • p1 and p99 against p5 and p95 measure the tails. A p1 far below p5 means a scattering of low points under the surface; a p99 far above p95 means high noise. Either is a reason to colour the cloud by elevation and look.

The viewer draws the elevation distribution as a histogram with p5, p50 and p95 marked on it, so a bimodal surface — say, a terrace and the street below — is visible as two humps rather than one misleading mean.

Intensity range

Intensity is the strength of the return, stored as a 16-bit integer. Its range says how the file was written before it says anything about the scene:

  • Zero everywhere — never recorded. Photogrammetry, or a sensor whose intensity was dropped in processing.
  • Never above 255 — 8-bit values written into the 16-bit field, which many tools then display almost black until they are rescaled.
  • Up to the tens of thousands — the genuine 16-bit range, though usually as a spike near zero with a long tail. That shape is why the viewer's intensity chart is clipped to the central 99%: over the full range every point lands in the first bar.

Point density

Points per unit area is the figure specifications are written in, and the one with the most definitions. The simplest is the one the viewer uses: points divided by the area of the axis-aligned bounding box of the points, in the file's coordinate units.

It is deliberately simple and has a known bias. A diagonal corridor survey, a stretch of coastline or an L-shaped tile covers far less ground than its box, so the figure understates the density where the points actually are; it is a lower bound. For a rectangular tile it is the number everyone means. Tools that report a higher density are usually dividing by a tighter footprint — a convex hull, or the count of occupied grid cells — and the two are not comparable without saying which.

Two more caveats. The box should come from the points, not the header: header bounds are frequently wrong in real files, and a header that claims a 10 km extent for a 500 m tile gives a density 400 times too low. And the unit follows the coordinate system: metres for a metric projection, feet for a US survey foot one, and for a geographic CRS the figure is per square degree, which is not a density at all.

Exact, or from a sample?

It matters which figures are counted over every point and which are estimated, because "how many ground points" is exactly the kind of number that ends up in a report. In the viewer here, the class counts, return counts, extents, means and density are exact: every record passes through the decoder on its way to being drawn or skipped, and it is tallied there. The distribution charts and the percentiles are the exception. A percentile needs the whole distribution, and holding hundreds of millions of elevations to sort them would cost more memory than the cloud itself, so they come from the display sample — up to two million points at an even stride across the file — and the panel says so when that is what it did. For a file that fits the display budget entirely, everything is exact.

Open the viewer to get these figures for a file. Drop it in, and the statistics panel unfolds under the view once the points are read.

Frequently asked questions

How do I get a classification histogram of a LAS or LAZ file?
Open the file in the viewer on this site and unfold the Point statistics panel under the 3D view. Every point record is read once in a Web Worker and the classification of each is tallied, so the histogram shows exactly which ASPRS classes are present and how many points each holds. The counts match what lasinfo and pdal info report for the same file.
Are the viewer's counts exact, or estimated from a sample?
The counts are exact. Class counts, return counts, the elevation minimum, maximum and mean, the intensity range and the bounding box come from every point in the file, not from the points that happen to be drawn. Only the two distribution charts and the elevation percentiles use the display sample, and only when the file is larger than the two-million-point display budget — the panel says so when that is the case.
How is point density calculated?
Points divided by the area of the axis-aligned bounding box of the points, in the units of the file's coordinate system. That is the simplest honest definition: a bounding box overstates the covered area for a corridor, a coastline or an irregular tile, so the figure is a lower bound on the density where there are actually points. Software that reports a higher number is usually dividing by a tighter footprint, such as a convex hull or a count of occupied grid cells.
Why does the density read per square degree?
Because the file's coordinates are geographic — latitude and longitude — rather than projected. A degree of longitude is a different length at every latitude, so points per square degree cannot be compared with points per square metre. Reproject the file to a metric CRS to get a usable density.
What does the return-number distribution tell me?
Whether the data came from a LiDAR sensor and how much it penetrated. A cloud with almost every point as return 1 and one return per pulse is either open terrain or photogrammetry; a large share of second and later returns means vegetation the pulses passed through. Return number 0 is not valid in the specification and appears when the writer never filled the field — common in photogrammetric exports.
How do I tell whether a file has actually been classified?
Look at the histogram. A file that is entirely class 0 or class 1 has never been classified, whatever the delivery paperwork says. A properly classified airborne LiDAR file usually has a large ground class (2) with vegetation (3 to 5) and often buildings (6); noise classes 7 and 18 show that a cleaning step ran.
What do the elevation percentiles show that min and max do not?
Where the bulk of the surface is, and how far the outliers are from it. The minimum and maximum are decided by the single lowest and highest points, which are often noise — a bird, a reflection, a return from the sky. If p1 sits far below p5, or p99 far above p95, those extremes are a handful of stray points rather than real terrain, and a filter on class 7 and 18 or a height threshold will remove them.
Why is the intensity chart clipped?
Because intensity is almost always a spike near zero with a long tail towards 65535, and binned over the full range every point would land in the first bar. The chart covers the central 99% of the values and folds the tails into its end bars, which it labels. The minimum and maximum next to it are still the true ones.