A point cloud is a set of measured positions in three dimensions. Each point says: at this X, this Y and this Z, a surface was detected. Most points also carry attributes — how strongly the signal came back, which echo of its pulse it was, what somebody later decided it represents.
The definition is nearly trivial. What makes point clouds worth explaining is the negative space in it: there is no information about what lies between the points, and no stated relationship between one point and the next. A cloud is not a surface. It is evidence from which a surface can be inferred, and almost every difficulty in working with one traces back to that distinction.
What one point actually is
In a LAS file a point is a fixed-size binary record — between 20 and 38 bytes for the formats in everyday use, up to 67 for the waveform formats — laid end to end with every other point. There is no separator, no key, no per-point overhead. Reading point number 4,000,000 is a matter of multiplying by the record length and seeking there, which is why LAS files are fast to read and why the format has survived more than twenty years of data growth.
A typical record in point data record format 1 looks like this:
| Bytes | Field | Type |
|---|---|---|
| 0–3 | X | 32-bit signed integer |
| 4–7 | Y | 32-bit signed integer |
| 8–11 | Z | 32-bit signed integer |
| 12–13 | Intensity | 16-bit unsigned |
| 14 | Return number, number of returns, scan direction, edge of flight line | Packed bit fields |
| 15 | Classification and flags | Packed bit fields |
| 16 | Scan angle rank | Signed byte |
| 17 | User data | Byte |
| 18–19 | Point source ID | 16-bit unsigned |
| 20–27 | GPS time | 64-bit double |
Twenty-eight bytes. Every point in the file has exactly this shape.LAS point formats covers all eleven layouts and what each one adds.
Why the coordinates are integers
The single most surprising thing about a LAS file, for anyone who expects coordinates to be floating point, is that they are not. X, Y and Z are 32-bit integers, and the real-world coordinate is recovered with a scale and an offset stored once in the header:
real_x = (X × x_scale) + x_offset
There are two good reasons, and one important consequence.
Precision. A 32-bit float carries about seven significant decimal digits. A projected easting such as542318.274 already needs nine to hold a millimetre. Storing that as a float silently rounds it — and the error depends on how far the coordinate is from zero, so the same cloud is less precise in one projection than another. An integer with a scale factor gives exactly the same precision everywhere in the file, chosen deliberately by whoever wrote it.
Compression. Neighbouring points in a scan are close together, so their integer coordinates differ by small amounts. That is exactly the structure a compressor can exploit, and it is a large part of why LAZ reaches roughly a tenth of the original size losslessly. Floating-point coordinates, whose bit patterns change erratically for nearby values, compress far worse.
The consequence: the scale factor sets the resolution of the file, and the range of a 32-bit integer sets its extent. With a scale of 0.001 the coordinates span about ±2,147 km around the offset — ample. With a scale of 0.01, ten times that, but the file can then only express centimetres. Choosing a scale finer than the data warrants wastes compression; choosing one coarser than the survey's accuracy quietly throws measurements away. Both are visible in the header, which the LAS inspector reads without touching a single point.
Point cloud, raster, mesh
These three turn up constantly in the same workflows, and the differences between them decide which operations are cheap, which are lossy and which are impossible.
| Point cloud | Raster | Mesh | |
|---|---|---|---|
| Structure | Irregular positions, no connectivity | Regular grid of cells | Vertices joined into faces |
| Coverage | Gaps wherever nothing was measured | Complete over its extent | Continuous over the surface |
| Multiple heights at one X,Y | Yes — canopy, eaves and ground all present | No — one value per cell | Only if the surface folds over itself |
| Per-element attributes | Many, on every point | One value, or one per band | Usually position and colour only |
| Size for a given area | Large, driven by density | Small and predictable | Between the two |
| Good for | Measurement, classification, deriving other things | Analysis, display, sharing | Visualisation, volumes, physical models |
The row that matters most is the third. A point cloud can hold several points directly above one another; a raster cannot.That single property is why a cloud can describe a tree canopy and the ground beneath it at once, and why turning it into an elevation raster forces a choice about which of those heights to keep — the choice that separates a DSM from a DTM.
Note also that converting a cloud to a raster is routine and lossy, and the reverse is not really possible. Rasterising discards the individual measurements and every attribute you did not grid. You can generate points from raster cells afterwards, but they are grid samples, not the original observations.
Density
Point density is points per unit of ground area, conventionally points per square metre. Its inverse, the average spacing, is often the more useful number: 4 points/m² is about one point every 50 cm, and 16 points/m² about one every 25 cm.
Density sets a hard limit on what the data can resolve. A kerb 15 cm wide is not reliably present in a cloud whose points are 50 cm apart — it may be caught by a few points, but it cannot be measured. Deriving a 10 cm raster from such a cloud produces a result that looks detailed and is mostly interpolation. As a rough rule, a derived grid cell should be large enough to contain at least a few points.
Real density is never uniform, for reasons worth recognising:
- Overlap. Adjacent flight lines or scan positions overlap by design, so those strips have double density or more.
- Range. A terrestrial scanner sweeps at a constant angular step, so points spread apart with distance. Density near the tripod can be thousands of times what it is at the far wall.
- Surface angle. A beam striking a slope obliquely spreads its footprint over more ground.
- Absorption. Water and very dark surfaces return little or nothing, so they appear as holes rather than as flat areas.
Because of this, a single average density for a whole file can be misleading — it is a useful headline number and a poor description of any particular spot. Thestatistics panel in the viewerreports density over the bounding box alongside the distributions that explain it;point cloud statistics goes through how each is defined.
Where point clouds come from
LiDAR is the most common source in geospatial work, but not the only one, and the differences show up in the data:
- LiDAR. Direct range measurement. Produces return numbers and intensity, and can see through gaps in vegetation to the ground beneath.
- Photogrammetry. Points reconstructed from overlapping photographs. Carries good RGB colour and no return information at all — every point is whatever the camera could see, so there is nothing under a canopy. This is why photogrammetric clouds need adifferent classification approachfrom airborne LiDAR.
- Depth and structured-light sensors. Short range, high density, typically indoors.
- Sonar. The same idea underwater, with sound.
A cloud from any of these can live in a LAS file, and the format cannot tell you which it was. The give-away is in the data: if every point is return 1 of 1, or the return fields are all zero, it is almost certainly not from a ranging LiDAR sensor.
What you can do with one
Directly: measure between points, take sections and profiles, compare two epochs to find change, and classify points into ground, vegetation and buildings. All of these work on the cloud as it stands.
Indirectly, by deriving something else: an elevation raster, a contour set, a mesh, a building footprint, a canopy height model. These are conversions, and each one discards information the cloud held. That is usually the right trade — a 3 GB cloud becomes a 20 MB raster that every GIS can open — but it is worth knowing it is a one-way door, and worth keeping the cloud.
Open a point cloud in your browserto look at one directly, orinspect the header to see the scale, offset, extent and point count before committing to a workflow.
Size, and why compression is not optional
Point cloud file sizes are unusually predictable: record size times point count, plus a header of a few hundred bytes. No content-dependent variation, no surprises.
| Points | Format 1 (28 bytes) | Format 3 (34 bytes) | Roughly, as LAZ |
|---|---|---|---|
| 1 million | 28 MB | 34 MB | 3–4 MB |
| 10 million | 280 MB | 340 MB | 30–40 MB |
| 100 million | 2.8 GB | 3.4 GB | 300–400 MB |
| 1 billion | 28 GB | 34 GB | 3–4 GB |
The LAZ column is approximate — the real ratio depends on point ordering and how much of each attribute varies — but a tenth is the usual neighbourhood, and it is lossless: converting back produces the original bytes. LAS vs LAZ covers the trade-off, and you can compress a file here to see the real ratio for your own data.
Common mistakes
- Deriving a grid finer than the density supports. The output looks more detailed and contains no more information.
- Quoting one density figure for a whole survey. True on average, wrong nearly everywhere.
- Treating classification as measurement. Coordinates were measured. Classes were decided, usually by an algorithm.
- Discarding the cloud after making a raster. The raster cannot be turned back into it.
- Assuming empty means flat. A hole in a cloud usually means water, a dark surface, or an occlusion — not level ground.