Reading a LAS/LAZ header, and what COPC adds

Scale, offset, and the 32-bit limit

X, Y and Z in a point record are signed 32-bit integers, not floating-point numbers. The header's scale and offset turn them into file coordinates: coordinate = (record value × scale) + offset, at the precision the scale claims — 0.0001 in the chapel scan, 0.001 in the Greenwood LAZ.

A signed 32-bit integer stops at 2,147,483,647, and the offset exists because of that ceiling. The northern edge of the Greenwood crop is at 4,286,002.909 m in UTM zone 15N; at a 0.001 m scale with no offset that is 4,286,002,909 counts, twice what the field holds. The published LAZ sets the Y offset to 4,285,496 m, so the point is stored as 506,909 counts.

Ask PDAL for a 0.001 m scale with no offset and it declines, naming the first point to overflow rather than the largest:

Unable to convert scaled value (4285603749) to int32 for dimension 'Y'

The published COPC keeps the offset at zero and coarsens the scale to 0.01 m, which fits and quantizes every coordinate to the nearest centimeter. The check is two-sided about the offset, and it runs per axis: every coordinate has to satisfy −2,147,483,648 ≤ (coordinate − offset) ÷ scale ≤ 2,147,483,647, so the axis minimum and the axis maximum both have to be tested. Dividing the extent by the scale says the data would fit somewhere, not that the offset puts it there.

Where the coordinate reference system lives

The header has no field for it. The coordinate system is stored in a variable length record — an ordinary VLR before the points, or an extended one after them.

A VLR is a 54-byte header — two reserved bytes, a 16-character user ID, a 2-byte record ID, a 2-byte payload length, a 32-character description — and then its payload, which is what the Bytes column counts.

LASF_Projection record 2112 is the OGC WKT coordinate system record, and its 905 bytes name a compound CRS: EPSG:6344, NAD83(2011) / UTM zone 15N, plus EPSG:5703, NAVD88 height. Global Encoding reads 16, bit 4 set, so flag and record agree, as they must: LAS 1.4 makes a clear WKT bit an error for point formats 6 through 10, to be fixed at the source rather than read around.

The chapel scan has one VLR, the LASzip descriptor. The dump starts at byte 224, so the record begins with bb aa at 227:

000000e0: b4 09 c0 bb aa 6c 61 73 7a 69 70 20 65 6e 63 6f  .....laszip enco
000000f0: 64 65 64 00 00 bc 56 2e 00 68 74 74 70 3a 2f 2f  ded...V..http://
00000100: 6c 61 73 7a 69 70 2e 6f 72 67 00 00 00 00 00 00  laszip.org......

So there is no CRS in the file, and the Global Encoding is zero. A handheld SLAM scanner builds its cloud in a frame the walk defines, and the file records neither where that frame's origin ended up nor — since units are part of a CRS — what the numbers are in. Ask for the transform to a mapping frame when a scanner-local file arrives without one.

One region by HTTP range request

The plain LAZ declares a fixed 50,000 points per chunk, so a reader can seek to a chunk boundary but nothing tells it which chunk covers which part of the site. The COPC sets the same field to the variable-chunk sentinel, one chunk per octree node, and the hierarchy says where each one is, so asking for a region becomes a byte range:

curl -r 4807078-4989292 -o node.bin \
  https://bradleylab-public.s3.us-east-2.amazonaws.com/pointclouds/\
greenwood_cemetery_usgs3dep_2017.copc.laz

HTTP/1.1 206 Partial Content
Content-Range: bytes 4807078-4989292/4990292
Content-Length: 182215

Three requests give a whole-site overview: bytes 0–1,640 for the header and VLRs, bytes 4,989,432–4,990,291 for the hierarchy, and the 182,215 bytes of the root node — 184,716 bytes of 4,990,292, or 3.7 percent of the file, for 19,776 points across the entire cemetery. PDAL does the same through its COPC reader, which takes the URL directly and writes the same 19,776 points:

pdal translate --driver readers.copc \
  https://bradleylab-public.s3.us-east-2.amazonaws.com/pointclouds/\
greenwood_cemetery_usgs3dep_2017.copc.laz overview.las \
  --readers.copc.resolution=10

The chunks here are encoded by lazperf rather than by LASzip itself, recorded above as lazperf variant; the lab's publishing notes have that combination breaking CloudCompare and ArcGIS Pro for another lab file, in point format 7, in June 2026 — which is why the plain LAZ is published alongside.