COPC: Cloud-Optimized Storage for LiDAR Point Clouds

COPC (Cloud Optimized Point Cloud) is an extension of LAZ 1.4 with an embedded octree spatial index that turns a regular LiDAR archive into a file ready for selective reads straight from S3 or any HTTP storage via range requests. Before COPC, working with a LiDAR cloud in the cloud meant "download the entire 5–50 GB LAZ, decompress, run PDAL, pick your bbox"; even for a single-block extract you had to transfer gigabytes. LAZ compresses points beautifully (10–20× vs raw LAS) but offers no random access — the structure is linear, and to reach a point in the corner of the dataset you have to read everything. COPC solves exactly that: an octree index packed into EVLR sections of the LAZ file describes which byte ranges of the file hold the points of which spatial tiles and levels of detail. The client makes one HTTP request for the header, reads the octree, and then pulls only the ranges that fall into its bbox and target LOD.

History and the standard

COPC appeared in 2021 as a joint effort by Hobu Inc. (the company behind PDAL and Entwine) and USGS 3DEP (the US national LiDAR coverage program). By then Hobu already had Entwine Point Tile, their own octree format for cloud-streaming LiDAR, but EPT is a directory of thousands of small files — awkward on S3 (per-object GetObject overhead) and incompatible with the LAZ ecosystem. COPC took the opposite approach: keep exactly one file, binary-compatible with every existing LAZ reader (PDAL, lastools, laspy, CloudCompare), and add the octree index hidden inside standard LAZ 1.4 EVLR fields.

The spec lives on copc.io and is maintained by a small group; version 1.0 was frozen in 2021, minor revisions ship as 1.x. The core architectural promise is backwards compatibility: a COPC file opened by a "dumb" LAZ reader reads as a regular LAS 1.4 — all points present, octree metadata simply ignored as unknown EVLR. This is critical for adoption: USGS doesn't have to maintain two versions of each dataset, the same .copc.laz works in legacy pipelines (lastools batch) and modern web viewers via range requests alike.

Inside COPC

A COPC file is a LAZ 1.4 with two extra artifacts in EVLR (Extended Variable Length Records, the section after the chunk table):

• COPC info VLR — root metadata: dataset bbox, GPS time range, total point count, the octree root (level 0).
• COPC hierarchy EVLR — the octree itself: for each occupied voxel (tree node) it stores a (level, x, y, z) key, the byte offset in the file and the byte size of the compressed chunk holding that node's points. The octree splits the bbox into 2^level cubes: level 0 = the whole bbox, level 1 = 8 octants, level 2 = 64, and so on, usually down to level 6–8 for city datasets.
• Chunk table (the standard LAZ one) — index of compressed chunks; the COPC octree points right into this table.

When a client wants "all points in this block at LOD 3" it (1) issues a GET with Range on the first ~64 KB of the file and reads the header plus COPC info; (2) fetches the COPC hierarchy EVLR (typically hundreds of kilobytes even for a huge dataset); (3) traverses the octree, picking nodes intersecting the bbox and matching the target LOD; (4) fires parallel HTTP range requests for the selected chunks. Points decode on the fly, no need to drag the entire file. Same idea as COG for rasters or PMTiles for vector tiles, applied to point clouds.

LOD is the octree's other trick: upper-level nodes hold "thinned" representative points (one point per voxel), lower levels hold the full density. A web viewer's overview screen is happy with the root levels (millions of points covering an entire state); as the user zooms in, the client streams child nodes and density grows naturally.

Use cases

USGS 3DEP — US national LiDAR coverage. The USGS 3D Elevation Program has published tens of terabytes of scanned territory as COPC on the 3DEP S3 bucket. This is the first and largest consumer: a single state is hundreds of .copc.laz files at 5–50 GB each, and any researcher can pull only the area they need via a PDAL pipeline or the copc.js browser viewer, without downloading terabytes.

AHN3 / AHN4 — Netherlands. The Dutch national LiDAR program Actueel Hoogtebestand Nederland (8–32 points/m² density) moved to COPC distribution in 2022–2023. AHN4 covers the entire country at 0.5 m spacing, and COPC is the only practical way to query that volume without a full download.

Forestry inventory. Forest agencies in Finland, Sweden and Canada publish LiDAR scans of forests in COPC; biomass, canopy height and understorey density are computed server-side or in the browser via PDAL/copc.js over the exact forest tile of interest, no transfer needed.

Survey and mining DTM. In mining, a drone scans the open pit weekly; the deliverable ships as COPC over the internal network — geologists and surveyors pull specific bench sections via PDAL with S3 ACLs and compute weekly extraction volumes.

Workflow in OSM2CDR

Honest disclosure: OSM2CDR is a service for exporting vector OpenStreetMap data (buildings, roads, POIs, water bodies), and COPC is a format for point cloud LiDAR scans, which we do not produce. There is no COPC exporter in worker/renderer/, and this article does not describe a pipeline analogous to LAS or 3D Tiles — those have a direct OSM → mesh pipeline, while COPC's source is fundamentally different: actual airborne or drone scans.

If you already have LiDAR in LAS/LAZ and need to convert it to COPC, the path is standard, via the open-source utility from Hobu:

untwine -i input.laz -o output.copc.laz --single_file

untwine builds the octree in place, writes the hierarchy into EVLR, and upgrades the file to COPC 1.0. The alternative is a PDAL pipeline with writers.copc. Both tools are free and cross-platform.

For osm2cdr users, COPC can be useful in a hybrid scenario: you export OSM vector layers (buildings, road network) through us, you separately hold a LiDAR scan of the area as COPC, and in final assembly (Cesium viewer, QGIS) you overlay both. We don't make COPC, but we mesh well with it on projections: export OSM in the right CRS (UTM, local national grids) and both datasets line up cleanly.

Conclusion

COPC is a rare case of a format that solved a specific problem at the right time: cloud-native LiDAR without breaking compatibility with a decade-old LAZ ecosystem. One file, one spec, a free converter from the author, and the largest national LiDAR programs (USGS 3DEP, AHN, and dozens of regional ones) already on it. If you work with LiDAR, COPC is the de facto cloud distribution standard today. OSM2CDR doesn't generate this format, but if you need to combine our OSM vector exports with your LiDAR COPC files, the /formats/copc/ page is the entry point for projection and compatibility coordination. For vector map formats, see our main formats list.

Related

• LAS — the standard format for LiDAR point clouds
• 3D Tiles — streaming 3D scenes into the browser
• PMTiles — single-file vector tiles for the cloud-native stack

Sources

• COPC specification — copc.io
• USGS 3DEP LiDAR Explorer — apps.nationalmap.gov/lidar-explorer
• Hobu Inc. untwine — github.com/hobuinc/untwine
• PDAL writers.copc — pdal.io/en/stable/stages/writers.copc.html
• AHN — ahn.nl