|Introduction | Sustainability Factors | Content Categories | Format Descriptions | Contact|
|Full name||LAS (LASer) File Format, Version 1.4|
LAS is a file format for the interchange of 3-dimensional point cloud data. Although developed primarily for exchange of lidar point cloud data, this format supports the exchange of any 3-dimensional x,y,z tuplet data. Lidar uses ultraviolet, visible, or near infrared light to image objects and instruments fitted to aircraft and satellites use lidar for surveying and mapping. See Notes below for more on lidar and point clouds. The LAS specification was developed and is maintained as a public specification by the American Society for Photogrammetry and Remote Sensing (ASPRS). USGS has established the 3D Elevation Program (3DEP), which will generate lidar data for the entire continental United States and Hawaii, using the LAS 1.4 format to deliver raw point cloud data. The data is used to derive images and 3D surface models.
The introduction to the LAS format from ASPRS explains the rational for developing the format: "This binary file format is an alternative to proprietary systems or a generic ASCII file interchange system used by many companies. The problem with proprietary systems is obvious in that data cannot be easily taken from one system to another. There are two major problems with the ASCII file interchange. The first problem is performance because the reading and interpretation of ASCII elevation data can be very slow and the file size can be extremely large, even for small amounts of data. The second problem is that all information specific to the lidar data is lost. The LAS file format is a binary file format that maintains information specific to the lidar nature of the data while not being overly complex." Numbers in LAS are stored in binary form to save space and to eliminate the processing time needed to convert numbers in ASCII to a form usable for calculation. See Notes below for more details on number formats used in LAS.
The LAS format consists of four types of record. All data are binary in little-endian format. Version 1.4 is based on a 64-bit file structure. The record types are listed here in the order found in a LAS file.
Features added with version 1.4 include:
|Production phase||A middle-state format for data interchange. Also used for archiving point cloud data.|
|Relationship to other formats|
|Has earlier version||Versions 1.0 through 1.3, not described separately on this site. Versions through 1.3 used a 32-bit file structure.|
|Equivalent to||LAZ, a losslessly compressed variant of LAS. LASzip compresses the point data using mechanisms appropriate to the different elements of the data and typical characteristics.|
|LC experience or existing holdings||The Congressional Cartography Program of the Library of Congress has limited experience using LIDAR point cloud data in the LAS format to prepare maps for Congress or the Congressional Research Service.|
|Disclosure||Publicly available standard developed and maintained by the American Society for Photogrammetry and Remote Sensing (ASPRS). Intended for use without license.|
|Documentation||All versions of the LAS File Format Specification are available from LASer (LAS) File Format Exchange Activities at ASPRS. As of January 2015, the latest version is Revision 13, July 2013.|
Widely used for lidar point cloud data. See Introduction to Lidar, a tutorial slideshow from Open Topography. Although point cloud data can be described in ASCII text files, such files are very clumsy to use, because of the time required to import data and convert the numbers to binary for analysis. In practice, lidar point cloud datasets are usually shared in LAS files or losslessly compressed derivatives of LAS.
The National Geospatial Program: Lidar Base Specification, ver. 1.2, November 2014 requires (on page 6) that "All processing will be carried out with the understanding that all point deliverables are required to be fully compliant with ASPRS LAS Specification, version 1.4, using Point Data Record Format 6, 7, 8, 9 or 10.
Software libraries available for manipulation of data in the LAS format include: LAStools, a suite of batch-scriptable, multicore command line tools, that can also be run in a native GUI and are available as a LiDAR processing toolboxes for ArcGIS and QGIS; Laspy, a python interface for reading/modifying/creating .LAS lidar files matching specification 1.0-1.4.; and PDAL, a C++ library intended to support data translation.
LAS 1.4 is used as a distribution format for data generated by the 3D Elevation Program (3DEP). The 3DEP initiative, under USGS and the National Map, is gathering lidar data to support generation of high-quality topographic data and other three-dimensional representations of the nation's natural and constructed features. The primary goal of 3DEP is to systematically collect enhanced elevation data in the form of high-quality light detection and ranging (lidar) data over the continental United States, Hawaii, and the U.S. territories, with data acquired over an 8-year period. Interferometric synthetic aperture radar (ifsar) data will be collected over Alaska, where cloud cover and remote locations preclude the use of lidar.
|Licensing and patents||No concerns. Developed by ASPRS as a publicly usable format.|
|Transparency||A binary format. Not easily viewable by human readers, but using a very straightforward structure for which developing software for basic data extraction would be simple.|
|Self-documentation||The header provides basic metadata to support identification of the file and retrieval of data. Richer metadata can be included as VLR or EVLR records.|
|External dependencies||None beyond LAS-aware software.|
|Technical protection considerations||The format provides no mechanism for technical protection of the data.|
Not a general-purpose dataset format. Designed for point cloud data. Includes mechanisms for holding x,y,z values at different scales.
See Notes for details on data types used in LAS.
|Data documentation (quality, provenance, etc.)||The LAS format provides two mechanisms that can be used to document the provenance and quality of the data. Several fields in the header contribute to identification of the project or lidar-gathering flight from which the data come, the software that generated the file, and the file creation date. Other metadata or a textual description of the file can be embedded in a LAS file using VLR or EVLR records. According to Rein in 3D Point Clouds with the LAS Format, "Starting in version 1.1, the LAS format specification has allowed users to specify the software that generated the file, or that a particular point is synthetic instead of originating from LiDAR sensor data. These metadata attributes are particularly useful for instances where the data doesn’t come from a LiDAR sensor, which is more frequently the case now."|
|GIS images and datasets|
|Normal functionality||Designed specifically for delivery of point cloud data, and generated via equipment on aircraft or satellites in swaths determined by flight paths. Georeferencing information is mandatory, with coordinate reference system recorded either using Well Known Text (preferred in LAS 1.4) or appropriate tags from the GeoTiff specification.|
|Support for GIS metadata||Could be included in a LAS file using VLR or EVLR records.|
|Support for grids||As data expressed as values at points in three dimensions, the data in a LAS file is not directly usable for grid-based analysis. However, tools exist to aggregate data points in cells in a two-dimensional grid.|
|Beyond normal functionality||The format allows for the addition, as EVLR records, the waveform data associated with the returns from laser pulses.|
||The file extension is not mandated in the specification. However, it is specified in the Lidar Base Specification from USGS, which is the specification in use for the National Map 3DEP data.|
||In first 4 bytes of the file. From specification.|
|Indicator for profile, level, version, etc.||Bytes 25 and 26 of the header block are for major and minor version numbers for the LAS specification.|
|Pronom PUID||See note.||PRONOM, using the name ASPRS Lidar Data Exchange Format, has records for LAS 1.0 (http://www.nationalarchives.gov.uk/PRONOM/fmt/368), LAS 1.1 (http://www.nationalarchives.gov.uk/PRONOM/fmt/369), and LAS 1.2 (http://www.nationalarchives.gov.uk/PRONOM/fmt/370), but not for later versions of the LAS specification.|
|Wikidata Title ID||Q33515758
A useful description of how lidar data is gathered is in Lidar 101 from NOAA's Digital Coast program: "When an airborne laser is pointed at a targeted area on the ground, the beam of light is reflected by the surface it encounters. A sensor records this reflected light to measure a range. When laser ranges are combined with position and orientation data generated from integrated GPS and Inertial Measurement Unit systems, scan angles, and calibration data, the result is a dense, detail-rich group of elevation points, called a 'point cloud.' Each point in the point cloud has three-dimensional spatial coordinates (latitude, longitude, and height) that correspond to a particular point on the Earth's surface from which a laser pulse was reflected. The point clouds are used to generate other geospatial products, such as digital elevation models, canopy models, building models, and contours."
Point records of types 0-10 are specified in LAS 1.4. In the list below, Core-0 and Core-6 are not terms from the specification, but used here as shorthand.
The core data of a point record includes a "Classification" byte, a numerical code which represents an interpretation of the point as of a class. Examples of predefined classes are "ground," "low vegetation," "building," "road surface," etc.
The binary LAS format incorporates data types conformant to the 1999 ANSI C Language Specification (ANSI/ISO/IEC 9899:1999 ("C99"): char (1 byte); unsigned char (1 byte); short (2 bytes); unsigned short (2 bytes); long (4 bytes); unsigned long (4 bytes); long long (8 bytes); unsigned long long (8 bytes); float (4 byte IEEE floating point format); double (8 byte IEEE floating point format); string (a variable series of 1 byte characters, ASCII encoded, null terminated).
LAS, Version 1.4 introduced the concept of a Domain Profile, a derivative of the base LAS specification that adds (but does not remove or alter existing) point classes and attributes to meet the application-specific needs of a particular subset of the broad lidar community (e.g., the coastal/bathymetric lidar community, or the powerline mapping community). New classes can be added to Point Data Record Formats 6-10. New attributes must be incorporated using Extra Bytes VLRs.
LAS files can be very large despite the binary nature of the format. Two formats that compress LAS in a lossless fashion and tailored to characteristics of the data exist. The LAZ format was informally documented in LASzip: lossless compression of LiDAR data, by Martin Isenburg in 2011, and is usable through the open source LASzip software library. Several agencies distribute data in the LAZ format. In early 2014, ESRI introduced its own lossless compression format, zLAS. Open data supporters raise objections to the introduction of this proprietary format. See for example, Esri Announces LAS Compression (Jan 4, 2014) and FAQ on Esri LAS Optimizer (Jan 12, 2014) from the LiDAR News blog. In LAS Optimizer 1.2, ESRI explains "zLAS files are much smaller and more efficient to use, especially on the cloud and over networks, than regular LAS." The compilers of this resource are not aware of detailed technical or functional reasons that motivated ESRI to introduce the new format rather than use LAZ. Comments welcome. According to March 2015 post from LiDAR News blog, ESRI released a software toolit for reading and writing zLAS files and converting between zLAS and LAS.
Since version 1.4 of the LAS File Format Specification was approved in November, 2011, minor revisions have been issued: