Spatial Data Archival · Cold Storage

Compressing LiDAR with LASzip for Deep Archive

Point clouds are the largest thing most spatial archives store, so the compression decision on LiDAR moves the storage line more than any other single choice. This walkthrough is for the archivist deciding what form a survey should take before it is tiered into an archive class, and it covers what LASzip actually achieves on real point data, what the remaining levers are once it has been applied, and which apparent optimisations are false economies for a preservation copy.

What LASzip Achieves, and Where the Rest Goes

LASzip is lossless and format-aware: it compresses each point attribute with a model suited to that attribute rather than treating the record as opaque bytes. The ratio it achieves therefore depends heavily on which attributes a file carries.

LASzip ratio by point record content Compression ratios falling from 7.4 to 2.1 as point records gain GPS time, colour and waveform attributes. Lossless LASzip ratio against uncompressed LAS, by record content XYZ + intensity + class 7.4× + GPS time 6.1× + RGB colour 4.2× + full waveform 2.1× The lever is therefore what the archive keeps, not how hard it compresses: waveform data is often an order of magnitude larger than the derived point cloud and is needed by almost nobody — but discarding it is irreversible, so it is a policy decision.

Step-by-Step Procedure

Step 1 — Measure what the delivery actually contains 

pdal info --summary datasets/lidar/2023/region_north/tile_0417.laz \
  | jq '{format: .summary.dataformat_id,
         points: .summary.num_points,
         dims: (.summary.dimensions | split(", "))}'

A record format above 3 carries GPS time; formats 2, 3, 7 and 8 carry colour. Knowing which attributes are present tells you which ratio to expect and which are candidates for a policy conversation.

Step 2 — Compress losslessly, and verify it round-trips 

# Compress an uncompressed LAS delivery
pdal translate datasets/lidar/2023/raw/tile_0417.las tile_0417.laz \
  --writers.las.compression=laszip \
  --writers.las.forward=all

# Prove the round trip is exact: decompress and compare point records
pdal translate tile_0417.laz roundtrip.las --writers.las.forward=all
cmp <(pdal info --all datasets/lidar/2023/raw/tile_0417.las | jq -S .stats) \
    <(pdal info --all roundtrip.las | jq -S .stats) && echo "round trip exact"

Step 3 — Decide the waveform and intermediate-product policy explicitly

The largest saving available is not compression but scope. Waveform records, raw swath files and intermediate classification passes can each dwarf the delivered point cloud, and each has a different case for retention.

What a LiDAR deliverable is made of, and what to keep Four components of a LiDAR deliverable by storage share — waveform, raw swaths, classified point cloud and derived rasters — with a retention recommendation for each. One county-scale acquisition · 6.9 TB delivered, all LASzip-compressed full waveform 4.2 TB · 61% keep only where a documented research need exists — and record the decision either way raw swath files 1.5 TB · 22% keep for a defined period; they permit reclassification, which the classified cloud does not classified point cloud 980 GB · 14% the archive of record — keep indefinitely, convert to COPC, replicate derived rasters 210 GB · 3% — regenerable; keep for convenience, not for preservation

Step 4 — Tier what remains

Once scope and compression are settled, the tiering decision is ordinary: the classified cloud follows the archive’s access curve, the raw swaths go deep, and the derived rasters follow whatever their consumers need.

aws s3api put-object --bucket spatial-archive \
  --key archive/lidar/2023/region_north.copc.laz \
  --body region_north.copc.laz \
  --storage-class STANDARD_IA \
  --checksum-algorithm SHA256 \
  --tagging "copy_class=authoritative&retention_class=statutory-25y&asset=lidar"

Validation & Verification

Confirm the compression was lossless and the header survived.

pdal info --metadata region_north.copc.laz \
  | jq '{count, compressed: .metadata.compressed, dataformat_id: .metadata.dataformat_id,
         scale_x: .metadata.scale_x, offset_x: .metadata.offset_x}'

Expected output shows compressed: true, the point count matching the source exactly, and the record format and frame unchanged. A record format that differs from the source means attributes were dropped, which no compression check would report.

Troubleshooting

Symptom Root cause Fix
Ratio far below expectation Record carries colour or waveform Expected — check the record format before blaming the codec
Output larger than input Input was already LAZ Do not recompress; LASzip is not idempotent-improving
Round trip differs in statistics Record format downgraded on write Pin dataformat_id and use forward=all
GPS time lost Written as a format without a time field Use record format 6 or 7 for anything carrying time
Deep Archive bill higher than modelled Many small tiles, per-object overhead Consolidate before tiering; see the COPC grouping guidance

