LAS / LAZ: ASPRS Format for LiDAR Point Cloud Storage
LAS (LASer File Format) is the binary industry standard for storing point clouds, developed by ASPRS (American Society for Photogrammetry and Remote Sensing) in 2003 and effectively the universal LiDAR exchange format by the mid-2010s. Each point carries at minimum XYZ coordinates, intensity (returned pulse energy), return number, and a classification code from the ASPRS table — 2 for ground, 5 for high vegetation, 6 for buildings, 9 for water, and so on. On top of LAS sits LAZ — a lossless compression scheme developed by Martin Isenburg in the LASzip project; LAZ files are 5–15× smaller than raw LAS while remaining fully backward compatible, and today LAZ is the de facto way to publish LiDAR datasets on national open-data portals (USGS 3DEP, the Dutch AHN, Norway's lidar.no, swissSURFACE3D). OSM2CDR works with vector OSM data and does not produce LAS itself — point clouds are captured by LiDAR sensors, not extracted from OpenStreetMap tags. But LAS appears in our workflows as input for building classification, DTM construction via PDAL, and future integration with COPC exports.
History and evolution: from LAS 1.0 to 1.4
By the early 2000s airborne LiDAR had moved from experimental geodesy into mainstream topographic survey. Every sensor vendor (Leica, Optech, Riegl) had its own binary format, which made data exchange between contractors and customers painful. In 2003 ASPRS published LAS 1.0 — an open specification standardising the header, point data records, and class table. By 2005 every major sensor manufacturer supported LAS export.
LAS 1.1 (2005) introduced Variable Length Records (VLR) — a metadata section including CRS definition via GeoTIFF-style keys or WKT. LAS 1.2 (2008) added RGB channels for points (when LiDAR is combined with orthophoto — each point gets a real-world colour). LAS 1.3 (2010) brought waveform packets — the ability to store the full returned pulse waveform, not just discrete returns; critical for forestry, where waveform helps distinguish canopy layers.
LAS 1.4 (2013) is the latest revision and the current standard. Key changes: 64-bit point counters (vs 32-bit — previously capped at ~4 billion points, now practically unlimited), an extended classification table up to 256 classes (overlap points, transmission towers, and other domain-specific categories), extended return numbers up to 15 (needed for modern multi-pulse sensors), new Point Data Record Formats 6–10 with GPS timestamp and scanner channel. Most modern airborne and mobile LiDAR deliverables ship as LAS 1.4.
LAZ as a compression format emerged around 2010: Martin Isenburg (rapidlasso) developed an arithmetic-coding scheme tuned for LiDAR coordinate and attribute distributions. LAZ is not a separate format — it is a compression wrapper around LAS: same header, same VLRs, same point format, but point data packed into 50k-point chunks with an entropy coder. The laszip decompressor is LGPL-licensed; the encoder was initially commercial but went fully open-source in 2020.
LAS file structure
A LAS file is a binary with three major blocks: a fixed-length header, optional Variable Length Records (metadata), and an array of point data records. Points in LAS are typically sorted by GPS time or arbitrary order — there is no spatial index in the format itself. For fast spatial queries over LAS/LAZ, external indexes (lasindex / LAX files) are built, or COPC is used, which embeds an octree index directly into LAZ.
Public header block (375 bytes for LAS 1.4) contains the LASF magic, format version, project GUID, coordinate scales (scale_x/y/z — typically 0.01 for metre-coordinates with centimetre precision) and offsets, total point count, min/max bounding box, and per-class point counts. Coordinates are stored as int32 + scale + offset — packing large areas into 12 bytes per point without precision loss.
Variable Length Records (VLR) sit after the header. Each VLR has a user_id, record_id, and a variable-length payload. Standard VLRs: GeoTIFF/WKT projection definition (without it a LAS is just a cloud of numbers with no CRS), classification lookup, scanner metadata. LAS 1.4 also added Extended VLR (EVLR) — same VLRs but placed at the file's tail after the points, so metadata can be appended without rewriting the entire file.
Point Data Records is an array of fixed-length records. The layout depends on Point Data Record Format (0–10): PDRF 0 is the minimum (XYZ + intensity + return + classification + scan angle, 20 bytes); PDRF 2 adds RGB (26 bytes); PDRF 3 adds GPS time (34 bytes); PDRF 6 is the LAS 1.4 extended format at 30 bytes, supporting 256 classes and 15 returns; PDRF 7–10 mix in RGB, NIR, waveform packets. A typical 1 km² airborne dataset at 10 points/m² = 10M points × 28 bytes ≈ 280 MB in LAS, about 35 MB in LAZ.
ASPRS point classification
The standardised class table is what turns LAS from "a cloud of numbers" into a useful product. After capture, the raw cloud is run through a classification pipeline (manually in TerraScan / TerraSolid, or automatically via PDAL filters), and every point receives a class code from the ASPRS table:
| Class | Name | Description | Use |
|---|---|---|---|
| 0 | Created, never classified | Fresh import, no processing | Intermediate |
| 1 | Unclassified | Doesn't fit any category | Noise, artefacts |
| 2 | Ground | Earth surface | Basis for DTM |
| 3 | Low vegetation | Grass, shrubs < 0.5 m | Hydrology, fire risk |
| 4 | Medium vegetation | Shrubs 0.5–2 m | Forestry |
| 5 | High vegetation | Trees > 2 m | Tree census, CHM |
| 6 | Building | Walls and roofs | 3D-city models, BIM as-built |
| 7 | Low point (noise) | Below ground | Discarded |
| 9 | Water | Water surfaces | Hydrography |
| 10 | Rail | Rails | Transport infrastructure |
| 11 | Road surface | Pavement | DOT projects |
| 13–17 | Wire-related | Power lines, towers, conductors | Utility cadastre |
| 18 | High noise | Above expected ceiling | Birds, artefacts |
LAS 1.4 extends the range to 0–255 — codes 64–255 are reserved for user-defined classifications (OSM mapping, industry-specific categories: vehicles, oil pipelines, archaeological strata).
In practice 80% of useful LAS work is extracting subsets by class. Via PDAL: pdal translate input.laz ground.laz --filters.range=Classification[2:2] keeps only ground points. From those a DTM (Digital Terrain Model) is built — a raster of bare earth without buildings or vegetation. Class 6 (Buildings) after filtering yields footprints and roofs ready for polygon rectification and export to IFC or CityGML. Class 5 (High vegetation) is input for Canopy Height Models.
Tooling: PDAL, lastools, CloudCompare, Potree
PDAL (Point Data Abstraction Library) is the open-source GDAL-equivalent for point clouds. Pipeline-driven: you describe a JSON config with readers, filters and writers, then pdal pipeline config.json executes it in one pass. PDAL reads LAS/LAZ, E57, PCD, streams from COPC via HTTP Range Requests, runs classification filters (SMRF, PMF for ground; cloth simulation), decodes waveform, writes LAS/LAZ/COPC/EPT/3D Tiles. Most modern LiDAR pipelines are built on PDAL.
lastools (rapidlasso) is Martin Isenburg's suite: lasinfo, lasview, laszip, las2dem, lasground, lasclassify. Part of the toolkit is free (read, info, compress/decompress), part requires a commercial licence (advanced classification, automated DTM extraction). Lastools is historically faster than PDAL on huge datasets thanks to native C++ and tight memory handling, but less flexible: no pipeline config, every command is a separate run.
CloudCompare is a desktop GUI for visualising and interactively processing point clouds. Free, cross-platform. Opens LAS/LAZ of 100M+ points on a 32GB machine, supports interactive classification, segmentation, and registration (alignment) of multiple clouds. The standard QA tool: load LAS, eyeball ground/building separation, go back to a PDAL pipeline if it's off.
QGIS LAS plugin — since QGIS 3.18, native LAS/LAZ support via a PDAL backend: drop .laz into the project as a layer, render with raster symbolization by classification or elevation, do 2.5D visualisation. For web visualisation the industry standard is Potree: a WebGL viewer that consumes EPT/COPC and streams millions of points to the browser via octree LOD.
Workflow in OSM2CDR
LAS is not one of our export formats. OSM2CDR builds maps from vector OpenStreetMap data: roads, buildings, land use, POI, water. A point cloud is captured by a LiDAR sensor, not extracted from OSM tags. Accordingly, /api/render?format=las does not exist, and you won't find a LAS button in the Format Wizard.
But LAS shows up in our workflows from a different angle — as an external input the user can mix with OSM vectors to improve quality. A typical scenario:
Step 1: fetch public LAS. Download airborne LiDAR from a national portal: USGS 3DEP (USA), AHN (Netherlands, ~10 points/m² density), Geo.Admin (Switzerland swissSURFACE3D), Lantmäteriet (Sweden), GeoBretagne (France). Files usually ship as LAZ 1.4 tiles, 1×1 km each.
Step 2: classification and filtering via PDAL. If the LAS isn't classified — run ground extraction: pdal pipeline classify.json with a config describing filters.smrf (Simple Morphological Filter for ground) and filters.range for building separation by heuristics (height above ground > 2.5 m, planarity > 0.9). The output is a classified LAZ with proper classes 2 (ground), 5 (vegetation), 6 (buildings).
Step 3: DTM extraction. From ground-only points via pdal translate ... --writers.gdal or las2dem, build a raster DTM (GeoTIFF) — a bare-earth elevation model. The user loads this DTM into QGIS on top of the OSM map exported from osm2cdr.ru, getting a topographic backdrop under the OSM street grid.
Step 4: building rectification. Class 6 (Buildings) points can be rectified into polygonal roofs via PDAL + RANSAC plane fitting, or specialised tools like PointSerfer / BuildingDetector. Comparing the resulting footprints to OSM building=* polygons is a classic quality check of OSM data and a source of improvement suggestions for OpenStreetMap.
For cloud-native scenarios — when the cloud needs to stream into a web viewer or OGC API — we recommend converting LAZ to COPC (Cloud Optimized Point Cloud) right away. COPC is LAZ 1.4 with an octree index inside a VLR, letting an HTTP Range Request pull only the needed chunk. pdal translate input.laz output.copc.laz --writers.copc does the conversion in one pass. On the OSM2CDR roadmap — built-in COPC visualisation over vector OSM maps for cities with public LiDAR (Moscow, Berlin, Amsterdam).
Conclusion
LAS and LAZ are the pair of formats that have held up the entire industrial LiDAR exchange for the past 20 years. The ASPRS spec is open, the LAZ decompressor is LGPL, support in PDAL, lastools, QGIS and CloudCompare covers everything from raw import to classification, DTM generation and web visualisation via Potree. OSM2CDR doesn't export point clouds itself — that's not our formats domain — but we recommend LAS/LAZ as the bridge between public airborne LiDAR and our vector OSM maps: ground-only DTM as a topographic backdrop, building-class points as ground truth for OSM building checks. When you need a vector OSM export for a region where you already have a LiDAR capture — head to /formats/las/ to see how to set up the combined workflow.
Related
- COPC — Cloud Optimized Point Cloud for web LiDAR streaming
- 3D Tiles — format for visualising large 3D scenes in the browser
- STL — mesh format for printing and modelling buildings
Sources
- ASPRS LAS 1.4 Specification — asprs.org/wp-content/uploads/2019/07/LAS_1_4_r15.pdf
- PDAL documentation — pdal.io
- LASzip / rapidlasso — laszip.org
- USGS 3DEP LiDAR data — usgs.gov/3d-elevation-program
- AHN (Netherlands LiDAR) — ahn.nl