Reading a LAS header: what it tells you before you classify
A LAS file announces what it can hold before it holds anything. The first 375 bytes, the public header block, say which version wrote it, which point record format it uses, how coordinates are stored, how many points there are, and where the coordinate system lives [1]. Reading that block takes a minute with any LiDAR tool, and it answers most of the questions a classification job raises later: can this file carry wire classes at all, will the coordinates survive a round trip, and is the coordinate system going to be there when the client opens the result. Here is the header, field by field, from a surveyor's side of the desk.
The public header block, in the order it is written
| Field | Offset | What to read into it |
|---|---|---|
| File Signature | 0 | Four bytes, always LASF. Anything else is not a LAS file. |
| Global Encoding | 6 | A bit field. Bit 0 says whether GPS time is week time or adjusted standard time; bit 4 says the coordinate system is stored as WKT. |
| Version Major / Minor | 24 / 25 | 1.2, 1.3, 1.4, or since August 2025, 1.5. The version decides which record formats and class codes are legal. |
| System Identifier | 26 | 32 characters: the sensor for raw data, or MERGE, MODIFICATION, EXTRACTION, TRANSFORMATION for derived files. |
| Generating Software | 58 | 32 characters naming the package and version that wrote the file. The first thing to check when a delivery looks odd. |
| Header Size | 94 | 375 for LAS 1.4. Users may not extend it. |
| Offset to Point Data | 96 | Where the points begin. Everything between the header and this offset is variable length records. |
| Point Data Record Format | 104 | 0 to 10. Formats 6 to 10 are the modern ones; the legacy 0 to 5 cannot hold the utility or bridge classes. |
| Point Data Record Length | 105 | Bytes per point. Larger than the format's minimum means extra bytes are stored with each point. |
| Scale factors and offsets | 131 to 178 | Six doubles. A coordinate is the stored integer times the scale plus the offset. |
| Max and min X, Y, Z | 179 to 226 | The extent. Compare it to the block you expected to receive. |
| Number of Point Records | 247 | The 64-bit count, always populated in 1.4. The legacy 32-bit count at offset 107 is zero for formats 6 to 10. |
All offsets and sizes are from the LAS 1.4 specification's public header table [1]. Two fields deserve a longer look because they cause most of the surprises: the point data record format and the scale and offset.
The record format decides which classes exist
Formats 0 to 5 store the class in five bits, so they carry codes 0 to 31, and the specification defines only 0 to 12 of those, with 13 to 31 reserved [1]. Formats 6 to 10 store the class in a full byte and add a separate scanner channel and a proper overlap flag; the standard codes run to 22, including 13 to 16 for guard wires, conductors, transmission towers, and wire-structure connectors, 17 for bridge decks, 18 for high noise, and 19 to 22 for overhead structures, ignored ground, snow, and temporal exclusion, with 64 to 255 left for user-defined classes [1]. A corridor deliverable therefore has to arrive in format 6 or higher; a classifier asked to write wire classes into a format 1 file has nowhere legal to put them.
The minimum record lengths make the format visible at a glance: 30 bytes for format 6, 36 for format 7 with colour, 38 for format 8 with colour and near infrared, and 59 and 67 for the waveform formats 9 and 10 [1]. A record length larger than the minimum means extra bytes ride with every point, and an Extra Bytes record in the header describes them.
Scale and offset: why coordinates look wrong
Points are stored as 32-bit integers, not as real numbers. A coordinate is recovered as the stored value multiplied by the scale factor, plus the offset [1]. A scale of 0.01 keeps two decimal places; a scale of 0.001 keeps three. That is the whole precision budget of the file, and it is set by whoever wrote it. When a tool rewrites a block with a coarser scale, every coordinate is rounded and the change is invisible until someone overlays the result on the original. When it rewrites with a bad offset, the extent in the header no longer matches the points. Both are round-trip failures a reviewer can catch by comparing the six numbers before and after classification.
Variable length records: where the coordinate system lives
Between the header and the points sit the variable length records, each with a 54-byte header naming a user ID and a record ID [1]. The ones that matter for classification work are the coordinate system records. Under the user ID LASF_Projection, record 2112 holds the coordinate system as OGC well-known text, record 2111 an optional math transform, and records 34735, 34736, and 34737 the older GeoTIFF keys [1]. Formats 6 to 10 must use WKT, and a file with more than one GeoTIFF or more than one WKT record is in error [1]. Under LASF_Spec, record 4 is the Extra Bytes descriptor and record 0 the classification lookup, which LAS 1.5 has deprecated [1], [2]. Extended records of the same shape, with a 60-byte header, can follow the point data.
LAZ and COPC: two more records to look for
A LAZ file is a LAS file whose points are compressed, and the header is the same block. What marks it is one special record with the user ID laszip encoded and record ID 22204, whose payload names the compressor, the chunk size, and the item layout [3]. Chunking is what gives LAZ random access, and the modern compressor, number 3, is reserved for formats 6 to 10 [3]. A COPC file goes one step further: it is a LAZ 1.4 file whose points are organized in an octree, it may contain only formats 6, 7, or 8, and its copc info record, ID 1, must be the very first variable length record, starting at byte 375, with the octree hierarchy in a copc record of ID 1000 [4]. Any reader that handles chunked LAZ can read a COPC file sequentially; a reader that understands the hierarchy can fetch a spatial subset without touching the rest [4].
What changed with LAS 1.5
LAS 1.5 R00 was approved in August 2025, alongside a readability revision of 1.4 numbered R16 [1], [2]. The additions are worth knowing even if your tools still write 1.4: the legacy formats 0 to 5 are removed, the header gains minimum and maximum GPS time fields, the coordinate system must be WKT and GeoTIFF encoding is dropped, the Extra Bytes record must be unique, and the classification lookup record is deprecated [2]. A 1.5 file keeps header compatibility with 1.1 through 1.4, so the reading order above still applies [2].
A header checklist before classification
- Version 1.4 or later and point data record format 6 or higher, if the deliverable needs any class above 12.
- Scale factors that match the precision the contract expects, and offsets that place the extent where the block should be.
- Exactly one coordinate system record, WKT for formats 6 to 10, and the WKT bit set in the global encoding.
- A 64-bit point count that matches the delivery note, and points-by-return counts that look like the sensor you flew.
- For LAZ, the
laszip encodedrecord present; for COPC, thecopcinfo record first. - The same six numbers, record count, and coordinate system after classification as before.
Vecten reads LAS, LAZ, and COPC and writes classified LAS or LAZ that keeps the header, the coordinate system records, and the point flags of the input. Vecten Desktop does that on your own workstation; Vecten Cloud does the same in the browser.
Frequently asked questions
- How big is a LAS 1.4 header?
- 375 bytes for the public header block. Variable length records follow it, and the Offset to Point Data field says where the points begin.
- Which point data record format do I need for powerline classes?
- Format 6 or higher. Codes 13 to 16 for wires, towers, and connectors, and 17 for bridge decks, are defined only for formats 6 to 10.
- Is a COPC file still a LAZ file?
- Yes. COPC is a LAZ 1.4 file with points arranged in an octree and two extra records that describe it. Ordinary LAZ readers open it sequentially; COPC-aware readers use the hierarchy to fetch only the region they need.
- Why are my coordinates a few millimetres off after processing?
- Check the scale factors. If the output file uses a coarser scale than the input, every coordinate was rounded on write. The fix is to write with the input's scale and offset.
References
- [1] ASPRS, *LAS Specification 1.4 – R16*, The American Society for Photogrammetry & Remote Sensing, LAS Working Group, 2025. github.com/ASPRSorg/LAS
- [2] ASPRS, *LAS Specification 1.5 – R00*, The American Society for Photogrammetry & Remote Sensing, LAS Working Group, 2025. github.com/ASPRSorg/LAS
- [3] rapidlasso, *LAZ Specification 1.4 – Revision R1*, 2025. rapidlasso.de
- [4] Hobu, Inc., *Cloud Optimized Point Cloud (COPC) Specification 1.0*, 2021. copc.io
