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.