Anl7_LAS-Spezifikation_V1-4_2019-03-26.pdf

[Seite 1]

LAS Specification 1.4 - R14

Release Information:

VersionApproved–November2011 Revisiondate–26March2019

PDFbuilddate–26March2019 GitHubcommit–2ea0a5b46bbca1c05d7a7e0827ebf0eb660aead5 GitHubrepo–https://github.com/ASPRSorg/LAS

Published by:

TheAmericanSocietyforPhotogrammetry&RemoteSensing 425BarlowPlace,Suite210 Bethesda,Maryland20814-2160 Voice: 301-493-0290 Fax: 225-408-4422 Web: www.asprs.org

Copyright © 2002-2019 American Society for Photogrammetry and Remote Sensing (ASPRS). Allrightsreserved.

Permission to Use: The copyright owner hereby consents to unlimited use and distribution of this document, or parts thereof, asaspecification provided such use references ASPRS as the publisher. This consent does not extend to other uses such as general distribution in any form, including electronic, by any individual or organization whether for advertising or promotional purposes, for creating new collective works, or for resale. For these and all other purposes, reproduction of this publication or any part thereof (excluding short quotations for use in the preparation of reviews and technical and scientific papers) may be made only after obtaining the specificapprovalofthepublisher.

PrintedintheUnitedStatesofAmerica.

[Seite 2]

CONTENTS:

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Purpose,Scope,andApplicability . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 LAS1.4RevisionHistory . . . . . . . . . . . . . . . . . . . . . 1 1.1.2 ComparisonofLAS1.4toPreviousVersions . . . . . . . . . . . 2 1.2 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.1 ASPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3.2 OGC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 LASFormatDefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 LegacyCompatibility(LAS1.1-LAS1.3) . . . . . . . . . . . . . . . . 5 2.2 CoordinateReferenceSystem(CRS)Representation . . . . . . . . . . . 6 2.3 DataTypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 PublicHeaderBlock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 VariableLengthRecords(VLRs) . . . . . . . . . . . . . . . . . . . . . . 13 2.6 PointDataRecords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6.1 PointDataRecordFormat0 . . . . . . . . . . . . . . . . . . . . 15 2.6.2 PointDataRecordFormat1 . . . . . . . . . . . . . . . . . . . . 21 2.6.3 PointDataRecordFormat2 . . . . . . . . . . . . . . . . . . . . 22 2.6.4 PointDataRecordFormat3 . . . . . . . . . . . . . . . . . . . . 23 2.6.5 PointDataRecordFormat4 . . . . . . . . . . . . . . . . . . . . 24 2.6.6 PointDataRecordFormat5 . . . . . . . . . . . . . . . . . . . . 26 2.6.7 PointDataRecordFormat6 . . . . . . . . . . . . . . . . . . . . 27 2.6.8 PointDataRecordFormat7 . . . . . . . . . . . . . . . . . . . . 32 2.6.9 PointDataRecordFormat8 . . . . . . . . . . . . . . . . . . . . 33 2.6.10 PointDataRecordFormat9 . . . . . . . . . . . . . . . . . . . . 34 2.6.11 PointDataRecordFormat10 . . . . . . . . . . . . . . . . . . . 35 2.7 ExtendedVariableLengthRecords(EVLRs) . . . . . . . . . . . . . . . . 36 2.7.1 LegacyCompatibilityforEVLRs . . . . . . . . . . . . . . . . . 36 3 CoordinateReferenceSystemVLRs(Required) . . . . . . . . . . . . . . . . . . 37 3.1 CoordinateReferenceSystemInformation . . . . . . . . . . . . . . . . . 37 3.2 GeoreferencingInformationUsingWKT . . . . . . . . . . . . . . . . . 37 3.2.1 OGCMathTransformWKTRecord . . . . . . . . . . . . . . . 37 3.2.2 OGCCoordinateSystemWKTRecord . . . . . . . . . . . . . . 38

i

[Seite 3]

3.3 GeoreferencingInformationUsingGeoTIFF . . . . . . . . . . . . . . . . 38 3.3.1 GeoKeyDirectoryTagRecord . . . . . . . . . . . . . . . . . . . 38 3.3.2 GeoDoubleParamsTagRecord(Optional) . . . . . . . . . . . . . 39 3.3.3 GeoAsciiParamsTagRecord(Optional) . . . . . . . . . . . . . . 40 4 OtherSpecificationDefinedVLRs(Optional) . . . . . . . . . . . . . . . . . . . . 41 4.1 ClassificationLookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 TextAreaDescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.3 ExtraBytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.4 Superseded . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.5 WaveformPacketDescriptor . . . . . . . . . . . . . . . . . . . . . . . . 44 5 DefinedExtendedVariableLengthRecords(EVLRs) . . . . . . . . . . . . . . . . 46 5.1 WaveformDataPackets . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6 LASDomainProfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1 LASDomainProfileDescription . . . . . . . . . . . . . . . . . . . . . . 47

ii

[Seite 4]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

1 Introduction

1.1 Purpose, Scope, and Applicability

TheLASfileisintendedtocontainlidar(orother)pointclouddatarecords. Thedatawillgenerally be putinto thisformat fromsoftware (e.g., providedby hardwarevendors), which combinesGPS, IMU,andlaserpulserangedatatoproduceX,Y,andZpointdata. Theintentionofthedataformat is to provide an open format that allows different hardware and software tools to output data in a commonformat.

This document reflects the fourth revision of the LAS format specification since its initial version 1.0release.

1.1.1 LAS 1.4 Revision History

SummaryofLAS1.4revisions(GitHubIssuenumbersincludedwhenapplicable):

• R11-ApprovedVersion(Nov2011). • R12-Errata(June2012)-Typographicalcorrections: – CorrectedPublicHeaderSizeindescriptiveparagraphto375bytes. – CorrectedtwoinstancesofScanAngleRankfrom“UnsignedChar”to“Char”. • R13-AddedDomainProfileSection(July2013). • R14-Multipleupdates(March2019): – AestheticchangesfrommigrationtoGitHub – Multiplecapitalization&typocorrections. – UpdatedASPRScontactinfo. (I-305) – Additionalstandardclassifications19-22forPDRFs6-10: (I-116,I-267)

• Class19–OverheadStructureinPDRFs6-10.
• Class20–IgnoredGround.
• Class21–Snow.
• Class22–TemporalExclusion. – AddedOGCendorsement. (I-318) – AddedminimumPDRFsizestoattributetables. (I-479) – Sectionreorganization: (I-5710)
• AdditionofTableofContentswithsectionnumbers. (c.f. I-2711,I-4912)
• DividedDefinedVariableLengthRecordssectionintoCoordinateReferenceSys- temVLRssection(s3)andOtherSpecificationDefinedVLRs(s4).

5https://github.com/ASPRSorg/LAS/issues/30 6https://github.com/ASPRSorg/LAS/issues/11 7https://github.com/ASPRSorg/LAS/issues/26 8https://github.com/ASPRSorg/LAS/issues/31 9https://github.com/ASPRSorg/LAS/issues/47 10https://github.com/ASPRSorg/LAS/issues/57 11https://github.com/ASPRSorg/LAS/issues/27 12https://github.com/ASPRSorg/LAS/issues/49

1. INTRODUCTION Page1

[Seite 5]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