Operational Execution Checklist

Deciding What a Survey Is For Before Deciding What to Keep

Retention decisions on point-cloud deliverables are usually framed as a storage question and are really a question about future use. Three uses account for almost everything anyone does with an archived LiDAR survey years later, and each depends on a different part of the deliverable — so the retention policy follows directly once the uses are named.

Which deliverable each future use depends on Three common future uses of an archived LiDAR survey and the component each depends on, with the retention that follows. future use depends on retention that follows terrain models, change detection classified point cloud only keep indefinitely reclassification with new methods raw swaths keep 10–15 years full-waveform research waveform records keep only on a documented request legal or contractual evidence the delivery as received keep per the contract Naming the uses turns an argument about storage cost into a decision about scope, which is the only kind that can be defended later.

Write the answer into the collection’s profile rather than deciding per delivery, so a contractor shipping four terabytes of waveform data next year meets an existing policy rather than a fresh debate. Where a use is genuinely uncertain, keeping the component for a defined review period and revisiting is better than either extreme.

Frequently Asked Questions

Is lossy point-cloud compression ever appropriate?

For delivery copies serving visualisation, yes; for the archive of record, no. Lossy schemes discard points or reduce coordinate precision, and a preservation copy whose points have been thinned cannot support the re-analysis that is the main reason to keep LiDAR for decades. Keep the lossless copy and generate lossy derivatives as needed.

Does converting to COPC change the compression?

Not materially. COPC uses the same LASzip chunking with the octree layered over it, so the compressed size is within a few percent of an ordinary LAZ file of the same points. The overhead buys the index, which is why the conversion is close to free in storage terms.

Should intensity be kept?

Yes. It is small relative to coordinates, it compresses well, and it is used for classification refinement and for change detection between surveys. It is one of the few attributes where the storage argument for discarding it does not exist.

Does LASzip compression vary between implementations?

The format is fixed, so any compliant reader decodes any compliant writer’s output — but the compressed size can differ by a few percent between implementations and versions. That is worth knowing when comparing an archive’s own output against a delivery: a difference of two or three percent is a tooling difference, not a data difference.

Should point clouds be re-compressed when a better version appears?

No. The gain is a few percent, the cost is a full read and rewrite of the largest thing in the archive, and the result is a set of objects whose checksums no longer match any existing record. Compression improvements belong in the pipeline for new data, not in a campaign against the existing archive.

How does compression interact with the octree in COPC?

COPC compresses each octree node as an independent LAZ chunk, which is what makes node-level range reads possible. That independence costs a little ratio compared with one long stream — typically two to three percent — and buys the ability to read a spatial subset without decompressing the file. For an archive that is an easy trade.

How does compression interact with the fixity programme?

Not at all, directly — the checksum is computed over the compressed bytes as stored, so the codec is invisible to the audit. What does matter is that recompressing an object changes its checksum, which is one more reason not to run compression campaigns against an existing archive. An object whose checksum changed for a good reason still requires a provenance record explaining it, and doing that across a whole holding is more work than the few percent of size it recovers.

Should waveform data be compressed differently from the point cloud?

It is stored separately by the format — in an auxiliary file or an extended variable-length record — and it compresses far less well, because it is closer to raw sensor output than to structured points. Where waveform is retained, treating it as its own object with its own tiering rule is usually better than binding it to the point cloud it accompanies, since almost every access pattern wants one and not the other.

What is the practical ceiling on a single compressed point-cloud object?

Around twenty gigabytes, above which restores become coarse enough that any query pays for far more data than it needs. The format imposes no such limit — point counts are 64-bit — so this is an operational ceiling rather than a technical one, and it is the same reasoning that caps object size for imagery and vector partitions.

Does the compressed size vary with point ordering?

Slightly, and in COPC’s favour: points sorted into octree order are spatially coherent, so their coordinate deltas are smaller and compress marginally better than the delivered tile order. The effect is a percent or two and is a side benefit of the conversion rather than a reason for it.

Up one level: Point Cloud & COPC Conversion.

Related pages

Converting LAS to COPC for Cold Archives Streaming COPC Octree Nodes Over HTTP Range Requests Validating Point Cloud CRS and Scaling After Conversion