LAS is the ASPRS point-cloud interchange standard; LAZ is its losslessly compressed encoding. Send LAZ when the recipient and contract accept it because fewer bytes reduce storage and transfer burden. Send LAS when the specification requires LAS or the client's toolchain cannot read LAZ. Never promise one compression ratio: measure the actual dataset.
LAS defines the point records
The current published LAS 1.4 revision is R16. Its Point Data Record Formats remain 0–10: PDRFs 0–5 are legacy, while 6–10 are preferred going forward. PDRF 6 is the newer core: GPS Time is mandatory, as many as 15 returns are supported, and classification expands to 256 values. The cited R15 PDF remains the technical source used here for these unchanged record definitions and sizes.
Minimum point-record sizes vary with the attributes:
| PDRF | Main distinction | Minimum bytes per point | |---|---|---:| | 0 | Legacy core | 20 | | 3 | Legacy with GPS Time and RGB | 34 | | 6 | Preferred core with GPS Time | 30 | | 7 | PDRF 6 plus RGB | 36 | | 8 | PDRF 7 plus NIR | 38 | | 10 | RGB, NIR, waveform reference | 67 |
Those sizes explain why “one billion points” is incomplete as a storage estimate. One billion PDRF 6 records are about 30 decimal GB; PDRF 7 is 36 GB and PDRF 10 is 67 GB, before headers, extra bytes, and external waveform data.
ASPRS publishes LAS 1.4 R16 as the current LAS 1.4 revision. LAS 1.5 remains ongoing standards work rather than a published replacement. Check the official ASPRS documents portal when a contract requires the authoritative current file.
LAZ compresses the point block without discarding points
LASzip describes LAZ as free, open-source, lossless compression with a bit-identical round trip. LAZ does not introduce a different point-cloud data model. Under the LAZ 1.4 R1 specification, the point data block is compressed while the header identifies the compressed PDRF so a LAS-only reader does not silently interpret compressed bytes as ordinary points.
The encoding uses lossless arithmetic coding and prediction of values or differences. Chunking supports access at chunk granularity. For PDRFs 6–10, layered and chunked compression lets readers skip unneeded layers. Waveform data is stored in an external .wdp companion rather than compressed into the LAZ point block.
Compression is not the same as thinning, reprojection, coordinate rescaling, or deleting attributes. Those processing choices can alter data; LAZ compression itself is lossless according to LASzip.
The ratio is dataset-dependent
LASzip states that LAZ files are 7–20% of the original LAS size. The LAZ specification publishes no numeric ratio. Treat the LASzip range as project-stated guidance, not a universal result. PDRF, populated attributes, coordinate scale and offset precision, point ordering, and dataset character influence compression.
For a one-billion-point PDRF 7 deliverable, the minimum point records are about 36 decimal GB as LAS. Applying LASzip's stated range produces a scenario of roughly 2.5–7.2 GB as LAZ. The width of that range is the reason to compress representative tiles before capacity planning.
Format choice changes transfer exposure but not network performance. Fewer bytes generally take less time over the same path, yet achieved throughput still depends on sender upload, recipient download, latency, contention, storage, and protocol behavior. Use the transfer-time calculator with measured LAS and LAZ sizes rather than hardcoding a compression assumption.
Acceptance matters more than convenience
LAZ is not universally accepted as a contractual deliverable. The USGS Lidar Base Specification requires LAS 1.4 with PDRFs 6–10 for its point deliverables and does not name LAZ in that requirement. Separately, USGS 3DEP data is distributed publicly as LAZ 1.4 through the AWS Open Data Registry. That distinction shows why an efficient distribution format and a required submission format may differ.
Choose:
- LAS when the contract names it, validation requires it, or the client has a LAS-only toolchain.
- LAZ when accepted and the client needs a conventional downloadable point cloud with fewer transfer bytes.
- COPC when the client needs spatial subset access from one file. COPC 1.0 is a LAZ 1.4 file organized as a clustered octree, restricted to PDRFs 6, 7, and 8, with HTTP range access.
- EPT for indexed web-serving workflows that accept a directory tree of LAZ tiles and JSON hierarchy files. Many small files have different packaging and exception behavior from one COPC.
- E57 when a terrestrial/AEC workflow needs a vendor-neutral container for points, imagery, and metadata and the recipient supports it.
Confirm the decision in a README and manifest. If the recipient requests LAS, transmitting LAZ with instructions to convert is not the same as meeting the request.
Plan delivery around the chosen package
Tile conventional deliverables consistently, include every required companion, and verify a decompressed sample before release. Compare the complete package against both endpoints and the deadline. The LiDAR delivery checklist covers format, CRS, units, metadata, access, and acceptance; the LAS-size explanation covers the other volume multipliers.
TeraAirlift does not choose or convert the format. It is a Windows-first desktop operations console for moving the resulting files and folders, with 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 speed. See the LiDAR workflow and 5 GB versus 5 TB guide for transport planning.
Sources
- ASPRS — LAS public documents, including current LAS 1.4 R16
- ASPRS — LAS Specification 1.4 R15 technical reference
- ASPRS LAS Working Group discussion
- LASzip project
- rapidlasso — LAZ Specification 1.4 R1
- USGS — Lidar Base Specification
- AWS Open Data Registry — USGS 3DEP
- COPC specification
- Entwine Point Tile specification