• Expanded EVLR discussion in Legacy Compatibility section (s2.1) and moved LegacyCompatibilitysectiontoEVLRdefinition(nows2.7.1).
• Swapped order of LAS 1.4 Revision History (now s1.1.1) and LAS 1.4 Additions (nows1.1.2).
• RearrangedparagraphsinExtraBytesVLRdescription. – Deprecated“tuple”and“triple”extrabytedatatypes. (I-113)
• Addedexplanationandexampleofimplicitarraysfromdescriptornames. – ClarifiedthatExtraBytemin/maxshouldbeanuntransformedvalue. (I-414) – Clarified that Legacy Point Counts should be set to zero if using non-legacy PDRFs. (I-1215) – ClarifiedFullWaveformdescriptionsandaddedwikilink. (I-916) – RenamedX(t),Y(t),andZ(t)fromwaveformpacketstoParametricdx/dy/dz. – PDRF9nowcorrectlyrequiresScannerChannellikeotherPDRFs. (I-2917) – Clarifiedorigindate/timeforAdjustedStandardGPSTime. (I-4018) – Clarified null-termination of fixed-length char arrays, especially VLR Description. (I-4619) – ClarifiedrelationshipbetweenFileSourceIDandPointSourceID.(I-5920) – Added language to support technologies other than conventional linear-mode lidar scanners. (I-3521)
• ClarifiedandrenamedSyntheticReturnNumbersGlobalEncodingbit.
• ClarifiedSyntheticpointclassificationflag.
• Clarifiedvalidityofzero-valuePointSourceID.
• Unified Return Number and Number of Returns descriptions between legacy and non-legacyPDRFs.
• ClarifiedScanDirectionandEdgeofFlightLineFlagsfornon-rotationalsystems. – AddedwikilinkforProjectIDexamples. (I-3822)

For detailed information on changes in revisions R14 and newer, review the inline differencing providedontheGitHubpage23.

1.1.2 Comparison of LAS 1.4 to Previous Versions

TheadditionsofLAS1.4include:

• Backward compatibility with LAS 1.1 – LAS 1.3 when payloads consist of only legacy

13https://github.com/ASPRSorg/LAS/issues/1 14https://github.com/ASPRSorg/LAS/issues/4 15https://github.com/ASPRSorg/LAS/issues/12 16https://github.com/ASPRSorg/LAS/issues/9 17https://github.com/ASPRSorg/LAS/issues/29 18https://github.com/ASPRSorg/LAS/issues/40 19https://github.com/ASPRSorg/LAS/issues/46 20https://github.com/ASPRSorg/LAS/issues/59 21https://github.com/ASPRSorg/LAS/issues/35 22https://github.com/ASPRSorg/LAS/issues/38 23https://github.com/ASPRSorg/LAS

1. INTRODUCTION Page2

[Seite 6]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

content • LAS1.4modewhichsupports: – Extensionofoffsetsandfieldsizestosupportfull64bit – Supportforupto15returnsperoutgoingpulse – ExtensionofthePointClassfieldtosupport256classes – DefinitionofseveralnewASPRSstandardclasses – ExtensionoftheScanAnglefieldto2bytestosupportfinerangleresolution – AdditionofaSensorChannelbitfieldtosupportmobilemappingsystems – AdditionofWellKnownText(WKT)definitionsforCoordinateReferenceSystems – AdditionofanOverlapbittoallowindicatingpulsesintheoverlapregionwhilemain- tainingtheclassdefinition – Addition of an (optional) Extra Byte Variable Length Record to describe “extra bytes” storedwitheachpoint • Otherminorchanges: – Addeddefinitionsfor“LASDomainProfile”and“LASDomainProfileDescription” – AddedlinkstoofficialLASwiki: https://github.com/ASPRSorg/LAS/wiki

1.2 Conformance

