LiDAR files become large because a point cloud is a long list of records. The basic estimate is points × bytes per point, then headers, variable-length records, imagery, derived products, and intermediate copies add more. Point count grows with area, density, overlap, passes, and returns; bytes per point grow with attributes such as RGB, near-infrared, GPS time, and waveform references.
Estimate point-cloud size from first principles
Start with:
approximate LAS bytes = density × area × bytes per point
Use points per square metre, square metres, and the minimum record size for the selected Point Data Record Format. The result is a planning estimate, not a storage guarantee: real density is uneven, LAS can contain extra bytes, and a complete delivery normally includes more than one point file.
ASPRS LAS 1.4 R15 defines 11 PDRFs. Minimum record sizes are 20, 28, 26, 34, 57, and 63 bytes for legacy PDRFs 0–5, then 30, 36, 38, 59, and 67 bytes for preferred PDRFs 6–10. PDRF 6 is the newer core: GPS Time is mandatory, as many as 15 returns are supported, and classification expands to 256 values. PDRF 7 adds RGB at 36 bytes; PDRF 8 adds near-infrared at 38 bytes. PDRFs 9 and 10 reference waveform packets and are much larger.
For one billion points, the minimum point records alone are approximately:
| Record format | Included distinction | Approximate decimal size | |---|---|---:| | PDRF 6 | Core record with GPS Time | 30 GB | | PDRF 7 | PDRF 6 plus RGB | 36 GB | | PDRF 8 | PDRF 7 plus NIR | 38 GB | | PDRF 10 | RGB, NIR, waveform reference | 67 GB |
These are arithmetic examples based on minimum record sizes, before headers, extra bytes, waveform companions, or project outputs.
Density multiplies area quickly
The USGS Lidar Base Specification gives program-specific minimum aggregate nominal pulse densities of at least 0.5 pulses/m² for QL3, 2 for QL2, and 8 for QL1 and QL0. These are 3DEP requirements, not universal commercial defaults. For the estimates below, first returns stand in as pulse surrogates and each pulse is simplified to one stored return. That produces a lower bound, not a complete record count.
At PDRF 6 under that one-return assumption, a uniform one-square-kilometre example works out to about 15 MB at 0.5 pulse surrogates/m², 60 MB at 2, and 240 MB at 8. Scale the area from 1 km² to 250 km² at 8 pulse surrogates/m² and the lower-bound estimate becomes two billion point records, or about 60 decimal GB. Multiple stored returns from a pulse increase records and bytes, so the arithmetic need not be recalculated unless a return-rate assumption is available.
Real collections are not uniform grids. Scan pattern, altitude, aircraft speed and pitch, swath overlap, vegetation, multiple returns, occlusion, and detector blind zones all change local density. Overlap areas may contain points from several swaths before classification or thinning. Measure the actual exported folder when planning transfer.
Attributes are only part of the footprint
The point cloud may be smaller than everything around it. A contracted delivery can include tiled classified clouds, bare-earth DEMs, orthomosaics, hillshades, breaklines, control reports, trajectory data, metadata, and QA exports. Processing may retain raw, registered, classified, edited, and publication-ready versions simultaneously.
The USGS specification, for example, calls for products beyond the classified point cloud, including a bare-earth DEM, breaklines where required, and metadata. That does not establish a universal commercial package, but it shows why “the LAS file” and “the project folder” are different measurements.
Compress, organize, then choose transport
LASzip describes LAZ as a lossless compressed form of LAS with a bit-identical round trip. The project states that LAZ files are 7–20% of the original LAS size. That range is not a promise: PDRF, populated attributes, coordinate precision, point ordering, and the data itself affect compression. The LAZ specification explains lossless arithmetic, predictive, chunked, and layered compression but publishes no universal ratio.
For the two-billion-record, 60 GB lower-bound LAS example, applying LASzip's stated range yields approximately 4.2–12 GB as LAZ. Multiple returns can increase both the LAS record total and resulting LAZ bytes. Treat the range as a scenario until you test a representative tile. Compression does not excuse a format change the contract forbids, and reprojection, thinning, or coordinate rescaling are separate transformations that may alter data.
Next, tile large deliverables so exceptions can be isolated and recipients can work incrementally. Consider COPC when a client needs spatial subsets: it stores a clustered octree in one LAZ 1.4 file and supports HTTP range reads. Keep conventional LAS when the specification requires it, and use E57 where terrestrial/AEC software and the contract call for a vendor-neutral container holding points, imagery, and metadata.
Finally, compare online and physical movement against the deadline. Use the transfer-time calculator for measured bytes and endpoint rates and the shipping-versus-transfer calculator for larger hauls. The LiDAR workflow covers the operational path.
Where TeraAirlift fits
Once the deliverable is sized and organized, TeraAirlift can operate the online leg. It is a Windows-first desktop console with file and folder queues, progress and ETA, cancellation, retry-friendly operations, history, diagnostics, recipient controls, short-lived storage access, and SHA-256 verification. It is not an archive and does not guarantee a transfer rate. For the larger operational decision, continue with how LiDAR companies move point clouds, the 5 GB versus 5 TB guide, and the LiDAR delivery checklist.
