LAS vs LAZ vs COPC: choosing the right LiDAR format for classification

A LiDAR block can live in more than one container, and the container you choose shapes how fast it moves, how much storage it eats, and how easily a colleague or a web viewer can open it. LAS, LAZ, and COPC are the three you meet most often in survey and mapping production, and although they can hold the exact same points, they are built for different jobs.

The reassuring part for anyone doing classification work is that the classification codes travel unchanged across all three. A point classified as ground stays ground whether it sits in a raw LAS delivery, a compressed LAZ archive, or a COPC file streamed into a browser. The format choice is not about the meaning of the data — it is about size, read and write speed, and how the file is accessed. This guide walks through what each format is, how they compare, and how to pick one for a classification workflow.

LAS: the ASPRS exchange standard

LAS is the open exchange format published by the American Society for Photogrammetry and Remote Sensing (ASPRS). It is a binary format, and the current published version is LAS 1.4. A file opens with a public header block, followed by a set of variable length records that carry metadata such as the coordinate reference system, and then the point data itself — one fixed-size record per return.

Each point record stores far more than a coordinate. Alongside X, Y, and Z, a point carries intensity, return number, number of returns, scan angle, GPS time, and — the field that matters most here — classification. The exact set depends on the point data record format. LAS 1.4 added the extended point record formats (6 through 10), which store classification as a full byte, so a point can carry any class value from 0 to 255 and GPS time is standard. Older point record formats capped classification at a 5-bit field.

The thing to know about LAS is that it is uncompressed. Every point takes the same fixed number of bytes whether the scene is a bare field or a dense forest, so a modern airborne collection runs to very large files. That is fine for a sensor writing raw data and for a tool that needs to read points at full speed, but it is heavy for storage and slow to move across a network.

LAZ: the same data, compressed

LAZ is LAS put through lossless compression. The compression is handled by LASzip, an open and freely available codec, and the key word is lossless: every point, every attribute, and every classification code is recovered bit-for-bit when the file is read back. Nothing is thrown away and nothing is approximated. A LAZ file carries the same header, the same variable length records, and the same points as the LAS it came from.

The payoff is size. A LAZ file is typically several times smaller than the LAS it came from — often in the range of 5 to 10 times smaller, depending on the data. For archiving, delivery, and anything that crosses a network, that reduction is the difference between a manageable handoff and a painful one, which is why most vendor deliverables and public data portals distribute LAZ rather than raw LAS.

The tradeoff is compute. Points have to be decompressed before a tool can read them, so there is a CPU cost every time the file is opened for processing, and a matching cost to recompress on write. For a one-time read this is negligible; for a workflow that reads and rewrites the same block many times, the decompression overhead is worth being aware of. LAZ buys a large saving in storage and transfer in exchange for a modest, repeated cost in processing time.

COPC: one file built for streaming

COPC — Cloud Optimized Point Cloud — is the newest of the three, and it is best understood as a special kind of LAZ rather than a separate format. A COPC file is a valid LAZ 1.4 file whose points are reorganized into a clustered octree, with the hierarchy of that octree stored in a variable length record. Because it is still a conformant LAZ file, it opens in any LAZ-capable reader as an ordinary point cloud — the organization is an addition, not a break in compatibility.

What the octree buys is selective access. Instead of reading a file start to finish, a client can ask for just the parts of the tree it needs. Two things follow. First, a viewer can stream a COPC file over plain HTTP using range requests, pulling only the byte ranges it wants without downloading the whole file. Second, it can read at a chosen level of detail — a coarse overview of a huge block first, then finer nodes only where the user zooms in. One file serves both the quick preview and the full-resolution data.

COPC uses the extended point record formats, so like modern LAS and LAZ it carries full-byte classification and standard GPS time. It is aimed squarely at remote access and web viewing: a single file on a server that many people can inspect without each of them pulling gigabytes down to their own machine.

Comparing the three at a glance

The three formats sit on a clear progression: LAS is the plain uncompressed container, LAZ compresses it losslessly, and COPC reorganizes a LAZ for streaming. The table below lines up the properties that actually drive a format decision.

Choosing a format for a classification workflow

For a classification team the choice usually resolves along three axes: how the data arrives, how it is worked, and how it is shared or reviewed. None of the three formats is universally best — each earns its place at a different stage of the job.

• Arrival and delivery. Sensor and vendor deliverables commonly arrive as LAS or LAZ, and LAZ is the sensible default for archiving and for handing off finished work — it is small, lossless, and readable by essentially every tool in the pipeline.
• Active classification. Classification is block-based local work: a tool reads a block, edits point classes, and writes the result back. All three formats preserve the classification codes exactly, so the decision here is read and write speed against storage. Many teams keep working blocks in LAZ and accept the decompression cost; some stage a heavily iterated block to uncompressed LAS for faster repeated reads.
• Review and sharing. When the point is to let colleagues or clients inspect a classified block without shipping the whole file, COPC is the format built for it — one file on a server, streamed at the level of detail each viewer needs.

This is why a classification tool needs to sit comfortably with all three. Vecten Desktop ingests LAS, LAZ, and COPC blocks for local, block-based processing and publishes classified outputs in the same family, so the format a block arrives in never dictates how it is worked or handed on. The container is chosen for the job at hand — raw local reads, compact archives, or streamed review — while the classification carried inside it stays constant from the first scan to the final deliverable.