The data types used in the LAS format definition are conformant to the 1999 ANSI C Language Specification(ANSI/ISO/IEC9899:1999(“C99”).

1.3 Authority

1.3.1 ASPRS

The American Society for Photogrammetry & Remote Sensing (ASPRS) is the owner of the LAS Specification. Thestandardismaintainedbycommitteeswithintheorganizationasdirectedbythe ASPRSBoardofDirectors. QuestionsrelatedtothisstandardcanbedirectedtoASPRS:

• Onlineathttps://github.com/ASPRSorg/LAS • Byphoneat301-493-0290 • Byemailatlas@asprs.orgorasprs@asprs.org • Bymailat425BarlowPlace,Suite210,Bethesda,Maryland20814-2160.

1.3.2 OGC

LAS has been recognized by the Open Geospatial Consortium (OGC24) in 2018 as an OGC Community Standard. The OGC version of the document with forward material about stan- dards that LAS references and its status within the standard body can be found at https://portal. opengeospatial.org/files/17-030r1.

24http://www.opengeospatial.org

1. INTRODUCTION Page3

[Seite 7]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Future recognition and activity on OGC referencing activities of LAS can be followed at http: //www.opengeospatial.org/standards/community.

1. INTRODUCTION Page4

[Seite 8]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2 LAS Format Definition

The format contains binary data consisting of a public header block, any number of (optional) VariableLengthRecords(VLRs),thePointDataRecords,andanynumberof(optional)Extended Variable Length Records (EVLRs). All data are in little-endian format. The public header block containsgenericdatasuchaspointnumbersandpointdatabounds. Werefertothedatacontentof thefileasthe“payload.”

The Variable Length Records (VLRs) contain variable types of data including projection informa- tion,metadata,waveformpacketinformation,anduserapplicationdata. Theyarelimitedtoadata payloadof65,535bytes.

The Extended Variable Length Records (EVLRs) allow a higher payload than VLRs and have the advantage that they can be appended to the end of a LAS file. This allows, for example, adding projectioninformationtoaLASfilewithouthavingtorewritetheentirefile.

Table1: LAS1.4FormatDefinition PublicHeaderBlock VariableLengthRecords(VLRs) PointDataRecords ExtendedVariableLengthRecords(EVLRs)

A LAS file that contains point record types 4, 5, 9, or 10 could potentially contain one block of waveform data packets that is stored as the payload of any Extended Variable Length Record (EVLR).UnlikeotherEVLRs,theWaveformDataPackets(ifstoredinternallytothefile)havethe offset to the storage header contained within the Public Header Block (“Start of Waveform Data PacketRecord”).

2.1 Legacy Compatibility (LAS 1.1 - LAS 1.3)

LAS 1.4 moves the file specification from a 32 bit file structure (maximum value of 232 − 1 ≡ 4,294,967,295 ≡ UINT32_MAX)toa64bitfilestructure(264 −1).

To maintain the ability to place a LAS 1.1 through LAS 1.3 payload (point record types 0-5, Geo- TIFFcoordinatereferencesystem,referredtoas“Legacy”payloads)inaLAS1.4filestructure,it isnecessarytoduplicatesomeofthefieldswithintheLAS1.4filestructure. Theseduplicatefields arenamed“Legacyxxx”where“xxx”denotesthemeaningofthefield.

A LAS 1.4 file writer who wishes to maintain backward compatibility must maintain both the legacyfieldsandtheequivalentnon-legacyfieldsinsynchronization. However,thisisnotpossible ifthenumberofpointsexceedsUINT32_MAX,inwhichcasethelegacyfieldsmustbesettozero. If a file writer is not maintaining backward compatibility, the legacy fields must always be set to zero.

2. LASFORMATDEFINITION Page5

[Seite 9]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Ifthereisadiscrepancybetweenanon-zerolegacyfieldandtheequivalentLAS1.4field,theLAS 1.4 reader should use the legacy value to maintain the same behavior as a LAS 1.1 through LAS 1.3reader. Bestpracticeistoalsothrowaninformativeerrorsothatthefilecanberepaired.

LAS 1.4 introduced the option to define Variable Length Records (VLRs) as Extended Variable Length Records (EVLRs) instead. A LAS 1.4 file writer wishing to maintain backward compati- bilitymustuseonlyVLRs. SeetheLegacyCompatibilityforEVLRssectionformoreinformation.

2.2 Coordinate Reference System (CRS) Representation

GeoTIFF is being replaced by Well Known Text (WKT) as the required Coordinate Reference System(CRS)representationforthenewpointtypes(6-10)introducedbyLAS1.4.

GeoTIFFismaintainedforlegacyreasonsforpointtypes0-5.

A“WKT”bithasbeenaddedtotheGlobalEncodingflaginthePublicHeaderBlock. Ifthisbitis set, the CRS for the file will be located in the WKT (Extended) Variable Length Records (EVLR, VLR).

A file writer who desires to maintain backward compatibility with legacy LAS for point types 0-5 mustaddaGeoTIFFVLRtorepresenttheCRSforthefileandensurethattheWKTbitisfalse.

TheCRSrepresentationissummarizedbelow:

Table2: CoordinateReferenceSystemRepresentation

It is considered a file error to have more than one GeoTIFF (E)VLR or more than one WKT (E)VLR in the file. A writer can append a new CRS EVLR to a file by “superseding” the ex- isting CRS (E)VLR. Superseding is performed by changing the LAS_Spec ID of the record to “Superseded”,anewLASF_Specdefinedinthisrelease.

2. LASFORMATDEFINITION Page6

[Seite 10]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.3 Data Types

The following data types are used in the LAS format definition. Note that these data types are conformanttothe1999ANSICLanguageSpecification(ANSI/ISO/IEC9899:1999(“C99”)).

• char(1byte) • unsignedchar(1byte) • short(2bytes) • unsignedshort(2bytes) • long(4bytes) • unsignedlong(4bytes) • longlong(8bytes) • unsignedlonglong(8bytes) • float(4byteIEEEfloatingpointformat) • double(8byteIEEEfloatingpointformat) • string(avariableseriesof1bytecharacters,ASCIIencoded,null-terminated)

Warning: Fixed-length char arrays will not be null-terminated if all bytes are utilized. Examples include the System Identifier and Generating Software in the LAS Header, the User IDorDescriptionintheVariableLengthRecord,andtheNameofanExtraByteDescriptor.

2. LASFORMATDEFINITION Page7

[Seite 11]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.4 Public Header Block

Table3: PublicHeaderBlock

Continued on next page

2. LASFORMATDEFINITION Page8

[Seite 12]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table 3 – continued from previous page

Note: AnyfieldinthePublicHeaderBlockthatisnotrequiredandisnotusedmustbezerofilled.

FileSignature

The file signature must contain the four characters “LASF”, and it is required by the LAS specifi- cation. Thesefourcharacterscanbecheckedbyusersoftwareasaquicklookinitialdetermination offiletype.

FileSourceID

This field should be set to a value from 0 to 65,535. A value of zero is interpreted to mean that an ID has not been assigned, which is the norm for a LAS file resulting from an aggregation of multipleindependentsources(e.g.,atilemergedfrommultipleswaths).

Note that this scheme allows a project to contain up to 65,535 unique sources. Example sources can include a data repository ID or an original collection of temporally consistent data such as a flight line or sortie number for airborne systems, a route number for mobile systems, or a setup identifierforstaticsystems.

GlobalEncoding

This is a bit field used to indicate certain global properties about the file. In LAS 1.2 (the version in which this field was introduced), only the low bit is defined (this is the bit, that if set, would havetheunsignedintegeryieldavalueof1). Thisbitfieldisdefinedas:

2. LASFORMATDEFINITION Page9

[Seite 13]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table4: GlobalEncoding–BitFieldEncoding

ProjectID(GUIDData)

The four fields that comprise a complete Globally Unique Identifier (GUID) are now reserved for use as a Project Identifier (Project ID). The field remains optional. The time of assignment of the Project ID is at the discretion of processing software. The Project ID should be the same for all filesthatareassociatedwithauniqueproject. ByassigningaProjectIDandusingaFileSourceID (defined above) every file within a project and every point within a file can be uniquely identified, globally.

Note: ExampleimplementationsofrepresentingtheProjectIDfieldsasaGUIDcanbefoundon theofficialLASwiki: https://github.com/ASPRSorg/LAS/wiki

VersionNumber

The version number consists of a major and minor field. The major and minor fields combine to

2. LASFORMATDEFINITION Page10

[Seite 14]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

form the number that indicates the format number of the current specification itself. For example, specification number 1.4 would contain 1 in the major field and 4 in the minor field. It should be noted that the LAS Working Group does not associate any particular meaning to major or minor versionnumber.

SystemIdentifier

The version 1.0 specification assumed that LAS files are exclusively generated as a result of col- lectionbyahardwaresensor. Subsequentversionsrecognizethatfilesoftenresultfromextraction, merging,ormodifyingexistingdatafiles. ThusSystemIDbecomes:

Table5: SystemIdentifier

GeneratingSoftware

This information is ASCII data describing the generating software itself. This field provides a mechanism for specifying which generating software package and version was used during LAS filecreation(e.g.,“TerraScanV-10.8”,“REALMV-4.2”,etc.). Ifthecharacterdataislessthan32 characters,theremainingdatamustbenull.

FileCreationDayofYear

Day, expressed as an unsigned short, on which this file was created. Day is computed as the GreenwichMeanTime(GMT)day. January1isconsideredday1.

FileCreationYear

Theyear,expressedasafourdigitnumber,inwhichthefilewascreated.

HeaderSize

The size, in bytes, of the Public Header Block itself. For LAS 1.4 this size is 375 bytes. In the event that the header is extended by a new revision of the LAS specification through the addition of data at the end of the header, the Header Size field will be updated with the new header size. ThePublicHeaderBlockmaynotbeextendedbyusers.

OffsettoPointData

The actual number of bytes from the beginning of the file to the first field of the first point record datafield. Thisdataoffsetmustbeupdatedifanysoftwareadds/removesdatato/fromtheVariable

2. LASFORMATDEFINITION Page11

[Seite 15]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

LengthRecords.

NumberofVariableLengthRecords

This field contains the current number of VLRs that are stored in the file preceding the Point Data Records. ThisnumbermustbeupdatedifthenumberofVLRschanges.

PointDataRecordFormat

Thepointdatarecordindicatesthetypeofpointdatarecordscontainedinthefile. LAS1.4defines types0through10. ThesetypesaredefinedinthePointDataRecordssectionofthisspecification.

PointDataRecordLength

Thesize,inbytes,ofthePointDataRecord. AllPointDataRecordswithinasingleLASfilemust bethesametypeandhencethesamelength. Ifthespecifiedsizeislargerthanimpliedbythepoint format type (e.g., 32 bytes instead of 28 bytes for type 1) the remaining bytes are user-specific “extrabytes”. Theformatandmeaningofsuch“extrabytes”can(optionally)bedescribedwithan ExtraBytesVLR.

LegacyNumberofPointRecords

Thisfieldcontainsthetotalnumberofpointrecordswithinthefileifthefileismaintaininglegacy compatibility, the number of points is no greater than UINT32_MAX, and the Point Data Record Formatislessthan6. Otherwise,itmustbesettozero.

LegacyNumberofPointsbyReturn

These fields contain an array of the total point records per return if the file is maintaining legacy compatibility, the number of points is no greater than UINT32_MAX, and the Point Data Record Formatislessthan6. Otherwise,eachmemberofthearraymustbesettozero.

The first value will be the total number of records from the first return, the second contains the totalnumberforreturntwo,andsoonuptofivereturns.

X,Y,andZScaleFactors

The scale factor fields contain a double floating point value that is used to scale the corresponding X,Y,andZlongvalueswithinthepointrecords. ThecorrespondingX,Y,andZscalefactormust be multiplied by the X, Y, or Z point record value to get the actual X, Y, or Z coordinate. For example, if the X, Y, and Z coordinates are intended to have two decimal digits, then each scale factorwillcontainthenumber0.01.

X,Y,andZOffsets

The offset fields should be used to set the overall offset for the point records. In general these numberswillbezero,butforcertaincasestheresolutionofthepointdatamaynotbelargeenough foragivenprojectionsystem. However,itshouldalwaysbeassumedthatthesenumbersareused. So to scale a given X from the point record, take the point record X multiplied by the X scale factor,andthenaddtheXoffset.

2. LASFORMATDEFINITION Page12

[Seite 16]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

𝑋 = (𝑋 *𝑋 )+𝑋 (1) 𝑐𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒 𝑟𝑒𝑐𝑜𝑟𝑑 𝑠𝑐𝑎𝑙𝑒 𝑜𝑓𝑓𝑠𝑒𝑡 𝑌 = (𝑌 *𝑌 )+𝑌 (2) 𝑐𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒 𝑟𝑒𝑐𝑜𝑟𝑑 𝑠𝑐𝑎𝑙𝑒 𝑜𝑓𝑓𝑠𝑒𝑡 𝑍 = (𝑍 *𝑍 )+𝑍 (3) 𝑐𝑜𝑜𝑟𝑑𝑖𝑛𝑎𝑡𝑒 𝑟𝑒𝑐𝑜𝑟𝑑 𝑠𝑐𝑎𝑙𝑒 𝑜𝑓𝑓𝑠𝑒𝑡

MaxandMinX,Y,andZ

ThemaxandmindatafieldsaretheactualunscaledextentsoftheLASpointfiledata,specifiedin thecoordinatesystemoftheLASdata.

StartofWaveformDataPacketRecord

This value provides the offset, in bytes, from the beginning of the LAS file to the first byte of the WaveformDataPackageRecord. NotethatthiswillbethefirstbyteoftheWaveformDataPacket header. Ifnowaveformrecordsarecontainedwithinthefileortheyarestoredexternally,thisvalue must be zero. It should be noted that LAS 1.4 allows multiple Extended Variable Length Records (EVLRs)andthattheWaveformDataPacketRecordisnotnecessarilythefirstEVLRinthefile.

StartofFirstExtendedVariableLengthRecord

This value provides the offset, in bytes, from the beginning of the LAS file to the first byte of the firstEVLR.

NumberofExtendedVariableLengthRecords

ThisfieldcontainsthecurrentnumberofEVLRs(including,ifpresent,theWaveformDataPacket Record)thatarestoredinthefileafterthePointDataRecords. Thisnumbermustbeupdatedifthe numberofEVLRschanges. IftherearenoEVLRsthisvalueiszero.

NumberofPointRecords

Thisfieldcontainsthetotalnumberofpointrecordsinthefile. Notethatthisfieldmustalwaysbe correctlypopulated,regardlessoflegacymodeintent.

NumberofPointsbyReturn

These fields contain an array of the total point records per return. The first value will be the total number of records from the first return, the second contains the total number for return two, and soonuptofifteenreturns. Notethatthesefieldsmustalwaysbecorrectlypopulated,regardlessof legacymodeintent.

2.5 Variable Length Records (VLRs)

The Public Header Block can be followed by any number of Variable Length Records (VLRs) so long as the total size does not make the start of the Point Record data inaccessible by an unsigned long (“Offset to Point Data” in the Public Header Block). The number of VLRs is specified in the “Number of Variable Length Records” field in the Public Header Block. The Variable Length

2. LASFORMATDEFINITION Page13

[Seite 17]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Recordsmustbeaccessedsequentiallysincethesizeofeachvariablelengthrecordiscontainedin theVariableLengthRecordHeader. EachVariableLengthRecordHeaderis54bytesinlength.

Table6: VariableLengthRecordHeader

Reserved

Thisvaluemustbesettozero.

UserID

The User ID field is ASCII character data that identifies the user that created the variable length record. It is possible to have many Variable Length Records from different sources with different User IDs. If the character data is less than 16 characters, the remaining data must be null. The User ID must be registered with the LAS specification managing body. The management of these UserIDsensuresthatnotwoindividualsaccidentallyusethesameUserID.

RecordID

TheRecordIDisdependentupontheUserID.Therecanbe0to65,535RecordIDsforeveryUser ID. The LAS specification manages its own Record IDs (User IDs owned by the specification); otherwise Record IDs will be managed by the owner of the given User ID. Thus each User ID is allowed to assign 0 to 65,535 Record IDs in any manner they desire. Publicizing the meaning of a given Record ID is left to the owner of the given User ID. Unknown User ID/Record ID combinationsshouldbeignored.

RecordLengthAfterHeader

The record length is the number of bytes for the record after the end of the standard part of the header. Thus the entire record length is 54 bytes (the header size of the VLR) plus the number of bytesinthevariablelengthportionoftherecord.

Description

Optionaltextdescriptionofthedata. Anyremainingcharactersnotusedmustbenull.

2. LASFORMATDEFINITION Page14

[Seite 18]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6 Point Data Records

LASfileI/Osoftwaremustusethe“OffsettoPointData”fieldinthePublicHeaderBlocktolocate the starting position of the first Point Data Record. Note that all Point Data Records must be the sametype(i.e.,PointDataRecordFormat).

PointDataRecordFormats(PDRFs)6-10haveimprovedseveralaspectsofthecoreinformationin thepointdatarecords,particularlysupportfor256classesandthedefinitionofaspecific“Overlap” bit. While all PDRFs (0-10) are supported in LAS 1.4, the preferred formats are 6-10. PDRFs 0-5 arethereforedesignatedasthe“legacy”pointformats.

RequiredPointAttributes

Point attributes that are “Required” must be populated with relevant values whenever possible. If unused, point attributes that are not “Required” must be set to the equivalent of zero for the data type(i.e.,0.0forfloatingtypes,nullforASCII,0forintegers).

If a “Required” point attribute cannot apply to a particular technology (e.g., Scan Direction for a passive sensor) then the attribute must be set to a default value as directed. This default value is zeroifunspecifiedintheattributedescription.

AggregateModelSystems

Pointsderivedfrommultipleobservationsinanaggregatemodelratherthanadirectmeasurement system should be assigned valid values using a consistent scheme for a given dataset. For exam- ple, in the case of a photogrammetrically derived point cloud, the Point Source ID, GPS Time, and Scan Angle could be assigned to a point based on the value associated with the most recent photograph from which the point was derived. Example systems to which this recommendation appliesincludephotogrammetricallyderivedpointcloudsandGeiger-modelidarprocessedwitha consensusmodel. Thesesystemsarehereaftercollectivelydenotedas“AggregateModelSystems.”

2.6.1 Point Data Record Format 0

Point Data Record Format 0 contains the core 20 bytes that are shared by Point Data Record Formats0to5.

2. LASFORMATDEFINITION Page15

[Seite 19]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table7: PointDataRecordFormat0

X,Y,andZ

TheX,Y,andZvaluesarestoredaslongintegers. TheX,Y,andZvaluesareusedinconjunction with the scale values and the offset values to determine the coordinate for each point as described inthePublicHeaderBlock section.

Intensity

The Intensity value is the integer representation of the pulse return magnitude. This value is op- tional and system specific. However, it should always be included if available. If Intensity is not included,thisvaluemustbesettozero.

Intensity,whenincluded,isalwaysnormalizedtoa16bit,unsignedvaluebymultiplyingthevalue by65,536/(intensitydynamicrangeofthesensor). Forexample,ifthedynamicrangeofthesensor is10bits,thescalingvaluewouldbe(65,536/1,024). Thisnormalizationisrequiredtoensurethat datafromdifferentsensorscanbecorrectlymerged.

Forsystemsbasedontechnologyotherthanpulsedlasers,Intensityvaluesmayrepresentestimated relativereflectivity,ratherthanadirectmeasurementofpulsereturnmagnitude,andmaybederived frommultiplesources.

Note: Pleasenotethatthefollowingfourfields(ReturnNumber,NumberofReturns,ScanDirec- tionFlag,andEdgeofFlightLine)arebitfieldswithinasinglebyte.

ReturnNumber 1RecallthatthePointDataRecordSizecanbegreaterthantheminimumrequiredforaPDRF.These“extrabytes” followthestandardPointRecordfieldsandaredescribedintheExtraBytesVLRsection.

2. LASFORMATDEFINITION Page16

[Seite 20]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

TheReturnNumberisthepulsereturnnumberforagivenoutputpulse. Agivenoutputlaserpulse can have many returns, and they must be marked in sequence of return. The first return will have a Return Number of one, the second a Return Number of two, and so on up to five returns. The ReturnNumbermustbebetween1andtheNumberofReturns,inclusive.

Forsystemsunabletorecordmultiplereturns,theReturnNumbershouldbesettoone,unlessitis syntheticallyderivedandtheSyntheticReturnNumberGlobalEncodingbitisset.

NumberofReturns(GivenPulse)

The Number of Returns is the total number of returns for a given pulse. For example, a laser data pointmaybereturntwo(ReturnNumber)withinatotalnumberofuptofivereturns.

For systems unable to record multiple returns, the Number of Returns should be set to one, unless itissyntheticallyderivedandtheSyntheticReturnNumberGlobalEncodingbitisset.

ScanDirectionFlag

TheScanDirectionFlagdenotesthedirectioninwhichthescannermirrorwastravelingatthetime of the output pulse. A bit value of 1 is a positive scan direction, and a bit value of 0 is a negative scan direction (where positive scan direction is a scan moving from the left side of the in-track directiontotherightsideandnegativetheopposite).

For Aggregate Model Systems or if the measurement system does not include a rotational compo- nent,theScanDirectionFlagshouldbesettozero.

EdgeofFlightLineFlag

The Edge of Flight Line Flag has a value of 1 only when the point is at the end of a scan. It is the lastpointonagivenscanlinebeforeitchangesdirectionorthemirrorfacetchanges.

Note that this field has no meaning for Aggregate Model Systems or 360 degree Field of View scanners(e.g.,terrestriallidarscanners). Inthesecases,theEdgeofFlightLineFlagshouldbeset tozero.

Classification

This field represents the “class” attributes of a point. If a point has never been classified, this byte mustbesettozero. Theformatforclassificationisabitencodedfieldwiththelowerfivebitsused for the class and the three high bits used for flags. The bit definitions are listed in Table 8 and the classificationvaluesinTable9.

2. LASFORMATDEFINITION Page17

[Seite 21]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table 8: Classification Bit Field Encoding (Point Data RecordFormats0-5)

Note: Note that bits 5, 6 and 7 are treated as flags and can be set or clear in any combination. For example, a point with bits 5 and 6 both set to one and the lower five bits set to 2 would be a Ground pointthathadbeenSyntheticallycollectedandmarkedasamodelKey-Point.

ReservedPointClasses

Classificationmustadheretothefollowingstandard:

2. LASFORMATDEFINITION Page18

[Seite 22]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table 9: ASPRS Standard Point Classes (Point Data Record Formats0-5)

Note: A note on Bit Fields – The LAS storage format is “Little Endian.” This means that multi- bytedatafieldsarestoredinmemoryfromleastsignificantbyteatthelowaddresstomostsignifi- cantbyteatthehighaddress. Bitfieldsarealwaysinterpretedasbit0setto1equals1,bit1setto 1equals2,bit2setto1equals4andsoforth.

ScanAngleRank

The Scan Angle Rank is a signed one-byte integer with a valid range from -90 to +90. The Scan Angle Rank is the angle (rounded to the nearest integer in the absolute value sense) at which the laser point was output from the laser system including the roll of the aircraft. The scan angle is within1degreeofaccuracyfrom+90to-90degrees. Thescanangleisananglebasedon0degrees beingnadir,and-90degreestotheleftsideoftheaircraftinthedirectionofflight.

For Aggregate Model Systems, the Scan Angle Rank should be set to zero unless assigned from a componentmeasurement.

UserData

Thisfieldmaybeusedattheuser’sdiscretion.

2Weareusingboth0and1asUnclassifiedtomaintaincompatibilitywithcurrentpopularclassificationsoftware suchasTerraScan. Weextendtheideaofclassificationvalue1toincludecasesinwhichdatahavebeensubjectedtoa classificationalgorithmbutemergedinanundefinedstate. Forexample,datawithclass0issentthroughanalgorithm todetectman-madestructures–pointsthatemergewithouthavingbeenassignedasbelongingtostructurescouldbe remappedfromclass0toclass1. 3OverlapPointsarethosepointsthatwereimmediatelyculledduringthemergingofoverlappingflightlines. In general,theWithheldbitshouldbesetsincethesepointsarenotsubsequentlyclassified.

2. LASFORMATDEFINITION Page19

[Seite 23]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

PointSourceID

Thisvalueindicatesthesourcefromwhichthispointoriginated. Asourceistypicallydefinedasa groupingoftemporallyconsistentdata,suchasaflightlineorsortienumberforairbornesystems, a route number for mobile systems, or a setup identifier for static systems. Valid values for this fieldare1to65,535inclusive. Zeroisreservedasaconveniencetosystemimplementers.

ForAggregateModelSystems,thePointSourceIDshouldbesettoone(1)unlessassignedfroma componentmeasurement.

2. LASFORMATDEFINITION Page20

[Seite 24]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.2 Point Data Record Format 1

Point Data Record Format 1 is the same as Point Data Record Format 0 with the addition of GPS Time.

Table10: PointDataRecordFormat1

GPSTime

The GPS Time is the double floating point time tag value at which the point was observed. It is GPS Week Time if the Global Encoding low bit is clear and Adjusted Standard GPS Time if the bitisset.

ForAggregateModelSystems,theGPSTimeshouldbesettozerounlessassignedfromacompo- nentmeasurement.

2. LASFORMATDEFINITION Page21

[Seite 25]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.3 Point Data Record Format 2

Point Data Record Format 2 is the same as Point Data Record Format 0 with the addition of three colorchannels. Thesefieldsareusedwhen“colorizing”apointusingancillarydata,typicallyfrom acamera.

Table11: PointDataRecordFormat2

Red,Green,andBlue

TheRed,Green,andBlueimagechannelvaluesassociatedwiththispoint.

Note: The Red, Green, and Blue values should always be normalized to 16 bit values. For example, when encoding an 8 bit per channel pixel, multiply each channel value by 256 prior to storage in these fields. This normalization allows color values from different camera bit depths to beaccuratelymerged.

2. LASFORMATDEFINITION Page22

[Seite 26]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.4 Point Data Record Format 3

Point Data Record Format 3 is the same as Point Data Record Format 2 with the addition of GPS Time.

Table12: PointDataRecordFormat3

2. LASFORMATDEFINITION Page23

[Seite 27]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.5 Point Data Record Format 4

PointDataRecordFormat4addsWavePacketstoPointDataRecordFormat1.

Table13: PointDataRecordFormat4

WavePacketDescriptorIndex

This value plus 99 is the Record ID of the Waveform Packet Descriptor and indicates the User Defined Record that describes the waveform packet associated with this Point Record. Up to 255 different User Defined Records which describe the waveform packet are supported. A value of zeroindicatesthatthereisnowaveformdataassociatedwiththisPointRecord.

ByteOffsettoWaveformData

The waveform packet data are stored in the LAS file in an Extended Variable Length Record or in an auxiliary *.wdp file. The Byte Offset represents the location of the start of this Point Record’s waveform packet within the waveform data variable length record (or external file) relative to the beginning of the Waveform Data Packets header. The absolute location of the beginning of this waveformpacketrelativetothebeginningofthefileisgivenby:

StartofWaveformDataPacketRecord+ByteOffsettoWaveformData

forwaveformpacketsstoredwithintheLASfileand

2. LASFORMATDEFINITION Page24

[Seite 28]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

ByteOffsettoWaveformData

fordatastoredinanauxiliary*.wdpfile.

WaveformPacketSizeinBytes

The size, in bytes, of the waveform packet associated with this return. Note that each waveform can be of a different size (even those with the same Waveform Packet Descriptor index) due to packet compression. Also note that waveform packets can be located only via the Byte Offset to WaveformPacketDatavaluesincethereisnorequirementthatrecordsbestoredsequentially.

ReturnPointWaveformLocation Thetemporaloffsetinpicoseconds(10−12)fromthearbitrary“anchorpoint”tothelocationwithin thewaveformpacketforthisPointRecord.

Parametricdx,dy,dz

These parameters define a parametric line equation for extrapolating points along the associated waveform. Thepositionalongthewaveisgivenby:

𝑋 = 𝑋 +𝑡𝑑𝑥 (4) 0 𝑌 = 𝑌 +𝑡𝑑𝑦 (5) 0 𝑍 = 𝑍 +𝑡*𝑑𝑧 (6) 0

where (𝑋,𝑌,𝑍) is the spatial position of a derived point, (𝑋 ,𝑌 ,𝑍 ) is the position of the “an- 0 0 0 chor”point,and𝑡isthetime,inpicoseconds,relativetotheanchorpoint.

The anchor point is an arbitrary location at the origin of the associated waveform – i.e. 𝑡 = 0 at theanchorpoint–withcoordinatesdefinedby:

𝑋 = 𝑋 +𝐿𝑑𝑥 (7) 0 𝑃 𝑌 = 𝑌 +𝐿𝑑𝑦 (8) 0 𝑃 𝑍 = 𝑍 +𝐿*𝑑𝑧 (9) 0 𝑃

where (𝑋 ,𝑌 ,𝑍 ) is this Point Record’s transformed position (as a double) and 𝐿 is this Point 𝑃 𝑃 𝑃 Record’sReturnPointWaveformLocation.

The units of X, Y and Z are the units of the coordinate systems of the LAS data. If the coordinate systemisgeographic,thehorizontalunitsaredecimaldegreesandtheverticalunitsaremeters.

Note: Users seeking further clarity regarding LAS waveform encoding are encouraged to learn moreontheofficialLASwiki: https://github.com/ASPRSorg/LAS/wiki

2. LASFORMATDEFINITION Page25

[Seite 29]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.6 Point Data Record Format 5

PointDataRecordFormat5addsWavePacketstoPointDataRecordFormat3.

Table14: PointDataRecordFormat5

2. LASFORMATDEFINITION Page26

[Seite 30]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.7 Point Data Record Format 6

Point Data Record Format 6 contains the core 30 bytes that are shared by Point Data Record Formats 6 to 10. The difference to the core 20 bytes of Point Data Record Formats 0 to 5 is that there are more bits for return numbers in order to support up to 15 returns, there are more bits for point classifications to support up to 256 classes, there is a higher precision scan angle (16 bits insteadof8),andtheGPStimeismandatory.

Table15: PointDataRecordFormat6

Note: The following five fields (Return Number, Number of Returns, Classification Flags, Scan DirectionFlag,andEdgeofFlightLine)arebitfields,encodedintotwobytes.

ReturnNumber

TheReturnNumberisthepulsereturnnumberforagivenoutputpulse. Agivenoutputlaserpulse can have many returns, and they must be marked in sequence of return. The first return will have a Return Number of one, the second a Return Number of two, and so on up to fifteen returns. The ReturnNumbermustbebetween1andtheNumberofReturns,inclusive.

Forsystemsunabletorecordmultiplereturns,theReturnNumbershouldbesettoone,unlessitis syntheticallyderivedandtheSyntheticReturnNumberGlobalEncodingbitisset.

NumberofReturns(GivenPulse)

The Number of Returns is the total number of returns for a given pulse. For example, a laser data pointmaybereturntwo(ReturnNumber)withinatotalnumberofuptofifteenreturns.

2. LASFORMATDEFINITION Page27

[Seite 31]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

For systems unable to record multiple returns, the Number of Returns should be set to one, unless itissyntheticallyderivedandtheSyntheticReturnNumberGlobalEncodingbitisset.

ClassificationFlags

Classification flags are used to indicate special characteristics associated with the point. The bit definitionsare:

Table 16: Classification Bit Field Encoding (Point Data RecordFormats6-10)

Note: Thesebitsaretreatedasflagsandcanbesetorclearedinanycombination. Forexample,a pointwithbits0and1bothsettooneandtheClassificationfieldsetto2wouldbeaGround point thathadbeenSyntheticallycollectedandmarkedasamodelKey-Point.

ScannerChannel

ScannerChannelisusedtoindicatethechannel(scannerhead)ofamulti-channelsystem. Channel 0isusedforsinglescannersystems. Uptofourchannelsaresupported(0-3).

ForAggregateModelSystems,theChannelshouldbesettozerounlessassignedfromacomponent measurement.

ScanDirectionFlag

TheScanDirectionFlagdenotesthedirectioninwhichthescannermirrorwastravelingatthetime of the output pulse. A bit value of 1 is a positive scan direction, and a bit value of 0 is a negative scan direction (where positive scan direction is a scan moving from the left side of the in-track

2. LASFORMATDEFINITION Page28

[Seite 32]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

directiontotherightsideandnegativetheopposite).

For Aggregate Model Systems or if the measurement system does not include a rotational compo- nent,theScanDirectionFlagshouldbesettozero.

EdgeofFlightLineFlag

The Edge of Flight Line Flag has a value of 1 only when the point is at the end of a scan. It is the lastpointonagivenscanlinebeforeitchangesdirectionorthemirrorfacetchanges.

Note that this field has no meaning for Aggregate Model Systems or 360 degree Field of View scanners(e.g.,terrestriallidarscanners). Inthesecases,theEdgeofFlightLineFlagshouldbeset tozero.

Classification

Classificationmustadheretothefollowingstandard:

2. LASFORMATDEFINITION Page29

[Seite 33]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table17: ASPRSStandardPointClasses(PointDataRecord Formats6-10)

ScanAngle

The Scan Angle is a signed short that represents the rotational position of the emitted laser pulse with respect to the vertical of the coordinate system of the data. Down in the data coordinate system is the 0.0 position. Each increment represents 0.006 degrees. Counter-clockwise rotation, as viewed from the rear of the sensor, facing in the along-track (positive trajectory) direction, is positive. The maximum value in the positive sense is 30,000 (180 degrees which is up in the

4Weareusingboth0and1asUnclassifiedtomaintaincompatibilitywithcurrentpopularclassificationsoftware suchasTerraScan. Weextendtheideaofclassificationvalue1toincludecasesinwhichdatahavebeensubjectedtoa classificationalgorithmbutemergedinanundefinedstate. Forexample,datawithclass0issentthroughanalgorithm todetectman-madestructures–pointsthatemergewithouthavingbeenassignedasbelongingtostructurescouldbe remappedfromclass0toclass1.

2. LASFORMATDEFINITION Page30

[Seite 34]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

coordinate system of the data). The maximum value in the negative direction is -30,000 which is alsodirectlyup.

For Aggregate Model Systems, the Scan Angle should be set to zero unless assigned from a com- ponentmeasurement.

2. LASFORMATDEFINITION Page31

[Seite 35]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.8 Point Data Record Format 7

Point Data Record Format 7 is the same as Point Data Record Format 6 with the addition of three RGBcolorchannels. Thesefieldsareusedwhen“colorizing”apointusingancillarydata,typically fromacamera.

Table18: PointDataRecordFormat7

2. LASFORMATDEFINITION Page32

[Seite 36]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.9 Point Data Record Format 8

PointDataRecordFormat8isthesameasPointDataRecordFormat7withtheadditionofaNIR (nearinfrared)channel.

Table19: PointDataRecordFormat8

NIR

TheNIR(nearinfrared)channelvalueassociatedwiththispoint.

Note: Note that Red, Green, Blue, and NIR values should always be normalized to 16 bit values. For example, when encoding an 8 bit per channel pixel, multiply each channel value by 256 prior to storage in these fields. This normalization allows color values from different camera bit depths tobeaccuratelymerged.

2. LASFORMATDEFINITION Page33

[Seite 37]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.10 Point Data Record Format 9

PointDataRecordFormat9addsWavePacketstoPointDataRecordFormat6.

Table20: PointDataRecordFormat9

2. LASFORMATDEFINITION Page34

[Seite 38]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.6.11 Point Data Record Format 10

Point Data Record Format 10 is the same as Point Data Record Format 9 with RGB and NIR values.

Table21: PointDataRecordFormat10

2. LASFORMATDEFINITION Page35

[Seite 39]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

2.7 Extended Variable Length Records (EVLRs)

ThePointRecordDatacanbefollowedbyanynumberofEVLRs.

The EVLR is, in spirit, identical to a VLR but can carry a larger payload as the “Record Length AfterHeader”fieldis8bytesinsteadof2bytes. ThenumberofEVLRsisspecifiedinthe“Number ofExtendedVariableLengthRecords”fieldinthePublicHeaderBlock. ThestartofthefirstEVLR isatthefileoffsetindicatedbythe“StartofFirstExtendedVariableLengthRecord”inthePublic Header Block. The Extended Variable Length Records must be accessed sequentially since the size of each variable length record is contained in the Extended Variable Length Record Header. EachExtendedVariableLengthRecordHeaderis60bytesinlength.

Table22: ExtendedVariableLengthRecordHeader

Note: AswiththeVLR,theReservedfieldmustbesettozero.

2.7.1 Legacy Compatibility for EVLRs

A writer who wishes to maintain legacy compatibility must use only VLRs (except for internally stored waveform data). A writer who is not concerned with a legacy LAS reader having access to aVLRcanelecttouseanEVLR,evenforpredefinedVLRssuchasCoordinateReferenceSystem (CRS) information. This ability is useful, for example, when a user wishes to update information normallycontainedwithinaVLRwithouttheneedofrewritingthepointdata.

AnewLASF_Spec“Superseded”VLR(value7)hasbeendefinedtoallowawritertoindicatethat a VLR should no longer be used. For example, if a user appends a new WKT EVLR to a file, the existing WKT VLR should have its LASF Spec number changed to Superseded to indicate that it isnolongerinuse.

2. LASFORMATDEFINITION Page36

[Seite 40]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

3 Coordinate Reference System VLRs (Required)

LAS 1.4 defines Variable Length Records (VLRs) and Extended Variable Length Records (EVLRs). Coordinate Reference System (CRS) VLRs are defined in this section, while other VLRsandEVLRsaredefinedinthefollowingtwosections.

3.1 Coordinate Reference System Information

TheCoordinateReferenceSystem(CRS)informationforthepointdataisrequiredforalldata. The CRSinformationwillbeplacedinVariableLengthRecordsorExtendedVariableLengthRecords (note that if the writer wishes to maintain legacy compatibility, then GeoTIFF in VLRs must be used). TheCRSisrepresentedbyeitherGeoTIFForWellKnownText(WKT)asindicatedbythe WKT Global Encoding bit. Point Record Formats 0-5 can use either GeoTIFF or WKT, but not bothsimultaneously. PointDataRecordFormats6-10mustuseWKT.

3.2 Georeferencing Information Using WKT

For definition of WKT, we refer to Open Geospatial Consortium (OGC) specification “OpenGIS coordinatetransformationserviceimplementationspecification”revision1.00released12January 2001,section7(“CoordinateTransformationServiceSpec”25). AsthereareafewdialectsofWKT, pleasenotethatLASisnotusingthe“ESRIWKT”dialect,whichdoesnotincludeTOWGS84and Authoritynodes.

WKT georeferencing information can be specified in two optional variable length records, the OGCmathtransformWKTrecordandtheOGCcoordinatesystemWKTrecord,asfollows. Note thatthemathtransformWKTrecordisaddedforcompleteness,andacoordinatesystemWKTmay ormaynot requireamathtransformWKTrecord(aparameterizedmathtransformdefinition).

3.2.1 OGC Math Transform WKT Record

This record contains the textual data representing a Math Transform WKT as defined in section 7 oftheCoordinateTransformationServiceSpec,withthefollowingnotes:

• TheOGCMathTransformWKTVLRdatashallbeanull-terminatedstring. • TheOGCMathTransformWKTVLRdatashallbeconsideredUTF-8. • The OGC Math Transform WKT VLR data shall be considered C locale-based, and no lo- calizationofthenumericstringswithintheWKTshouldbeperformed.

25https://www.opengeospatial.org/standards/ct

3. COORDINATEREFERENCESYSTEMVLRS(REQUIRED) Page37

[Seite 41]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

3.2.2 OGC Coordinate System WKT Record

ThisrecordcontainsthetextualdatarepresentingaCoordinateSystemWKTasdefinedinsection 7oftheCoordinateTransformationServiceSpec,withthefollowingnotes:

• TheOGCCoordinateSystemWKTVLRdatashallbeanull-terminatedstring. • TheOGCCoordinateSystemWKTVLRdatashallbeconsideredUTF-8. • The OGC Coordinate System WKT VLR data shall be considered C locale-based, and no localizationofthenumericstringswithintheWKTshouldbeperformed.

3.3 Georeferencing Information Using GeoTIFF

TheGeoTIFFspecificationisdefinedbyhttp://geotiff.osgeo.org/.

GeoTIFF georeferencing for the LAS formats uses the same mechanism that was developed for the GeoTIFF standard. The variable length header records section may contain the same data that would be contained in the GeoTIFF key tags of a TIFF file. Since LAS is not a raster format and each point contains its own absolute location information, only 3 of the 6 GeoTIFF tags are necessarywhenusingGeoTIFFrecordsinsteadofWKTrecords. TheModelTiePointTag(33922), ModelPixelScaleTag(33550),andModelTransformationTag(34264)recordscanbeexcluded. The GeoKeyDirectoryTag (34735), GeoDoubleParamsTag (34736), and GeoAsciiParamsTag (34737) recordsareused.

Only the GeoKeyDirectoryTag record is required when using GeoTIFF records instead of WKT records. The GeoDoubleParamsTag and GeoAsciiParamsTag records may or may not be present, dependingonthecontentoftheGeoKeyDirectoryTagrecord.

3.3.1 GeoKeyDirectoryTag Record

This record contains the key values that define the coordinate system. A complete description can be found in the GeoTIFF format specification. Here is a summary from a programmatic point of viewforsomeoneinterestedinimplementation.

The GeoKeyDirectoryTag is defined as just an array of unsigned short values. But, programmati- cally,thedatacanbeseenassomethinglikethis:

3. COORDINATEREFERENCESYSTEMVLRS(REQUIRED) Page38

[Seite 42]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

struct sGeoKeys { unsigned short wKeyDirectoryVersion; unsigned short wKeyRevision; unsigned short wMinorRevision; unsigned short wNumberOfKeys;

struct sKeyEntry { unsigned short wKeyID; unsigned short wTIFFTagLocation; unsigned short wCount; unsigned short wValue_Offset; } pKey[1]; };

Where:

wKeyDirectoryVersion = 1; // Always wKeyRevision = 1; // Always wMinorRevision = 0; // Always wNumberOfKeys // Number of sets of 4 unsigned shorts to follow

Table23: GeoKeyFourUnsignedShorts

3.3.2 GeoDoubleParamsTag Record (Optional)

ThisrecordissimplyanarrayofdoublesthatcontainvaluesreferencedbytagsetsintheGeoKey-

3. COORDINATEREFERENCESYSTEMVLRS(REQUIRED) Page39

[Seite 43]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

DirectoryTagrecord.

3.3.3 GeoAsciiParamsTag Record (Optional)

ThisrecordissimplyanarrayofASCIIdata. Itcontainsmanystringsseparatedbynullterminator characters,whicharereferencedbypositionfromdataintheGeoKeyDirectoryTagrecord.

3. COORDINATEREFERENCESYSTEMVLRS(REQUIRED) Page40

[Seite 44]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

4 Other Specification Defined VLRs (Optional)

4.1 Classification Lookup

struct CLASSIFICATION { unsigned char ClassNumber; char Description[15]; }; //total of 16 bytes

4.2 Text Area Description

This VLR/EVLR is used for providing a textual description of the content of the LAS file. It is a null-terminated,free-formASCIIstring.

4.3 Extra Bytes

The Extra Bytes VLR provides a mechanism whereby additional information can be added to the end of a standard Point Record. This VLR has been added to LAS 1.4 to formalize a process that has been used in prior versions of LAS. It is envisioned that software that is not cognizant of the meaningoftheextrabyteswillsimplycopythesebyteswhenmanipulatingfiles.

This VLR is only required for LAS files where points contain user-defined “extra bytes”. This happens when the point record size is set to a larger value than required by the point type. For example, if a LAS file that contains point type 1 has a point record size of 32 instead of 28, there are4“extrabytes”. TheExtraBytesVLRcontainsasimpledescriptionofthetypeandthemeaning ofthese“extrabytes”sotheycanbeaccessedinaconsistentmanneracrossapplications. Theextra bytesdescriptorisdefinedasfollows:

4. OTHERSPECIFICATIONDEFINEDVLRS(OPTIONAL) Page41

[Seite 45]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

struct EXTRA_BYTES { unsigned char reserved[2]; // 2 bytes unsigned char data_type; // 1 byte unsigned char options; // 1 byte char name[32]; // 32 bytes unsigned char unused[4]; // 4 bytes anytype no_data; // 8 bytes unsigned char deprecated1[16]; // 16 bytes anytype min; // 8 bytes unsigned char deprecated2[16]; // 16 bytes anytype max; // 8 bytes unsigned char deprecated3[16]; // 16 bytes double scale; // 8 bytes unsigned char deprecated4[16]; // 16 bytes double offset; // 8 bytes unsigned char deprecated5[16]; // 16 bytes char description[32]; // 32 bytes }; // total of 192 bytes

The 4 “extra bytes” could, for example, be of data_type 9 - a 4-byte floating point value - that specifies an “echo width” for each return. In this case there would be one EXTRA_BYTES struct inthepayloadofthisVLR.Inanotherexample,fourEXTRA_BYTESstructsintheVLRpayload coulddescribe14“extrabytes”ineachpointrecord:

1. “laserpulsedirection[0]”-data_type=9(float)
2. “laserpulsedirection[1]”-data_type=9(float)
3. “laserpulsedirection[2]”-data_type=9(float)
4. “pulsewidth”-data_type=3(ushort)

Inthisexample,anarrayofthreeindividualfloatscollectivelyspecifya“laserpulsedirection”for thatpoint,andoneunsignedshortintegerspecifiesa“pulsewidth”forthatpoint.

The“extrabytes”aremadeaccessibleviaauniquename. The“name”fielddistinguishestheaddi- tionalpointattributesthatsoftwaremayaddtothepointsinaLASfilesotheycanbeaccessedlater in a consistent manner by another software. Descriptive names such as “normalized reflectivity”, “echo width”, or “shading normal” are encouraged. The use of generic names such as “variable1” or“temp1”isdiscouraged.

Multiple sequential “extra byte” records can compose an array of associated values. It is recom- mended that each member’s name be consistent with other members, only varying by an index numberwrappedinsquarebrackets,asintheaboveexample. Zero-indexedarraysareencouraged. Previous revisions of the LAS 1.4 specification utilized data_types 11-30 to define standard two- and three-member arrays, but this feature was never widely implemented and was deprecated in R1426 tosimplifyimplementation.

Anyunusedcharactersinthe“name”or“description”fieldsmustbesettozero.

26https://github.com/ASPRSorg/LAS/issues/1

4. OTHERSPECIFICATIONDEFINEDVLRS(OPTIONAL) Page42

[Seite 46]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table24: Valuesfordata_typeField

Table25: EncodingofoptionsBitField

The bit mask in the “options” field specifies whether the min and max range of the value has been set(i.e.,ismeaningful),whetherthescaleand/oroffsetvaluesaresetwithwhichthe“extrabytes” are to be multiplied and translated to compute their actual value, and whether there is a special value that should be interpreted as NO_DATA. By default all bits are zero which means that the values in the corresponding fields are to be disregarded. Any unused “no_data”, “min”, “max”, “scale”,or“offset”fieldsmustbesettozero.

If the selected data_type is less than 8 bytes, the no_data, min, and max fields should be upcast into8-bytestorage. Foranyfloatthese8byteswouldbeupcasttoadouble,foranyunsignedchar, unsigned short, or unsigned long they would be upcast to an unsigned long long and for any char, short,orlong,theywouldbeupcasttoalonglong.

Ifused,theminandmaxfieldsreflecttheactualminimumandmaximumvaluesoftheattributein theLASfile,initsrawform,withoutanyscaleoroffsetvaluesapplied.

The “reserved” field, the “unused” field, and the “deprecated” fields must be set to zero and may beusedinafuturerevision.

4. OTHERSPECIFICATIONDEFINEDVLRS(OPTIONAL) Page43

[Seite 47]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

A LAS file contains “undocumented extra bytes” when there are “extra bytes” but when there is noExtraBytesVLRthatdescribesthemorwhentherearemore“extrabytes”thandescribedinan existingExtraBytesVLR.

When adding an “Extra Bytes” VLR to a LAS file that contains “undocumented extra bytes” they mustbedesignatedasdata_type==0withtheoptionsbitfieldstoringthenumberofundocumented bytes.

A LAS file has an “extra bytes mismatch” if the Extra Bytes VLR describes more “extra bytes” than each LAS point actually has. The occurrence of an “extra bytes mismatch” renders the Extra BytesVLRinvalid.

4.4 Superseded

ThisLASFRecordIDisusedtonegateanexistingVLR/EVLRwhenrewritingthefile(toremove the undesired VLR/EVLR). It is used, for example, when updating a record such as projection information where a new EVLR is appended to the end of the LAS file. The existing VLR which hasbeensupersededmustbemarkedwiththeSUPERSEDEDRecordID.

4.5 Waveform Packet Descriptor

Warning: ThisVLRisREQUIREDwhenusingPointDataRecordFormats4,5,9,or10.

Theserecordscontaininformationthatdescribestheconfigurationofthewaveformpackets. Since systems may be configured differently at different times throughout a job, the LAS file supports 255WaveformPacketDescriptors.

4. OTHERSPECIFICATIONDEFINEDVLRS(OPTIONAL) Page44

[Seite 48]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

Table26: WaveformPacketDescriptorUserDefinedRecord

BitsperSample

2through32bitsaresupported.

WaveformCompressionType

ItisexpectedthatinthefuturestandardcompressiontypeswillbeadoptedbytheLAScommittee. This field will indicate the compression algorithm used for the waveform packets associated with thisdescriptor. Avalueof0indicatesnocompression. Zeroistheonlyvaluecurrentlysupported.

NumberofSamples

The number of samples associated with this waveform packet type. This value always represents thefullydecompressedwaveformpacket.

TemporalSampleSpacing

The temporal sample spacing in picoseconds. Example values might be 500, 1000, 2000, and so on,representingdigitizerfrequenciesof2GHz,1GHz,and500MHzrespectively.

DigitizerGainandOffset

The digitizer gain and offset are used to convert the raw digitized value to an absolute digitizer voltageusingtheformula:

𝑉𝑂𝐿𝑇𝑆 = 𝑂𝐹𝐹𝑆𝐸𝑇 +𝐺𝐴𝐼𝑁 *𝑅𝑎𝑤_𝑊𝑎𝑣𝑒𝑓𝑜𝑟𝑚_𝐴𝑚𝑝𝑙𝑖𝑡𝑢𝑑𝑒

Note: Users seeking further clarity regarding LAS waveform encoding are encouraged to learn moreontheofficialLASwiki: https://github.com/ASPRSorg/LAS/wiki

4. OTHERSPECIFICATIONDEFINEDVLRS(OPTIONAL) Page45

[Seite 49]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

5 Defined Extended Variable Length Records (EVLRs)

5.1 Waveform Data Packets

Warning: This EVLR is REQUIRED internally or externally when using Point Data Record Formats4,5,9,or10.

The packet of Raw Waveform Amplitude values for all records immediately follow this VLR header. Note that when using a bit resolution that is not an even increment of 8, the last byte ofeachwaveformpacketmustbepaddedsuchthatthenextwaveformrecordwillstartonaneven byteboundary.

5. DEFINEDEXTENDEDVARIABLELENGTHRECORDS(EVLRS) Page46

[Seite 50]

LASSpecificationv.1.4-R14 AmericanSocietyforPhotogrammetry&RemoteSensing

6 LAS Domain Profiles

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 point cloud community (e.g., the coastal/bathymetric lidar community, or the powerline mapping community). SoastonotaltertheLASbasespecification,newclassescanonlybeaddedtoPoint Data Record Formats 6-10, and classification values cannot start below 39. New attributes must be incorporated using Extra Bytes VLRs. It is strongly recommended that the development of Domain Profiles be coordinated, so as to avoid unnecessary overlap or conflicts (e.g., conflicting classnumbers)betweenprofiles.

6.1 LAS Domain Profile Description

Thespecificationforaparticulardomainprofile. TheDescriptionmustcontain:

1. anoverviewofthepurposeandintendeduse;
2. tableofnewpointclassifications(PDRF6-10);and
3. table of new attributes to be stored using Extra Bytes VLRs (must contain fields for units, datatype,name,nodata,scale,anddescription).

LAS Domain Profile Descriptions reviewed and approved by the LAS Working Group will be posted on the ASPRS website. A template Domain Profile Description is available on the ASPRS website27.

27https://www.asprs.org/committee-general/laser-las-file-format-exchange-activities.html

6. LASDOMAINPROFILES Page47