diff --git a/source/00_index.txt b/source/00_index.txt index 4b27724..ffcfc7e 100644 --- a/source/00_index.txt +++ b/source/00_index.txt @@ -3,18 +3,14 @@ Welcome to LAS's documentation! =============================== .. toctree:: - :maxdepth: 2 + :maxdepth: 5 :caption: Contents: + :numbered: 01_intro - 04_definition - 05_legacy - 06_crs - 07_datatypes - 08_header - 09_vlr - 10_point - 11_evlr - 12_defined_vlrs - 15_profiles + 02.00_definition + 03_required_vlrs + 04_optional_vlrs + 05_defined_evlrs + 06_profiles diff --git a/source/01_intro.txt b/source/01_intro.txt index 58864ab..21e7614 100644 --- a/source/01_intro.txt +++ b/source/01_intro.txt @@ -1,24 +1,111 @@ -Purpose, Scope, and Applicability +Introduction -------------------------------------------------------------------------------- -The LAS file is intended to contain LIDAR (or other) point cloud data records. -The data will generally be put into this format from software (e.g. provided by -LIDAR hardware vendors) which combines GPS, IMU, and laser pulse range data to +Purpose, Scope, and Applicability +................................................................................ + +The LAS file is intended to contain lidar (or other) point cloud data records. +The data will generally be put into this format from software (e.g., provided by +hardware vendors), which combines GPS, IMU, and laser pulse range data to produce X, Y, and Z point data. The intention of the data format is to provide -an open format that allows different LIDAR hardware and software tools to +an open format that allows different hardware and software tools to output data in a common format. This document reflects the fourth revision of the LAS format specification since its initial version 1.0 release. -LAS 1.4 Additions -................................................................................ + +LAS 1.4 Revision History +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Summary of LAS 1.4 revisions: + +* R11 - Approved Version (Nov 2011). +* R12 - Errata (June 2012) - Typographical corrections: + + * Corrected Public Header Size in descriptive paragraph to 375 bytes. + * Corrected two instances of Scan Angle Rank from "Unsigned Char" to "Char". + +* R13 - Added Domain Profile Section (July 2013). +* R14 - Multiple updates (GitHub Issue numbers): + + * Aesthetic changes from migration to GitHub + * Multiple capitalization & typo corrections. + * Updated ASPRS contact info. + (`I-30 `_) + * Additional standard classifications 19-22 for PDRFs 6-10: + (`I-11 `_, + `I-26 `_) + + * Class 19 -- Overhead Structure in PDRFs 6-10. + * Class 20 -- Ignored Ground. + * Class 21 -- Snow. + * Class 22 -- Temporal Exclusion. + + * Added OGC endorsement. + (`I-31 `_) + * Added minimum PDRF sizes to attribute tables. + (`I-47 `_) + * Section reorganization: + (`I-57 `_) + + * Addition of Table of Contents with section numbers. (c.f. + `I-27 `_, + `I-49 `_) + * Divided Defined Variable Length Records section into Coordinate + Reference System VLRs section (s3) and Other Specification Defined + VLRs (s4). + * Expanded EVLR discussion in Legacy Compatibility section (s2.1) and moved + Legacy Compatibility section to EVLR definition (now s2.7.1). + * Swapped order of LAS 1.4 Revision History (now s1.1.1) and + LAS 1.4 Additions (now s1.1.2). + * Rearranged paragraphs in Extra Bytes VLR description. + + * Deprecated "tuple" and "triple" extra byte data types. + (`I-1 `_) + + * Added explanation and example of implicit arrays from descriptor names. + + * Clarified that ExtraByte min/max should be an untransformed value. + (`I-4 `_) + * Clarified that Legacy Point Counts should be set to zero if using non-legacy + PDRFs. (`I-12 `_) + * Clarified Full Waveform descriptions and added wiki link. + (`I-9 `_) + * Renamed X(t), Y(t), and Z(t) from waveform packets to Parametric dx/dy/dz. + * PDRF9 now correctly requires Scanner Channel like other PDRFs. + (`I-29 `_) + * Clarified origin date/time for Adjusted Standard GPS Time. + (`I-40 `_) + * Clarified null-termination of fixed-length ``char`` arrays, especially VLR + Description. (`I-46 `_) + * Clarified relationship between FileSourceID and PointSourceID. + (`I-59 `_) + * Added language to support technologies other than conventional linear-mode + lidar scanners. (`I-35 `_) + + * Clarified and renamed Synthetic Return Numbers Global Encoding bit. + * Clarified Synthetic point classification flag. + * Clarified validity of zero-value PointSourceID. + * Unified Return Number and Number of Returns descriptions between + legacy and non-legacy PDRFs. + * Clarified Scan Direction and Edge of Flight Line Flags for non-rotational systems. + + * Added wiki link for Project ID examples. + (`I-38 `_) + +For detailed information on changes in revisions R14 and newer, review the +inline differencing provided on the `GitHub page `_. + + +Comparison of LAS 1.4 to Previous Versions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The additions of LAS 1.4 include: * Backward compatibility with LAS 1.1 – LAS 1.3 when payloads consist of only legacy content -* LAS 1.4 Mode which supports +* LAS 1.4 mode which supports: * Extension of offsets and field sizes to support full 64 bit * Support for up to 15 returns per outgoing pulse @@ -33,43 +120,48 @@ The additions of LAS 1.4 include: * Addition of an (optional) Extra Byte Variable Length Record to describe "extra bytes" stored with each point -* Other minor changes +* Other minor changes: * Added definitions for "LAS Domain Profile" and "LAS Domain Profile Description" + * Added links to official LAS wiki: https://github.com/ASPRSorg/LAS/wiki -LAS 1.4 Revision History -................................................................................ - -Summary of LAS 1.4 revisions: - -* R11 - Approved Version (Nov 2011) -* R12 - Errata (June 2012) - Typographical corrections: - - * Corrected Public Header size in descriptive paragraph to 375 bytes - * Corrected two instances of Scan Angle Rank from "Unsigned Char" to "Char" - -* R13 - Added Domain Profile Section (July 2013) -* R14 - Aesthetic changes from migration to GitHub - -For detailed information on changes in revisions R14 and newer, review the -inline differencing provided on the GitHub page: https://github.com/ASPRSorg/LAS Conformance --------------------------------------------------------------------------------- +................................................................................ The data types used in the LAS format definition are conformant to the 1999 ANSI C Language Specification (ANSI/ISO/IEC 9899:1999 ("C99"). + Authority --------------------------------------------------------------------------------- +................................................................................ + +ASPRS +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The American Society for Photogrammetry & Remote Sensing (ASPRS) is the owner of the LAS Specification. The standard is maintained by committees within the organization as directed by the ASPRS Board of Directors. Questions related to -this standard can be directed to ASPRS at 301-493-0290, by email at -asprs@asprs.org, or by mail at 5410 Grosvenor Lane, Suite 210, Bethesda, -Maryland 20814-2160. +this standard can be directed to ASPRS: + +* Online at https://github.com/ASPRSorg/LAS +* By phone at 301-493-0290 +* By email at las@asprs.org or asprs@asprs.org +* By mail at 425 Barlow Place, Suite 210, Bethesda, Maryland 20814-2160. + +OGC +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +LAS has been recognized by the Open Geospatial Consortium (`OGC`_) in 2018 as an +OGC Community Standard. The OGC version of the document with forward material +about standards that LAS references and its status within the standard body can +be found at https://portal.opengeospatial.org/files/17-030r1. + +Future recognition and activity on OGC referencing activities of LAS can be +followed at http://www.opengeospatial.org/standards/community. + +.. _`OGC`: http://www.opengeospatial.org .. raw:: latex diff --git a/source/04_definition.txt b/source/02.00_definition.txt similarity index 74% rename from source/04_definition.txt rename to source/02.00_definition.txt index 83b4010..6e80c14 100644 --- a/source/04_definition.txt +++ b/source/02.00_definition.txt @@ -12,22 +12,22 @@ The Variable Length Records (VLRs) contain variable types of data including projection information, metadata, waveform packet information, and user application data. They are limited to a data payload of 65,535 bytes. -The Extended Variable Length Records (EVRLs) allow a higher payload than VLRs +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 adding, for example, projection information to a LAS file without having +allows, for example, adding projection information to a LAS file without having to rewrite the entire file. .. table:: LAS 1.4 Format Definition +--------------------------------------------+ - | PUBLIC HEADER BLOCK | + | :ref:`headerblock_label` | +--------------------------------------------+ - | VARIABLE LENGTH RECORDS (VLR) | + | :ref:`vlrdef_label` | +--------------------------------------------+ - | POINT DATA RECORDS | + | :ref:`ptrecords_label` | +--------------------------------------------+ - | EXTENDED VARIABLE LENGTH RECORDS (EVLR) | + | :ref:`evlrdef_label` | +--------------------------------------------+ @@ -38,4 +38,12 @@ Packets (if stored internally to the file) have the offset to the storage header contained within the Public Header Block ("Start of Waveform Data Packet Record"). +.. include:: ./02.01_legacy.sub +.. include:: ./02.02_crs.sub +.. include:: ./02.03_datatypes.sub +.. include:: ./02.04_header.sub +.. include:: ./02.05_vlr.sub +.. include:: ./02.06_point.sub +.. include:: ./02.07_evlr.sub + diff --git a/source/05_legacy.txt b/source/02.01_legacy.sub similarity index 71% rename from source/05_legacy.txt rename to source/02.01_legacy.sub index 81b19d7..2bb011a 100644 --- a/source/05_legacy.txt +++ b/source/02.01_legacy.sub @@ -1,5 +1,5 @@ -Legacy Compatibility (LAS 1.1 – LAS 1.3) --------------------------------------------------------------------------------- +Legacy Compatibility (LAS 1.1 - LAS 1.3) +................................................................................ LAS 1.4 moves the file specification from a 32 bit file structure (maximum value of :math:`2^{32}-1 \equiv 4,294,967,295 \equiv \mbox{UINT32\_MAX}`) to a @@ -7,13 +7,13 @@ value of :math:`2^{32}-1 \equiv 4,294,967,295 \equiv \mbox{UINT32\_MAX}`) to a To maintain the ability to place a LAS 1.1 through LAS 1.3 payload (point record types 0-5, GeoTIFF coordinate reference system, referred to as "Legacy" -payloads) in a LAS 1.4 file structure, it was necessary to duplicate some of +payloads) in a LAS 1.4 file structure, it is necessary to duplicate some of the fields within the LAS 1.4 file structure. These duplicate fields are named "Legacy xxx" where "xxx" denotes the meaning of the field. A LAS 1.4 file writer who wishes to maintain backward compatibility must maintain both the legacy fields and the equivalent non-legacy fields in -synchronization. Of course, this is not possible if the number of points +synchronization. However, this is not possible if the number of points exceeds UINT32_MAX, in which case the legacy fields must be set to zero. If a file writer is not maintaining backward compatibility, the legacy fields must always be set to zero. @@ -23,4 +23,8 @@ LAS 1.4 field, the LAS 1.4 reader should use the legacy value to maintain the same behavior as a LAS 1.1 through LAS 1.3 reader. Best practice is to also throw an informative error so that the file can be repaired. +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 compatibility must use only VLRs. See the +:ref:`evlr_legacy_label` section for more information. diff --git a/source/06_crs.txt b/source/02.02_crs.sub similarity index 91% rename from source/06_crs.txt rename to source/02.02_crs.sub index f080648..9b0cdb6 100644 --- a/source/06_crs.txt +++ b/source/02.02_crs.sub @@ -1,5 +1,5 @@ Coordinate Reference System (CRS) Representation --------------------------------------------------------------------------------- +................................................................................ GeoTIFF is being replaced by Well Known Text (WKT) as the required Coordinate Reference System (CRS) representation for the new point types (6-10) introduced @@ -15,7 +15,7 @@ A file writer who desires to maintain backward compatibility with legacy LAS for point types 0-5 must add a GeoTIFF VLR to represent the CRS for the file and ensure that the WKT bit is false. -The CRS representation is summarized in Table 2 +The CRS representation is summarized below: .. table:: Coordinate Reference System Representation @@ -30,11 +30,10 @@ The CRS representation is summarized in Table 2 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 existing CRS (E)VLR. Superseding is performed by changing the -LAS_Spec ID of the record to "Superseded", a new LASF_Spec defined in this +LAS_Spec ID of the record to ":ref:`superseded_vlr_label`", a new LASF_Spec defined in this release. - .. raw:: latex \newpage diff --git a/source/07_datatypes.txt b/source/02.03_datatypes.sub similarity index 63% rename from source/07_datatypes.txt rename to source/02.03_datatypes.sub index 7f0b64b..2d63e8c 100644 --- a/source/07_datatypes.txt +++ b/source/02.03_datatypes.sub @@ -15,6 +15,17 @@ data types are conformant to the 1999 ANSI C Language Specification * 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) +* string (a variable series of 1 byte characters, ASCII encoded, 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 ID or Description in the Variable Length Record, + and the Name of an Extra Byte Descriptor. + + +.. raw:: latex + + \newpage diff --git a/source/08_header.txt b/source/02.04_header.sub similarity index 78% rename from source/08_header.txt rename to source/02.04_header.sub index 624e9e1..26e2569 100644 --- a/source/08_header.txt +++ b/source/02.04_header.sub @@ -1,7 +1,7 @@ .. _headerblock_label: Public Header Block --------------------------------------------------------------------------------- +................................................................................ .. tabularcolumns:: |p{6.5cm}|p{4.0cm}|p{2.0cm}|p{1.5cm}| @@ -16,13 +16,13 @@ Public Header Block +----------------------------------+-------------------------+-----------+--------------+ | Global Encoding | unsigned short | 2 bytes | yes | +----------------------------------+-------------------------+-----------+--------------+ - | Project ID - GUID data 1 | unsigned long | 4 bytes | | + | Project ID - GUID Data 1 | unsigned long | 4 bytes | | +----------------------------------+-------------------------+-----------+--------------+ - | Project ID - GUID data 2 | unsigned short | 2 bytes | | + | Project ID - GUID Data 2 | unsigned short | 2 bytes | | +----------------------------------+-------------------------+-----------+--------------+ - | Project ID - GUID data 3 | unsigned short | 2 bytes | | + | Project ID - GUID Data 3 | unsigned short | 2 bytes | | +----------------------------------+-------------------------+-----------+--------------+ - | Project ID - GUID data 4 | unsigned char[8] | 8 bytes | | + | Project ID - GUID Data 4 | unsigned char[8] | 8 bytes | | +----------------------------------+-------------------------+-----------+--------------+ | Version Major | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+--------------+ @@ -85,7 +85,7 @@ Public Header Block +----------------------------------+-------------------------+-----------+--------------+ | Number of Point Records | unsigned long long | 8 bytes | yes | +----------------------------------+-------------------------+-----------+--------------+ - | Number of Points by Return | unsigned long long [15] | 120 bytes | yes | + | Number of Points by Return | unsigned long long[15] | 120 bytes | yes | +----------------------------------+-------------------------+-----------+--------------+ .. note:: @@ -94,28 +94,28 @@ Public Header Block must be zero filled. -File Signature -................................................................................ +**File Signature** The file signature must contain the four characters "LASF", and it is required by the LAS specification. These four characters can be checked by user software as a quick look initial determination of file type. -File Source ID -................................................................................ +**File Source ID** -This field should be set to a value ranging from 1 to 65,535. If this file was -derived from an original flight line, this is often the flight line number. A -value of zero (0) is interpreted to mean that an ID has not been assigned. In -this case, processing software is free to assign a number. Note that this -scheme allows a LIDAR project to contain up to 65,535 unique sources. A source -can be an original flight line or it can be result of merge and/or extract -operations. +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 multiple independent sources (e.g., a +tile merged from multiple swaths). -.. _globalencoding_label: +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 identifier for static +systems. -Global Encoding -................................................................................ +.. _globalencoding_link: + +**Global Encoding** 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 @@ -123,7 +123,7 @@ is defined (this is the bit, that if set, would have the unsigned integer yield a value of 1). This bit field is defined as: -.. tabularcolumns:: |p{2.0cm}|p{6.0cm}|p{8.5cm}| +.. tabularcolumns:: |p{2.0cm}|p{3.0cm}|p{11.0cm}| .. table:: Global Encoding -- Bit Field Encoding @@ -140,7 +140,9 @@ a value of 1). This bit field is defined as: | | | 1 x :math:`10^9` (Adjusted Standard GPS | | | | Time). The offset moves the time back to | | | | near zero to improve floating point | - | | | resolution. | + | | | resolution. The origin of standard GPS | + | | | Time is defined as midnight of the | + | | | morning of January 6, 1980. | +-------+-----------------------+------------------------------------------+ | 1 | Waveform Data Packets | If this bit is set, the waveform data | | | Internal | packets are located within this file | @@ -155,15 +157,15 @@ a value of 1). This bit field is defined as: | | | (note that this bit is mutually | | | | exclusive with bit 1) | +-------+-----------------------+------------------------------------------+ - | 3 | Return numbers have | If this bit is set, the point return | - | | been synthetically | numbers in the point data records have | - | | generated | been synthetically generated. This could | + | 3 | Synthetic Return | If this bit is set, the point return | + | | Numbers | numbers in the point data records have | + | | | been synthetically generated. This could | | | | be the case, for example, when a | | | | composite file is created by combining a | | | | First Return File and a Last Return | - | | | File. In this case, first return data | - | | | will be labeled "1 of 2" and second | - | | | return data will be labeled "2 of 2". | + | | | File, or when simulating return numbers | + | | | for a system not directly supporting | + | | | multiple returns. | +-------+-----------------------+------------------------------------------+ | 4 | WKT | If set, the Coordinate Reference System | | | | (CRS) is WKT. If not set, the CRS is | @@ -175,8 +177,8 @@ a value of 1). This bit field is defined as: | 5:15 | Reserved | Must be set to zero (0). | +-------+-----------------------+------------------------------------------+ -Project ID (GUID data) -................................................................................ + +**Project ID (GUID Data)** 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 @@ -186,8 +188,12 @@ associated with a unique project. By assigning a Project ID and using a File Source ID (defined above) every file within a project and every point within a file can be uniquely identified, globally. -Version Number -............................................................................... +.. note:: + + Example implementations of representing the Project ID fields as a GUID can + be found on the official LAS wiki: https://github.com/ASPRSorg/LAS/wiki + +**Version Number** The version number consists of a major and minor field. The major and minor fields combine to form the number that indicates the format number of the @@ -196,12 +202,11 @@ 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 version number. -System Identifier -................................................................................ +**System Identifier** The version 1.0 specification assumed that LAS files are exclusively generated as a result of collection by a hardware sensor. Subsequent versions recognize -that files often result from extraction, merging or modifying existing data +that files often result from extraction, merging, or modifying existing data files. Thus System ID becomes: .. tabularcolumns:: |p{6.5cm}|p{9.5cm}| @@ -211,8 +216,8 @@ files. Thus System ID becomes: +-----------------------------+---------------------------------------------+ | Generating Agent | System ID | +=============================+=============================================+ - | Hardware system | String identifying hardware (e.g. "ALTM | - | | 1210", "ALS50", "LMS-Q680i" etc. | + | Hardware system | String identifying hardware (e.g., "ALTM | + | | 1210", "ALS50", "LMS-Q680i", etc. | +-----------------------------+---------------------------------------------+ | Merge of one or more files | "MERGE" | +-----------------------------+---------------------------------------------+ @@ -231,29 +236,24 @@ files. Thus System ID becomes: -Generating Software -................................................................................ +**Generating Software** 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 file creation (e.g. "TerraScan V-10.8", "REALM -V-4.2" etc.). If the character data is less than 32 characters, the remaining +version was used during LAS file creation (e.g., "TerraScan V-10.8", "REALM +V-4.2", etc.). If the character data is less than 32 characters, the remaining data must be null. -File Creation Day of Year -................................................................................ +**File Creation Day of Year** Day, expressed as an unsigned short, on which this file was created. Day is computed as the Greenwich Mean Time (GMT) day. January 1 is considered day 1. -File Creation Year -................................................................................ +**File Creation Year** The year, expressed as a four digit number, in which the file was created. - -Header Size -................................................................................ +**Header Size** 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 @@ -261,59 +261,52 @@ 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. The Public Header Block may not be extended by users. -Offset to point data -................................................................................ +**Offset to Point Data** The actual number of bytes from the beginning of the file to the first field of the first point record data field. This data offset must be updated if any software adds/removes data to/from the Variable Length Records. -Number of Variable Length Records -................................................................................ +**Number of Variable Length Records** This field contains the current number of VLRs that are stored in the file preceding the Point Data Records. This number must be updated if the number of VLRs changes. -Point Data Record Format -................................................................................ +**Point Data Record Format** -The point data record indicates the type of point data records contains in the -file. LAS 1.4 defines types 0 through 10. These types are defined in the Point -Data Record Format section of this specification. +The point data record indicates the type of point data records contained in the +file. LAS 1.4 defines types 0 through 10. These types are defined in the +:ref:`ptrecords_label` section of this specification. -Point Data Record Length -................................................................................ +**Point Data Record Length** The size, in bytes, of the Point Data Record. All Point Data Records within a single LAS file must be the same type and hence the same length. If the -specified size is larger than implied by the point format type (e.g. 32 bytes +specified size is larger than implied by the point format type (e.g., 32 bytes instead of 28 bytes for type 1) the remaining bytes are user-specific "extra -bytes. The format and meaning of such "extra bytes" can (optionally) be -described with an Extra Bytes VLR (see Table 24 and Table 25). - +bytes". The format and meaning of such "extra bytes" can (optionally) be +described with an :ref:`extrabytes_vlr_label` VLR. -Legacy Number of point records -................................................................................ +**Legacy Number of Point Records** This field contains the total number of point records within the file if the -file is maintaining legacy compatibility and the number of points is no greater -than UINT32_MAX. It must be zero otherwise. +file is maintaining legacy compatibility, the number of points is no greater +than UINT32_MAX, and the Point Data Record Format is less than 6. Otherwise, +it must be set to zero. - -Legacy Number of points by return -................................................................................ +**Legacy Number of Points by Return** These fields contain an array of the total point records per return if the file -is maintaining legacy compatibility and the number of points is no greater than -UINT32_MAX. The first value will be the total number of records from the first -return, the second contains the total number for return two, and so on up to -five returns. If the file is not maintaining legacy compatibility, each member -of the array must be set to zero. +is maintaining legacy compatibility, the number of points is no greater than +UINT32_MAX, and the Point Data Record Format is less than 6. Otherwise, each +member of the array must be set to zero. +The first value will be the total number of records from the first +return, the second contains the total number for return two, and so on up to +five returns. -X, Y, and Z scale factors -................................................................................ +**X, Y, and Z Scale Factors** The scale factor fields contain a double floating point value that is used to scale the corresponding X, Y, and Z long values within the point records. The @@ -322,9 +315,7 @@ 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 factor will contain the number 0.01. - -X, Y, and Z offset -................................................................................ +**X, Y, and Z Offsets** The offset fields should be used to set the overall offset for the point records. In general these numbers will be zero, but for certain cases the @@ -342,45 +333,39 @@ the X scale factor, and then add the X offset. Z_{coordinate} &= (Z_{record} * Z_{scale}) + Z_{offset} \end {eqnarray} -Max and Min X, Y, and Z -................................................................................ +**Max and Min X, Y, and Z** + The max and min data fields are the actual unscaled extents of the LAS point file data, specified in the coordinate system of the LAS data. -Start of Waveform Data Packet Record -................................................................................ +**Start of Waveform Data Packet Record** This value provides the offset, in bytes, from the beginning of the LAS file to the first byte of the Waveform Data Package Record. Note that this will be the first byte of the Waveform Data Packet header. If no waveform records are -contained within the file, this value must be zero. It should be noted that LAS -1.4 allows multiple Extended Variable Length Records (EVLR) and that the +contained within the file or they are stored externally, this value must be zero. It should be noted that LAS +1.4 allows multiple Extended Variable Length Records (EVLRs) and that the Waveform Data Packet Record is not necessarily the first EVLR in the file. - -Start of First Extended Variable Length Record -................................................................................ +**Start of First Extended Variable Length Record** This value provides the offset, in bytes, from the beginning of the LAS file to the first byte of the first EVLR. -Number of Extended Variable Length Records -................................................................................ +**Number of Extended Variable Length Records** This field contains the current number of EVLRs (including, if present, the Waveform Data Packet Record) that are stored in the file after the Point Data Records. This number must be updated if the number of EVLRs changes. If there are no EVLRs this value is zero. -Number of point records -................................................................................ +**Number of Point Records** This field contains the total number of point records in the file. Note that this field must always be correctly populated, regardless of legacy mode intent. -Number of points by return -................................................................................ +**Number of Points by Return** 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 @@ -388,4 +373,3 @@ contains the total number for return two, and so on up to fifteen returns. Note that these fields must always be correctly populated, regardless of legacy mode intent. - diff --git a/source/09_vlr.txt b/source/02.05_vlr.sub similarity index 83% rename from source/09_vlr.txt rename to source/02.05_vlr.sub index 1820824..a018f82 100644 --- a/source/09_vlr.txt +++ b/source/02.05_vlr.sub @@ -1,5 +1,7 @@ +.. _vlrdef_label: + 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 @@ -29,44 +31,39 @@ Record Header is 54 bytes in length. | Description | char[32] | 32 bytes | | +----------------------------------+-------------------------+-----------+----------+ -Reserved -................................................................................ +**Reserved** This value must be set to zero. -User ID -................................................................................ +**User ID** -The User ID field is ASCII character data that identifies the user which +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 User IDs ensures that no two individuals accidentally use the same User ID. -Record ID -................................................................................ +**Record ID** The Record ID is dependent upon the User ID. There can be 0 to 65,535 Record IDs for every User ID. The LAS specification manages its own Record IDs (User -IDs owned by the specification), otherwise Record IDs will be managed by the +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 combinations should be ignored. -Record Length After Header -................................................................................ +**Record Length After Header** 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 bytes in the variable length portion of the record. -Description -................................................................................ +**Description** -Optional, null terminated text description of the data. Any remaining +Optional text description of the data. Any remaining characters not used must be null. .. raw:: latex diff --git a/source/10_point.txt b/source/02.06_point.sub similarity index 72% rename from source/10_point.txt rename to source/02.06_point.sub index 29bc7f5..ab12777 100644 --- a/source/10_point.txt +++ b/source/02.06_point.sub @@ -1,21 +1,48 @@ +.. _ptrecords_label: + Point Data Records --------------------------------------------------------------------------------- +................................................................................ -LAS file I/O software must use the "Offset to point data" field in the Public +LAS file I/O software must use the "Offset to Point Data" field in the Public Header Block to locate the starting position of the first Point Data Record. -Note that all Point Data Records must be the same type (i.e. Point Data Record -Format). Point data items that are not 'Required' must be set to the equivalent -of zero for the data type (e.g. 0.0 for floating types, null for ASCII, 0 for -integers). +Note that all Point Data Records must be the same type (i.e., Point Data Record +Format). -Point Data Record Format 6-10 have improved several aspects of the core +Point Data Record Formats (PDRFs) 6-10 have improved several aspects of the core information in the point data records, particularly support for 256 classes and -the definition of a specific "Overlap" bit. While all point record formats -(0-10) are supported in LAS 1.4, the preferred formats are 6-10. +the definition of a specific "Overlap" bit. While all PDRFs (0-10) are supported +in LAS 1.4, the preferred formats are 6-10. PDRFs 0-5 are therefore designated +as the "legacy" point formats. + +**Required Point Attributes** + +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.0 for floating types, +null for ASCII, 0 for integers). + +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 zero if unspecified in the attribute +description. + +.. _aggregate_link: + +**Aggregate Model Systems** + +Points derived from multiple observations in an aggregate model rather than +a direct measurement system should be assigned valid values using a consistent +scheme for a given dataset. For example, 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 applies include photogrammetrically derived point clouds and +Geiger-mode lidar processed with a consensus model. These systems are hereafter +collectively denoted as "Aggregate Model Systems." Point Data Record Format 0 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 0 contains the core 20 bytes that are shared by Point Data Record Formats 0 to 5. @@ -37,7 +64,7 @@ Data Record Formats 0 to 5. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 3 bits (bits 0-2) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 3 bits (bits 3-5) | 3 bits | yes | + | Number of Returns (Given Pulse) | 3 bits (bits 3-5) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -46,71 +73,93 @@ Data Record Formats 0 to 5. | Classification | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Angle Rank (-90 to +90) -- | signed char | 1 byte | yes | - | Left side | | | | + | Left Side | | | | +----------------------------------+-------------------------+-----------+----------+ | User Data | unsigned char | 1 byte | no | +----------------------------------+-------------------------+-----------+----------+ | Point Source ID | unsigned short | 2 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* [1]_ | *20 bytes* | + +------------------------------------------------------------+----------------------+ -X, Y, and Z -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. [1] Recall that the Point Data Record Size can be greater than the minimum + required for a PDRF. These "extra bytes" follow the standard Point Record + fields and are described in the :ref:`extrabytes_vlr_label` VLR section. + +**X, Y, and Z** The X, Y, and Z values are stored as long integers. The X, Y, and Z values are used in conjunction with the scale values and the offset values to determine the coordinate for each point as described in the :ref:`headerblock_label` section. -Intensity -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Intensity** -The intensity value is the integer representation of the pulse return +The Intensity value is the integer representation of the pulse return magnitude. This value is optional and system specific. However, it should -always be included if available. Intensity, when included, is always normalized +always be included if available. If Intensity is not included, this value must +be set to zero. + +Intensity, when included, is always normalized to a 16 bit, unsigned value by multiplying the value by 65,536/(intensity dynamic range of the sensor). For example, if the dynamic range of the sensor -is 10 bits, the scaling value would be (65,536/1,024). If intensity is not -included, this value must be set to zero. This normalization is required to +is 10 bits, the scaling value would be (65,536/1,024). This normalization is required to ensure that data from different sensors can be correctly merged. +For systems based on technology other than pulsed lasers, Intensity values may +represent estimated relative reflectivity, rather than a direct measurement of +pulse return magnitude, and may be derived from multiple sources. + .. note:: Please note that the following four fields (Return Number, Number of Returns, - Scan Direction Flag and Edge of Flight Line) are bit fields within a single + Scan Direction Flag, and Edge of Flight Line) are bit fields within a single byte. -Return Number -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Return Number** The Return Number is the pulse return number for a given output pulse. A given output laser pulse 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. +Return Number of two, and so on up to five returns. The Return Number must +be between 1 and the Number of Returns, inclusive. -Number of Returns (given pulse) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For systems unable to record multiple returns, the Return Number should be +set to one, unless it is synthetically derived and the Synthetic Return Number +Global Encoding bit is set. + +**Number of Returns (Given Pulse)** The Number of Returns is the total number of returns for a given pulse. For example, a laser data point may be return two (Return Number) within a total -number of five returns. +number of up to five returns. -Scan Direction Flag -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For systems unable to record multiple returns, the Number of Returns should be +set to one, unless it is synthetically derived and the Synthetic Return Number +Global Encoding bit is set. + +**Scan Direction Flag** -The Scan Direction Flag denotes the direction at which the scanner mirror was +The Scan Direction Flag denotes the direction in which the scanner mirror was traveling at the time 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 direction to the right side and negative the opposite). -Edge of Flight Line -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For :ref:`Aggregate Model Systems ` or if the measurement system +does not include a rotational component, the Scan Direction Flag should be set +to zero. + +**Edge of Flight Line Flag** -The Edge of Flight Line data bit has a value of 1 only when the point is at the +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 last point on a given scan line before it changes -direction. +direction or the mirror facet changes. -Classification -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Note that this field has no meaning for :ref:`Aggregate Model Systems ` +or 360 degree Field of View scanners (e.g., terrestrial lidar scanners). In +these cases, the Edge of Flight Line Flag should be set to zero. + +**Classification** This field represents the "class" attributes of a point. If a point has never been classified, this byte must be set to zero. The format for classification @@ -121,23 +170,27 @@ the classification values in Table 9. .. tabularcolumns:: |p{2.0cm}|p{3.0cm}|p{8.5cm}| -.. table:: Classification Bit Field Encoding for Point Record types 0 to 5 +.. table:: Classification Bit Field Encoding (Point Data Record Formats 0-5) +-------+-------------------------+------------------------------------------+ | Bit | Field Name | Description | +=======+=========================+==========================================+ | 0:4 | Classification | Standard ASPRS classification from | | | | 0 to 31 as defined in the classification | - | | | table for legacy point formats | - | | | (see :ref:`point_classes`) | + | | | table for legacy point formats (see | + | | | :ref:`Reserved Point Classes | + | | | `). | +-------+-------------------------+------------------------------------------+ | 5 | Synthetic | If set then this point was created by a | - | | | technique other than LIDAR collection | + | | | technique other than direct observation | | | | such as digitized from a photogrammetric | | | | stereo model or by traversing a | - | | | waveform. | + | | | waveform. Point attribute interpretation | + | | | might differ from non-Synthetic points. | + | | | Unused attributes must be set to the | + | | | appropriate default value. | +-------+-------------------------+------------------------------------------+ - | 6 | Key-point | If set, this point is considered to be a | + | 6 | Key-Point | If set, this point is considered to be a | | | | model key-point and thus generally | | | | should not be withheld in a thinning | | | | algorithm. | @@ -151,26 +204,25 @@ the classification values in Table 9. 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* point that had been - *Synthetically* collected and marked as a model *key-point*. + the lower five bits set to 2 would be a *Ground* point that had been + *Synthetically* collected and marked as a model *Key-Point*. -.. _point_classes: +.. _legacy_pt_class_link: -Reserved Point Classes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Reserved Point Classes** Classification must adhere to the following standard: .. tabularcolumns:: |p{6.0cm}|p{8.0cm}| -.. table:: ASPRS Standard LIDAR Point Classes (Point Data Record Format 0-5) +.. table:: ASPRS Standard Point Classes (Point Data Record Formats 0-5) +-----------------------------------+-----------------------------------------------+ - | Classification Value (bits 0:4) | Meaning | + | Classification Value (Bits 0:4) | Meaning | +===================================+===============================================+ - | 0 | Created, never classified | + | 0 | Created, Never Classified | +-----------------------------------+-----------------------------------------------+ - | 1 | Unclassified [1]_ | + | 1 | Unclassified [2]_ | +-----------------------------------+-----------------------------------------------+ | 2 | Ground | +-----------------------------------+-----------------------------------------------+ @@ -182,9 +234,9 @@ Classification must adhere to the following standard: +-----------------------------------+-----------------------------------------------+ | 6 | Building | +-----------------------------------+-----------------------------------------------+ - | 7 | Low Point (noise) | + | 7 | Low Point (Noise) | +-----------------------------------+-----------------------------------------------+ - | 8 | Model Key-point (mass point) | + | 8 | Model Key-Point (Mass Point) | +-----------------------------------+-----------------------------------------------+ | 9 | Water | +-----------------------------------+-----------------------------------------------+ @@ -192,7 +244,7 @@ Classification must adhere to the following standard: +-----------------------------------+-----------------------------------------------+ | 11 | *Reserved for ASPRS Definition* | +-----------------------------------+-----------------------------------------------+ - | 12 | Overlap Points [2]_ | + | 12 | Overlap Points [3]_ | +-----------------------------------+-----------------------------------------------+ | 13-31 | *Reserved for ASPRS Definition* | +-----------------------------------+-----------------------------------------------+ @@ -206,7 +258,7 @@ Classification must adhere to the following standard: 1 set to 1 equals 2, bit 2 set to 1 equals 4 and so forth. -.. [1] We are using both 0 and 1 as *Unclassified* to maintain compatibility with +.. [2] We are using both 0 and 1 as *Unclassified* to maintain compatibility with current popular classification software such as TerraScan. We extend the idea of classification value 1 to include cases in which data have been subjected to a classification algorithm but emerged in an undefined state. For example, data @@ -214,14 +266,13 @@ Classification must adhere to the following standard: points that emerge without having been assigned as belonging to structures could be remapped from class 0 to class 1. -.. [2] Overlap Points are those points that were immediately culled during the +.. [3] Overlap Points are those points that were immediately culled during the merging of overlapping flight lines. In general, the *Withheld* bit should be set since these points are not subsequently classified. -Scan Angle Rank -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Scan Angle Rank** -The Scan Angle Rank is a signed one-byte number with a valid range from -90 to +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 within 1 degree of @@ -229,29 +280,31 @@ accuracy from +90 to -90 degrees. The scan angle is an angle based on 0 degrees being nadir, and -90 degrees to the left side of the aircraft in the direction of flight. -User Data -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For :ref:`Aggregate Model Systems `, the Scan Angle Rank should +be set to zero unless assigned from a component measurement. + +**User Data** This field may be used at the user's discretion. -Point Source ID -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Point Source ID** + +This value indicates the source from which this point originated. A source is +typically defined as a grouping of temporally consistent data, such as a +flight line or sortie number for airborne systems, a route number for mobile +systems, or a setup identifier for static systems. Valid values for this field +are 1 to 65,535 inclusive. Zero is reserved as a convenience to system +implementers. -This value indicates the file from which this point originated. Valid values -for this field are 1 to 65,535 inclusive with zero being used for a special -case discussed below. The numerical value corresponds to the File Source ID -from which this point originated. Zero is reserved as a convenience to system -implementers. A Point Source ID of zero implies that this point originated in -this file. This implies that processing software should set the Point Source ID -equal to the File Source ID of the file containing this point at some time -during processing. +For :ref:`Aggregate Model Systems `, the Point Source ID should +be set to one (1) unless assigned from a component measurement. .. raw:: latex \newpage 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. @@ -274,7 +327,7 @@ addition of GPS Time. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 3 bits (bits 0-2) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 3 bits (bits 3-5) | 3 bits | yes | + | Number of Returns (Given Pulse) | 3 bits (bits 3-5) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -283,7 +336,7 @@ addition of GPS Time. | Classification | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Angle Rank (-90 to +90) -- | signed char | 1 byte | yes | - | Left side | | | | + | Left Side | | | | +----------------------------------+-------------------------+-----------+----------+ | User Data | unsigned char | 1 byte | no | +----------------------------------+-------------------------+-----------+----------+ @@ -291,25 +344,29 @@ addition of GPS Time. +----------------------------------+-------------------------+-----------+----------+ | GPS Time | double | 8 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *28 bytes* | + +------------------------------------------------------------+----------------------+ -GPS Time -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**GPS Time** The GPS Time is the double floating point time tag value at which the point was -acquired. It is GPS Week Time if the Global Encoding low bit is clear and -Adjusted Standard GPS Time if the Global Encoding low bit is set (see -:ref:`globalencoding_label` in the :ref:`headerblock_label` description). +observed. It is GPS Week Time if the :ref:`Global Encoding ` +low bit is clear and Adjusted Standard GPS Time if the bit is set. + +For :ref:`Aggregate Model Systems `, the GPS Time should be set +to zero unless assigned from a component measurement. + .. raw:: latex \newpage Point Data Record Format 2 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 2 is the same as Point Data Record Format 0 with the addition of three color channels. These fields are used when "colorizing" a -LIDAR point using ancillary data, typically from a camera. +point using ancillary data, typically from a camera. .. tabularcolumns:: |p{7.5cm}|p{3.5cm}|p{1.5cm}|p{1.5cm}| @@ -328,7 +385,7 @@ LIDAR point using ancillary data, typically from a camera. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 3 bits (bits 0-2) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 3 bits (bits 3-5) | 3 bits | yes | + | Number of Returns (Given Pulse) | 3 bits (bits 3-5) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -337,7 +394,7 @@ LIDAR point using ancillary data, typically from a camera. | Classification | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Angle Rank (-90 to +90) -- | signed char | 1 byte | yes | - | Left side | | | | + | Left Side | | | | +----------------------------------+-------------------------+-----------+----------+ | User Data | unsigned char | 1 byte | no | +----------------------------------+-------------------------+-----------+----------+ @@ -349,14 +406,16 @@ LIDAR point using ancillary data, typically from a camera. +----------------------------------+-------------------------+-----------+----------+ | Blue | unsigned short | 2 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *26 bytes* | + +------------------------------------------------------------+----------------------+ + +**Red, Green, and Blue** -Red, Green, and Blue -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Red, Green, and Blue image channel values associated with this point. .. note:: - The Red, Green, Blue values should always be normalized to 16 bit values. + 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 be accurately @@ -367,7 +426,7 @@ The Red, Green, and Blue image channel values associated with this point. \newpage 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. @@ -389,7 +448,7 @@ addition of GPS Time. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 3 bits (bits 0-2) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 3 bits (bits 3-5) | 3 bits | yes | + | Number of Returns (Given Pulse) | 3 bits (bits 3-5) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -398,7 +457,7 @@ addition of GPS Time. | Classification | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Angle Rank (-90 to +90) -- | signed char | 1 byte | yes | - | Left side | | | | + | Left Side | | | | +----------------------------------+-------------------------+-----------+----------+ | User Data | unsigned char | 1 byte | no | +----------------------------------+-------------------------+-----------+----------+ @@ -412,13 +471,15 @@ addition of GPS Time. +----------------------------------+-------------------------+-----------+----------+ | Blue | unsigned short | 2 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *34 bytes* | + +------------------------------------------------------------+----------------------+ .. raw:: latex \newpage Point Data Record Format 4 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 4 adds Wave Packets to Point Data Record Format 1. @@ -439,7 +500,7 @@ Point Data Record Format 4 adds Wave Packets to Point Data Record Format 1. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 3 bits (bits 0-2) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 3 bits (bits 3-5) | 3 bits | yes | + | Number of Returns (Given Pulse) | 3 bits (bits 3-5) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -448,7 +509,7 @@ Point Data Record Format 4 adds Wave Packets to Point Data Record Format 1. | Classification | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Angle Rank (-90 to +90) -- | signed char | 1 byte | yes | - | Left side | | | | + | Left Side | | | | +----------------------------------+-------------------------+-----------+----------+ | User Data | unsigned char | 1 byte | no | +----------------------------------+-------------------------+-----------+----------+ @@ -458,66 +519,62 @@ Point Data Record Format 4 adds Wave Packets to Point Data Record Format 1. +----------------------------------+-------------------------+-----------+----------+ | Wave Packet Descriptor Index | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ - | Byte offset to waveform data | unsigned long long | 8 bytes | yes | + | Byte Offset to Waveform Data | unsigned long long | 8 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Waveform packet size in bytes | unsigned long | 4 bytes | yes | + | Waveform Packet Size in Bytes | unsigned long | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ | Return Point Waveform Location | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | X(t) | float | 4 bytes | yes | + | Parametric dx | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Y(t) | float | 4 bytes | yes | + | Parametric dy | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Z(t) | float | 4 bytes | yes | + | Parametric dz | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *57 bytes* | + +------------------------------------------------------------+----------------------+ -Wave Packet Descriptor Index -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Wave Packet Descriptor Index** -This value plus **99** is the Record ID of the Waveform Packet Descriptor and +This value plus **99** is the Record ID of the :ref:`fwf_descriptor_label` and indicates the User Defined Record that describes the waveform packet associated -with this LIDAR point. Up to 255 different User Defined Records which describe +with this Point Record. Up to 255 different User Defined Records which describe the waveform packet are supported. A value of zero indicates that there is no -waveform data associated with this LIDAR point record. +waveform data associated with this Point Record. -Byte offset to Waveform Packet Data -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Byte Offset to Waveform Data** The waveform packet data are stored in the LAS file in an Extended Variable -Length Record or in an auxiliary WPD file. The Byte Offset represents the -location of the start of this LIDAR points’ waveform packet within the waveform +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 Packet Data header. The absolute location of the beginning of this +:ref:`fwf_packets_label` header. The absolute location of the beginning of this waveform packet relative to the beginning of the file is given by: - **Start of Waveform Data Packet Record** + **Byte offset to Waveform Packet Data** + **Start of Waveform Data Packet Record** + **Byte Offset to Waveform Data** for waveform packets stored within the LAS file and - **Byte offset to Waveform Packet Data** + **Byte Offset to Waveform Data** - for data stored in an auxiliary file + for data stored in an auxiliary *.wdp file. -Waveform packet size in bytes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Waveform Packet Size in Bytes** 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 Waveform Packet +waveform packets can be located only via the Byte Offset to Waveform Packet Data value since there is no requirement that records be stored sequentially. -Return Point location -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Return Point Waveform Location** -The offset in picoseconds (:math:`10^{-12}`) from the first digitized value to the -location within the waveform packet that the associated return pulse was -detected. +The temporal offset in picoseconds (:math:`10^{-12}`) from the arbitrary "anchor +point" to the location within the waveform packet for this Point Record. -X(t), Y(t), Z(t) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Parametric dx, dy, dz** These parameters define a parametric line equation for extrapolating points along the associated waveform. The position along the wave is given by: @@ -526,25 +583,47 @@ along the associated waveform. The position along the wave is given by: :nowrap: \begin {eqnarray} - X &= X_0 + X(t) \\ - Y &= Y_0 + Y(t) \\ - Z &= Z_0 + Z(t) + X &= X_0 + t * dx \\ + Y &= Y_0 + t * dy \\ + Z &= Z_0 + t * dz \end {eqnarray} -where X, Y and Z are the spatial position of the derived point, :math:`X_0`, -:math:`Y_0`, :math:`Z_0` are the position of the "anchor" point (the X, Y, Z -locations from this point's data record) and :math:`t` is the time, in picoseconds, -relative to the anchor point (i.e. :math:`t = 0` at the anchor point). The units of -X, Y and Z are the units of the coordinate systems of the LAS data. If the -coordinate system is geographic, the horizontal units are decimal degrees and -the vertical units are meters. +where :math:`(X, Y, Z)` is the spatial position of a derived point, +:math:`(X_0, Y_0, Z_0)` is the position of the "anchor" point, and :math:`t` is +the time, in picoseconds, relative to the anchor point. + +The anchor point is an arbitrary location at the origin of the associated +waveform -- i.e. :math:`t = 0` at the anchor point -- with coordinates defined +by: + +.. math:: + :nowrap: + + \begin {eqnarray} + X_0 &= X_P + L * dx \\ + Y_0 &= Y_P + L * dy \\ + Z_0 &= Z_P + L * dz + \end {eqnarray} + +where :math:`(X_P, Y_P, Z_P)` is this Point Record's transformed position (as a +double) and :math:`L` is this Point Record's Return Point Waveform Location. + +The units of X, Y and Z are the units of the coordinate systems of the LAS data. +If the coordinate system is geographic, the horizontal units are decimal degrees +and the vertical units are meters. + +.. note:: + + Users seeking further clarity regarding LAS waveform encoding are encouraged + to learn more on the official LAS wiki: https://github.com/ASPRSorg/LAS/wiki + .. raw:: latex \newpage Point Data Record Format 5 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 5 adds Wave Packets to Point Data Record Format 3. @@ -565,7 +644,7 @@ Point Data Record Format 5 adds Wave Packets to Point Data Record Format 3. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 3 bits (bits 0-2) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 3 bits (bits 3-5) | 3 bits | yes | + | Number of Returns (Given Pulse) | 3 bits (bits 3-5) | 3 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -574,7 +653,7 @@ Point Data Record Format 5 adds Wave Packets to Point Data Record Format 3. | Classification | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Angle Rank (-90 to +90) -- | signed char | 1 byte | yes | - | Left side | | | | + | Left Side | | | | +----------------------------------+-------------------------+-----------+----------+ | User Data | unsigned char | 1 byte | no | +----------------------------------+-------------------------+-----------+----------+ @@ -590,25 +669,27 @@ Point Data Record Format 5 adds Wave Packets to Point Data Record Format 3. +----------------------------------+-------------------------+-----------+----------+ | Wave Packet Descriptor Index | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ - | Byte offset to waveform data | unsigned long long | 8 bytes | yes | + | Byte Offset to Waveform Data | unsigned long long | 8 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Waveform packet size in bytes | unsigned long | 4 bytes | yes | + | Waveform Packet Size in Bytes | unsigned long | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ | Return Point Waveform Location | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | X(t) | float | 4 bytes | yes | + | Parametric dx | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Y(t) | float | 4 bytes | yes | + | Parametric dy | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Z(t) | float | 4 bytes | yes | + | Parametric dz | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *63 bytes* | + +------------------------------------------------------------+----------------------+ .. raw:: latex \newpage 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 @@ -634,7 +715,7 @@ instead of 8), and the GPS time is mandatory. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 4 bits (bits 0-3) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 4 bits (bits 4-7) | 4 bits | yes | + | Number of Returns (Given Pulse) | 4 bits (bits 4-7) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Classification Flags | 4 bits (bits 0-3) | 4 bits | no | +----------------------------------+-------------------------+-----------+----------+ @@ -654,15 +735,16 @@ instead of 8), and the GPS time is mandatory. +----------------------------------+-------------------------+-----------+----------+ | GPS Time | double | 8 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *30 bytes* | + +------------------------------------------------------------+----------------------+ .. note:: The following five fields (Return Number, Number of Returns, Classification - Flags, Scan Direction Flag and Edge of Flight Line) are bit fields, encoded + Flags, Scan Direction Flag, and Edge of Flight Line) are bit fields, encoded into two bytes. -Return Number -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Return Number** The Return Number is the pulse return number for a given output pulse. A given output laser pulse can have many returns, and they must be marked in sequence @@ -670,33 +752,42 @@ 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 Return Number must be between 1 and the Number of Returns, inclusive. -Number of Returns (given pulse) -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For systems unable to record multiple returns, the Return Number should be +set to one, unless it is synthetically derived and the Synthetic Return Number +Global Encoding bit is set. + +**Number of Returns (Given Pulse)** The Number of Returns is the total number of returns for a given pulse. For example, a laser data point may be return two (Return Number) within a total number of up to fifteen returns. -Classification Flags -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For systems unable to record multiple returns, the Number of Returns should be +set to one, unless it is synthetically derived and the Synthetic Return Number +Global Encoding bit is set. + +**Classification Flags** Classification flags are used to indicate special characteristics associated with the point. The bit definitions are: .. tabularcolumns:: |p{2.0cm}|p{3.0cm}|p{8.5cm}| -.. table:: Classification Bit Field Encoding for Point Data types 6 to 10 +.. table:: Classification Bit Field Encoding (Point Data Record Formats 6-10) +-------+-------------------------+------------------------------------------+ | Bit | Field Name | Description | +=======+=========================+==========================================+ | 0 | Synthetic | If set then this point was created by a | - | | | technique other than LIDAR collection | + | | | technique other than direct observation | | | | such as digitized from a photogrammetric | | | | stereo model or by traversing a | - | | | waveform. | + | | | waveform. Point attribute interpretation | + | | | might differ from non-Synthetic points. | + | | | Unused attributes must be set to the | + | | | appropriate default value. | +-------+-------------------------+------------------------------------------+ - | 1 | Key-point | If set, this point is considered to be a | + | 1 | Key-Point | If set, this point is considered to be a | | | | model key-point and thus generally | | | | should not be withheld in a thinning | | | | algorithm. | @@ -717,93 +808,110 @@ with the point. The bit definitions are: .. note:: These bits are treated as flags and can be set or cleared in any combination. For example, a point with bits 0 and 1 both set to one and the - *Classification* field set to 2 would be a *ground* point that had been - *synthetically* collected and marked as a model *key-point*. + *Classification* field set to 2 would be a *Ground* point that had been + *Synthetically* collected and marked as a model *Key-Point*. -Scanner Channel -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Scanner Channel** Scanner Channel is used to indicate the channel (scanner head) of a multi- channel system. Channel 0 is used for single scanner systems. Up to four channels are supported (0-3). -Scan Direction Flag -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For :ref:`Aggregate Model Systems `, the Channel should be set +to zero unless assigned from a component measurement. + +**Scan Direction Flag** -The Scan Direction Flag denotes the direction at which the scanner mirror was +The Scan Direction Flag denotes the direction in which the scanner mirror was traveling at the time 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 direction to the right side and negative the opposite). -Edge of Flight Line -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The Edge of Flight Line data bit has a value of 1 only when the point is at the -end of a scan. It is the last point on a given scan line before it changes -direction or the mirror facet changes. Note that this field has no meaning for -360° Field of View scanners (such as Mobile LIDAR scanners) and should not be -set. - -Classification -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For :ref:`Aggregate Model Systems ` or if the measurement system +does not include a rotational component, the Scan Direction Flag should be set +to zero. -Classification must adhere to the following standard: +**Edge of Flight Line Flag** +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 last point on a given scan line before it changes +direction or the mirror facet changes. -.. tabularcolumns:: |p{6.0cm}|p{8.0cm}| +Note that this field has no meaning for :ref:`Aggregate Model Systems ` +or 360 degree Field of View scanners (e.g., terrestrial lidar scanners). In +these cases, the Edge of Flight Line Flag should be set to zero. -.. table:: ASPRS Standard LIDAR Point Classes (Point Data Record Formats 6-10) +**Classification** - +-----------------------------------+-----------------------------------------------+ - | Classification Value (bits 0:4) | Meaning | - +===================================+===============================================+ - | 0 | Created, never classified | - +-----------------------------------+-----------------------------------------------+ - | 1 | Unclassified [3]_ | - +-----------------------------------+-----------------------------------------------+ - | 2 | Ground | - +-----------------------------------+-----------------------------------------------+ - | 3 | Low Vegetation | - +-----------------------------------+-----------------------------------------------+ - | 4 | Medium Vegetation | - +-----------------------------------+-----------------------------------------------+ - | 5 | High Vegetation | - +-----------------------------------+-----------------------------------------------+ - | 6 | Building | - +-----------------------------------+-----------------------------------------------+ - | 7 | Low Point (noise) | - +-----------------------------------+-----------------------------------------------+ - | 8 | *Reserved* | - +-----------------------------------+-----------------------------------------------+ - | 9 | Water | - +-----------------------------------+-----------------------------------------------+ - | 10 | Rail | - +-----------------------------------+-----------------------------------------------+ - | 11 | Road Surface | - +-----------------------------------+-----------------------------------------------+ - | 12 | *Reserved* | - +-----------------------------------+-----------------------------------------------+ - | 13 | Wire -- Guard (Shield) | - +-----------------------------------+-----------------------------------------------+ - | 14 | Wire -- Conductor (Phase) | - +-----------------------------------+-----------------------------------------------+ - | 15 | Transmission Tower | - +-----------------------------------+-----------------------------------------------+ - | 16 | Wire-structure Connector (e.g Insulator) | - +-----------------------------------+-----------------------------------------------+ - | 17 | Bridge Deck | - +-----------------------------------+-----------------------------------------------+ - | 18 | High Noise | - +-----------------------------------+-----------------------------------------------+ - | 19-63 | *Reserved* | - +-----------------------------------+-----------------------------------------------+ - | 64-255 | User definable | - +-----------------------------------+-----------------------------------------------+ +Classification must adhere to the following standard: -.. [3] We are using both 0 and 1 as Unclassified to maintain compatibility +.. tabularcolumns:: |p{3.0cm}|p{5.0cm}|p{7.0cm}| + +.. table:: ASPRS Standard Point Classes (Point Data Record Formats 6-10) + + +------------------+-----------------------------+--------------------------------+ + | Value (Bits 0:4) | Meaning | Notes | + +==================+=============================+================================+ + | 0 | Created, Never Classified | See note [4]_ | + +------------------+-----------------------------+ + + | 1 | Unclassified | | + +------------------+-----------------------------+--------------------------------+ + | 2 | Ground | | + +------------------+-----------------------------+--------------------------------+ + | 3 | Low Vegetation | | + +------------------+-----------------------------+--------------------------------+ + | 4 | Medium Vegetation | | + +------------------+-----------------------------+--------------------------------+ + | 5 | High Vegetation | | + +------------------+-----------------------------+--------------------------------+ + | 6 | Building | | + +------------------+-----------------------------+--------------------------------+ + | 7 | Low Point (Noise) | | + +------------------+-----------------------------+--------------------------------+ + | 8 | *Reserved* | | + +------------------+-----------------------------+--------------------------------+ + | 9 | Water | | + +------------------+-----------------------------+--------------------------------+ + | 10 | Rail | | + +------------------+-----------------------------+--------------------------------+ + | 11 | Road Surface | | + +------------------+-----------------------------+--------------------------------+ + | 12 | *Reserved* | | + +------------------+-----------------------------+--------------------------------+ + | 13 | Wire -- Guard (Shield) | | + +------------------+-----------------------------+--------------------------------+ + | 14 | Wire -- Conductor (Phase) | | + +------------------+-----------------------------+--------------------------------+ + | 15 | Transmission Tower | | + +------------------+-----------------------------+--------------------------------+ + | 16 | Wire-Structure Connector | e.g., insulators | + +------------------+-----------------------------+--------------------------------+ + | 17 | Bridge Deck | | + +------------------+-----------------------------+--------------------------------+ + | 18 | High Noise | | + +------------------+-----------------------------+--------------------------------+ + | 19 | Overhead Structure | e.g., conveyors, mining | + | | | equipment, traffic lights | + +------------------+-----------------------------+--------------------------------+ + | 20 | Ignored Ground | e.g., breakline proximity | + +------------------+-----------------------------+--------------------------------+ + | 21 | Snow | | + +------------------+-----------------------------+--------------------------------+ + | 22 | Temporal Exclusion | Features excluded due to | + | | | changes over time between data | + | | | sources -- e.g., water levels, | + | | | landslides, permafrost | + +------------------+-----------------------------+--------------------------------+ + | 23-63 | *Reserved* | | + +------------------+-----------------------------+--------------------------------+ + | 64-255 | User Definable | | + +------------------+-----------------------------+--------------------------------+ + + +.. [4] We are using both 0 and 1 as Unclassified to maintain compatibility with current popular classification software such as TerraScan. We extend the idea of classification value 1 to include cases in which data have been subjected to a classification algorithm but emerged in an undefined state. For @@ -812,28 +920,31 @@ Classification must adhere to the following standard: structures could be remapped from class 0 to class 1. -Scan Angle -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Scan Angle** 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 +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 coordinate system of the data). The maximum value in -the negative direction is -30.000 which is also directly up. +the negative direction is -30,000 which is also directly up. + +For :ref:`Aggregate Model Systems `, the Scan Angle should be +set to zero unless assigned from a component measurement. + .. raw:: latex \newpage Point Data Record Format 7 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 7 is the same as Point Data Record Format 6 with the addition of three RGB color channels. These fields are used when "colorizing" a -LIDAR point using ancillary data, typically from a camera +point using ancillary data, typically from a camera. .. tabularcolumns:: |p{7.5cm}|p{3.5cm}|p{1.5cm}|p{1.5cm}| @@ -852,7 +963,7 @@ LIDAR point using ancillary data, typically from a camera +----------------------------------+-------------------------+-----------+----------+ | Return Number | 4 bits (bits 0-3) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 4 bits (bits 4-7) | 4 bits | yes | + | Number of Returns (Given Pulse) | 4 bits (bits 4-7) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Classification Flags | 4 bits (bits 0-3) | 4 bits | no | +----------------------------------+-------------------------+-----------+----------+ @@ -878,13 +989,15 @@ LIDAR point using ancillary data, typically from a camera +----------------------------------+-------------------------+-----------+----------+ | Blue | unsigned short | 2 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *36 bytes* | + +------------------------------------------------------------+----------------------+ .. raw:: latex \newpage Point Data Record Format 8 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 8 is the same as Point Data Record Format 7 with the addition of a NIR (near infrared) channel. @@ -906,7 +1019,7 @@ addition of a NIR (near infrared) channel. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 4 bits (bits 0-3) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 4 bits (bits 4-7) | 4 bits | yes | + | Number of Returns (Given Pulse) | 4 bits (bits 4-7) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Classification Flags | 4 bits (bits 0-3) | 4 bits | no | +----------------------------------+-------------------------+-----------+----------+ @@ -934,15 +1047,16 @@ addition of a NIR (near infrared) channel. +----------------------------------+-------------------------+-----------+----------+ | NIR | unsigned short | 2 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *38 bytes* | + +------------------------------------------------------------+----------------------+ -NIR -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**NIR** The NIR (near infrared) channel value associated with this point. .. note:: - Note that Red, Green, Blue and NIR values should always be normalized to 16 + 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 to be @@ -953,7 +1067,7 @@ The NIR (near infrared) channel value associated with this point. \newpage Point Data Record Format 9 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 9 adds Wave Packets to Point Data Record Format 6. @@ -974,11 +1088,11 @@ Point Data Record Format 9 adds Wave Packets to Point Data Record Format 6. +----------------------------------+-------------------------+-----------+----------+ | Return Number | 4 bits (bits 0-3) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 4 bits (bits 4-7) | 4 bits | yes | + | Number of Returns (Given Pulse) | 4 bits (bits 4-7) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Classification Flags | 4 bits (bits 0-3) | 4 bits | no | +----------------------------------+-------------------------+-----------+----------+ - | Scanner Channel | 2 bits (bits 4-5) | 2 bits | no | + | Scanner Channel | 2 bits (bits 4-5) | 2 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Scan Direction Flag | 1 bit (bit 6) | 1 bit | yes | +----------------------------------+-------------------------+-----------+----------+ @@ -996,25 +1110,27 @@ Point Data Record Format 9 adds Wave Packets to Point Data Record Format 6. +----------------------------------+-------------------------+-----------+----------+ | Wave Packet Descriptor Index | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ - | Byte offset to waveform data | unsigned long long | 8 bytes | yes | + | Byte Offset to Waveform Data | unsigned long long | 8 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Waveform packet size in bytes | unsigned long | 4 bytes | yes | + | Waveform Packet Size in Bytes | unsigned long | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ | Return Point Waveform Location | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | X(t) | float | 4 bytes | yes | + | Parametric dx | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Y(t) | float | 4 bytes | yes | + | Parametric dy | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Z(t) | float | 4 bytes | yes | + | Parametric dz | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *59 bytes* | + +------------------------------------------------------------+----------------------+ .. raw:: latex \newpage Point Data Record Format 10 -................................................................................ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Point Data Record Format 10 is the same as Point Data Record Format 9 with RGB and NIR values. @@ -1035,7 +1151,7 @@ Point Data Record Format 10 is the same as Point Data Record Format 9 with RGB a +----------------------------------+-------------------------+-----------+----------+ | Return Number | 4 bits (bits 0-3) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ - | Number of Returns (given pulse) | 4 bits (bits 4-7) | 4 bits | yes | + | Number of Returns (Given Pulse) | 4 bits (bits 4-7) | 4 bits | yes | +----------------------------------+-------------------------+-----------+----------+ | Classification Flags | 4 bits (bits 0-3) | 4 bits | no | +----------------------------------+-------------------------+-----------+----------+ @@ -1065,15 +1181,22 @@ Point Data Record Format 10 is the same as Point Data Record Format 9 with RGB a +----------------------------------+-------------------------+-----------+----------+ | Wave Packet Descriptor Index | unsigned char | 1 byte | yes | +----------------------------------+-------------------------+-----------+----------+ - | Byte offset to waveform data | unsigned long long | 8 bytes | yes | + | Byte Offset to Waveform Data | unsigned long long | 8 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Waveform packet size in bytes | unsigned long | 4 bytes | yes | + | Waveform Packet Size in Bytes | unsigned long | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ | Return Point Waveform Location | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | X(t) | float | 4 bytes | yes | + | Parametric dx | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Y(t) | float | 4 bytes | yes | + | Parametric dy | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ - | Z(t) | float | 4 bytes | yes | + | Parametric dz | float | 4 bytes | yes | +----------------------------------+-------------------------+-----------+----------+ + | *Minimum PDRF Size* | *67 bytes* | + +------------------------------------------------------------+----------------------+ + +.. raw:: latex + + \newpage + diff --git a/source/11_evlr.txt b/source/02.07_evlr.sub similarity index 67% rename from source/11_evlr.txt rename to source/02.07_evlr.sub index a875737..baebd96 100644 --- a/source/11_evlr.txt +++ b/source/02.07_evlr.sub @@ -2,8 +2,10 @@ \newpage +.. _evlrdef_label: + Extended Variable Length Records (EVLRs) -------------------------------------------------------------------------------- +................................................................................ The Point Record Data can be followed by any number of EVLRs. @@ -11,7 +13,7 @@ The EVLR is, in spirit, identical to a VLR but can carry a larger payload as the "Record Length After Header" field is 8 bytes instead of 2 bytes. The number of EVLRs is specified in the "Number of Extended Variable Length Records" field in the :ref:`headerblock_label`. The start of the first EVLR is at -the file offset indicated by the "Start of first Extended Variable Length +the file offset indicated by the "Start of First Extended Variable Length Record" in the :ref:`headerblock_label`. 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. Each Extended Variable @@ -39,5 +41,21 @@ Length Record Header is 60 bytes in length. As with the VLR, the Reserved field must be set to zero. +.. _evlr_legacy_label: + +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 a VLR can elect to use an +EVLR, even for predefined VLRs such as Coordinate Reference System (CRS) +information. This ability is useful, for example, when a user wishes to update +information normally contained within a VLR without the need of rewriting the +point data. + +A new LASF_Spec ":ref:`superseded_vlr_label`" VLR (value 7) has been defined to allow a writer to +indicate that 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 is no longer in use. diff --git a/source/03_required_vlrs.txt b/source/03_required_vlrs.txt new file mode 100644 index 0000000..818b9ad --- /dev/null +++ b/source/03_required_vlrs.txt @@ -0,0 +1,190 @@ +.. raw:: latex + + \newpage + +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 VLRs and EVLRs are defined in the following two sections. + +Coordinate Reference System Information +................................................................................ + +The Coordinate Reference System (CRS) information for the point data is +required for all data. The CRS information will be placed in Variable Length +Records or Extended Variable Length Records (note that if the writer wishes to +maintain legacy compatibility, then GeoTIFF in VLRs must be used). The CRS is +represented by either GeoTIFF or Well Known Text (WKT) as indicated by the WKT +:ref:`Global Encoding ` bit. Point Record Formats 0-5 can +use either GeoTIFF or WKT, but not both simultaneously. Point Data Record +Formats 6-10 must use WKT. + +Georeferencing Information Using WKT +................................................................................ + +For definition of WKT, we refer to Open Geospatial Consortium (OGC) +specification "OpenGIS coordinate transformation service implementation +specification" revision 1.00 released 12 January 2001, section 7 (`"Coordinate +Transformation Service Spec" `_). +As there are a few dialects of WKT, please note that LAS is not using the "ESRI +WKT" dialect, which does not include TOWGS84 and Authority nodes. + +WKT georeferencing information can be specified in two optional variable length +records, the OGC math transform WKT record and the OGC coordinate system WKT +record, as follows. Note that the math transform WKT record is added for +completeness, and a coordinate system WKT *may* or *may not* require a math +transform WKT record (a parameterized math transform definition). + +OGC Math Transform WKT Record +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++-----------------+-----------------------------+ +| User ID | LASF_Projection | ++-----------------+-----------------------------+ +| Record ID | 2111 | ++-----------------+-----------------------------+ + +This record contains the textual data representing a Math Transform WKT as +defined in section 7 of the Coordinate Transformation Service Spec, with the +following notes: + +* The OGC Math Transform WKT VLR data shall be a null-terminated string. +* The OGC Math Transform WKT VLR data shall be considered UTF-8. +* The OGC Math Transform WKT VLR data shall be considered C locale-based, and + no localization of the numeric strings within the WKT should be performed. + +OGC Coordinate System WKT Record +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++-----------------+-----------------------------+ +| User ID | LASF_Projection | ++-----------------+-----------------------------+ +| Record ID | 2112 | ++-----------------+-----------------------------+ + +This record contains the textual data representing a Coordinate System WKT as +defined in section 7 of the Coordinate Transformation Service Spec, with the +following notes: + +* The OGC Coordinate System WKT VLR data shall be a null-terminated string. +* The OGC Coordinate System WKT VLR data shall be considered UTF-8. +* The OGC Coordinate System WKT VLR data shall be considered C locale-based, and + no localization of the numeric strings within the WKT should be performed. + +Georeferencing Information Using GeoTIFF +................................................................................ + +The GeoTIFF specification is defined by http://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 necessary when +using GeoTIFF records instead of WKT records. The ModelTiePointTag (33922), +ModelPixelScaleTag (33550), and ModelTransformationTag (34264) records can be +excluded. The GeoKeyDirectoryTag (34735), GeoDoubleParamsTag (34736), and +GeoAsciiParamsTag (34737) records are used. + +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, depending on the content of the GeoKeyDirectoryTag +record. + +GeoKeyDirectoryTag Record +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++-----------------+-----------------------------+ +| User ID | LASF_Projection | ++-----------------+-----------------------------+ +| Record ID | 34735 | ++-----------------+-----------------------------+ + +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 view for someone interested in +implementation. + +The GeoKeyDirectoryTag is defined as just an array of unsigned short values. +But, programmatically, the data can be seen as something like this: + +:: + + 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 + +.. tabularcolumns:: |p{4.5cm}|p{12.0cm}| + +.. table:: GeoKey Four Unsigned Shorts + + +---------------------------------+----------------------------------------------------------+ + | Name | Definition | + +=================================+==========================================================+ + | ``wKeyID`` | Defined key ID for each piece of GeoTIFF data. IDs | + | | contained in the GeoTIFF specification. | + +---------------------------------+----------------------------------------------------------+ + | ``wTIFFTagLocation`` | Indicates where the data for this key is located: | + | | | + | | * 0 means data is in the ``wValue_Offset`` field as an | + | | unsigned short. | + | | * 34736 means the data is located at index | + | | ``wValue_Offset`` of the GeoDoubleParamsTag record. | + | | * 34737 means the data is located at index | + | | ``wValue_Offset`` of the GeoAsciiParamsTag record. | + +---------------------------------+----------------------------------------------------------+ + | ``wCount`` | Number of characters in string for values of | + | | GeoAsciiParamsTag, otherwise is 1. | + +---------------------------------+----------------------------------------------------------+ + | ``wValue_Offset`` | Contents vary depending on value for wTIFFTagLocation | + | | above. | + +---------------------------------+----------------------------------------------------------+ + + + +GeoDoubleParamsTag Record (Optional) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++-----------------+-----------------------------+ +| User ID | LASF_Projection | ++-----------------+-----------------------------+ +| Record ID | 34736 | ++-----------------+-----------------------------+ + +This record is simply an array of doubles that contain values referenced by tag +sets in the GeoKeyDirectoryTag record. + +GeoAsciiParamsTag Record (Optional) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + ++-----------------+-----------------------------+ +| User ID | LASF_Projection | ++-----------------+-----------------------------+ +| Record ID | 34737 | ++-----------------+-----------------------------+ + +This record is simply an array of ASCII data. It contains many strings separated +by null terminator characters, which are referenced by position from data in the +GeoKeyDirectoryTag record. + + diff --git a/source/04_optional_vlrs.txt b/source/04_optional_vlrs.txt new file mode 100644 index 0000000..566a27d --- /dev/null +++ b/source/04_optional_vlrs.txt @@ -0,0 +1,305 @@ +.. raw:: latex + + \newpage + +Other Specification Defined VLRs (Optional) +-------------------------------------------------------------------------------- + +Classification Lookup +................................................................................ + ++----------------------------+-----------------------------------+ +| User ID | LASF_Spec | ++----------------------------+-----------------------------------+ +| Record ID | 0 | ++----------------------------+-----------------------------------+ +| Record Length after Header | 256 records * 16 bytes per struct | ++----------------------------+-----------------------------------+ + +:: + + struct CLASSIFICATION { + unsigned char ClassNumber; + char Description[15]; + }; //total of 16 bytes + + +Text Area Description +................................................................................ + ++-----------------+-----------------------------+ +| User ID | LASF_Spec | ++-----------------+-----------------------------+ +| Record ID | 3 | ++-----------------+-----------------------------+ + +This VLR/EVLR is used for providing a textual description of the content of the +LAS file. It is a null-terminated, free-form ASCII string. + +.. _extrabytes_vlr_label: + +Extra Bytes +................................................................................ + ++----------------------------+-----------------------------+ +| User ID | LASF_Spec | ++----------------------------+-----------------------------+ +| Record ID | 4 | ++----------------------------+-----------------------------+ +| Record Length after Header | n descriptors * 192 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 meaning of the extra +bytes will simply copy these bytes when manipulating files. + +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 are 4 "extra +bytes". The Extra Bytes VLR contains a simple description of the type and the +meaning of these "extra bytes" so they can be accessed in a consistent manner +across applications. The extra bytes descriptor is defined as follows: + +:: + + 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 in the payload of this VLR. In another example, +four EXTRA_BYTES structs in the VLR payload could describe 14 "extra bytes" in +each point record: + +#) "laser pulse direction [0]" - data_type = 9 (float) +#) "laser pulse direction [1]" - data_type = 9 (float) +#) "laser pulse direction [2]" - data_type = 9 (float) +#) "pulse width" - data_type = 3 (ushort) + +In this example, an array of three individual floats collectively specify a +"laser pulse direction" for that point, and one unsigned short integer specifies +a "pulse width" for that point. + +The "extra bytes" are made accessible via a unique name. The "name" field +distinguishes the additional point attributes that software may add to +the points in a LAS file so they can be accessed later 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" is discouraged. + +Multiple sequential "extra byte" records can compose an array of associated +values. It is recommended that each member's name be consistent with other +members, only varying by an index number wrapped in square brackets, as in +the above example. Zero-indexed arrays are encouraged. 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 R14 `_ to +simplify implementation. + +Any unused characters in the "name" or "description" fields must be set to zero. + +.. tabularcolumns:: |p{2.0cm}|p{5.0cm}|p{6.0cm}| + +.. table:: Values for ``data_type`` Field + + +------------+-------------------------------+-------------------+ + | Value | Meaning | Size on Disk | + +============+===============================+===================+ + | 0 | undocumented extra bytes | specify value in | + | | | ``options`` field | + +------------+-------------------------------+-------------------+ + | 1 | unsigned char | 1 byte | + +------------+-------------------------------+-------------------+ + | 2 | char | 1 byte | + +------------+-------------------------------+-------------------+ + | 3 | unsigned short | 2 bytes | + +------------+-------------------------------+-------------------+ + | 4 | short | 2 bytes | + +------------+-------------------------------+-------------------+ + | 5 | unsigned long | 4 bytes | + +------------+-------------------------------+-------------------+ + | 6 | long | 4 bytes | + +------------+-------------------------------+-------------------+ + | 7 | unsigned long long | 8 bytes | + +------------+-------------------------------+-------------------+ + | 8 | long long | 8 bytes | + +------------+-------------------------------+-------------------+ + | 9 | float | 4 bytes | + +------------+-------------------------------+-------------------+ + | 10 | double | 8 bytes | + +------------+-------------------------------+-------------------+ + | 11-30 | *Deprecated* | deprecated | + +------------+-------------------------------+-------------------+ + | 31-255 | *Reserved* | not assigned | + +------------+-------------------------------+-------------------+ + + +.. tabularcolumns:: |p{2.0cm}|p{4.0cm}|p{8.5cm}| + +.. table:: Encoding of ``options`` Bit Field + + +-----------+------------------+-------------------------------------------+ + | Bits | Field Name | Description | + +===========+==================+===========================================+ + | 0 | no_data_bit | If set the ``no_data`` value is relevant | + +-----------+------------------+-------------------------------------------+ + | 1 | min_bit | If set the ``min`` value is relevant | + +-----------+------------------+-------------------------------------------+ + | 2 | max_bit | If set the ``max`` value is relevant | + +-----------+------------------+-------------------------------------------+ + | 3 | scale_bit | If set each value should be multiplied | + | | | by the corresponding scale value (before | + | | | applying the offset). | + +-----------+------------------+-------------------------------------------+ + | 4 | offset_bit | If set each value should be translated | + | | | by the corresponding offset value (after | + | | | applying the scaling). | + +-----------+------------------+-------------------------------------------+ + + +The bit mask in the "options" field specifies whether the min and max range of +the value has been set (i.e., is meaningful), whether the scale and/or offset +values are set with which the "extra bytes" 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" fields must be set to zero. + +If the selected data_type is less than 8 bytes, the no_data, min, and max fields +should be upcast into 8-byte storage. For any float these 8 bytes would be +upcast to a double, for any unsigned char, unsigned short, or unsigned long +they would be upcast to an unsigned long long and for any char, short, or long, +they would be upcast to a long long. + +If used, the min and max fields reflect the actual minimum and maximum values +of the attribute in the LAS file, in its raw form, without any scale +or offset values applied. + +The "reserved" field, the "unused" field, and the "deprecated" fields must be +set to zero and may be used in a future revision. + +A LAS file contains "undocumented extra bytes" when there are "extra bytes" +but when there is no Extra Bytes VLR that describes them or when there are +more "extra bytes" than described in an existing Extra Bytes VLR. + +When adding an "Extra Bytes" VLR to a LAS file that contains "undocumented +extra bytes" they must be designated as data_type == 0 with the options bit +field storing the number of undocumented 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 Bytes VLR invalid. + +.. _superseded_vlr_label: + +Superseded +................................................................................ + ++-----------------+-----------------------------+ +| User ID | LASF_Spec | ++-----------------+-----------------------------+ +| Record ID | 7 | ++-----------------+-----------------------------+ + +This LASF Record ID is used to negate an existing VLR/EVLR when rewriting the +file (to remove 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 has been superseded must be +marked with the SUPERSEDED Record ID. + +.. _fwf_descriptor_label: + +Waveform Packet Descriptor +................................................................................ + ++-----------------+-----------------------------+ +| User ID | LASF_Spec | ++-----------------+-----------------------------+ +| Record ID | n: where n > 99 and n < 355 | ++-----------------+-----------------------------+ + +.. warning:: + + This VLR is REQUIRED when using Point Data Record Formats 4, 5, 9, or 10. + +These records contain information that describes the configuration of the +waveform packets. Since systems may be configured differently at different +times throughout a job, the LAS file supports 255 Waveform Packet Descriptors. + + +.. tabularcolumns:: |p{6.5cm}|p{4.0cm}|p{2.0cm}|p{1.5cm}| + +.. table:: Waveform Packet Descriptor User Defined Record + + +------------------------------+-------------------------+-----------+--------------+ + | Item | Format | Size | Required | + +==============================+=========================+===========+==============+ + | Bits per Sample | unsigned char | 1 byte | yes | + +------------------------------+-------------------------+-----------+--------------+ + | Waveform Compression Type | unsigned char | 1 byte | yes | + +------------------------------+-------------------------+-----------+--------------+ + | Number of Samples | unsigned long | 4 bytes | yes | + +------------------------------+-------------------------+-----------+--------------+ + | Temporal Sample Spacing | unsigned long | 4 bytes | yes | + +------------------------------+-------------------------+-----------+--------------+ + | Digitizer Gain | double | 8 bytes | yes | + +------------------------------+-------------------------+-----------+--------------+ + | Digitizer Offset | double | 8 bytes | yes | + +------------------------------+-------------------------+-----------+--------------+ + +**Bits per Sample** + +2 through 32 bits are supported. + +**Waveform Compression Type** + +It is expected that in the future standard compression types will be adopted by +the LAS committee. This field will indicate the compression algorithm used for +the waveform packets associated with this descriptor. A value of 0 indicates no +compression. Zero is the only value currently supported. + +**Number of Samples** + +The number of samples associated with this waveform packet type. This value +always represents the fully decompressed waveform packet. + +**Temporal Sample Spacing** + +The temporal sample spacing in picoseconds. Example values might be 500, 1000, +2000, and so on, representing digitizer frequencies of 2 GHz, 1 GHz, and 500 MHz +respectively. + +**Digitizer Gain and Offset** + +The digitizer gain and offset are used to convert the raw digitized value to an +absolute digitizer voltage using the formula: + +.. math:: + + VOLTS = OFFSET + GAIN * Raw\_Waveform\_Amplitude + +.. note:: + + Users seeking further clarity regarding LAS waveform encoding are encouraged + to learn more on the official LAS wiki: https://github.com/ASPRSorg/LAS/wiki + + diff --git a/source/05_defined_evlrs.txt b/source/05_defined_evlrs.txt new file mode 100644 index 0000000..cb964c2 --- /dev/null +++ b/source/05_defined_evlrs.txt @@ -0,0 +1,29 @@ +.. raw:: latex + + \newpage + +Defined Extended Variable Length Records (EVLRs) +-------------------------------------------------------------------------------- + +.. _fwf_packets_label: + +Waveform Data Packets +............................................................................... + +.. warning:: + + This EVLR is REQUIRED internally or externally when using Point Data Record + Formats 4, 5, 9, or 10. + ++-----------------+-----------------------------+ +| User ID | LASF_Spec | ++-----------------+-----------------------------+ +| Record ID | 65535 | ++-----------------+-----------------------------+ + +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 of each waveform packet must be padded +such that the next waveform record will start on an even byte boundary. + + diff --git a/source/15_profiles.txt b/source/06_profiles.txt similarity index 89% rename from source/15_profiles.txt rename to source/06_profiles.txt index 1a4e473..128faae 100644 --- a/source/15_profiles.txt +++ b/source/06_profiles.txt @@ -7,11 +7,11 @@ 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 lidar community (e.g., the +needs of a particular subset of the broad point cloud community (e.g., the coastal/bathymetric lidar community, or the powerline mapping community). So as to not alter the LAS base specification, new classes can only be added to Point Data Record Formats 6-10, and classification values cannot start below 39. New -attributes must be incorporated using Extra Bytes VLRs. It is strongly +attributes must be incorporated using :ref:`extrabytes_vlr_label` VLRs. It is strongly recommended that the development of Domain Profiles be coordinated, so as to avoid unnecessary overlap or conflicts (e.g., conflicting class numbers) between profiles. diff --git a/source/12_defined_vlrs.txt b/source/12_defined_vlrs.txt deleted file mode 100644 index c5e7d55..0000000 --- a/source/12_defined_vlrs.txt +++ /dev/null @@ -1,360 +0,0 @@ -.. raw:: latex - - \newpage - -Defined Variable Length Records --------------------------------------------------------------------------------- - -LAS 1.4 defines Variable Length Records (VLR) and Extended Variable Length -Records (EVLR). 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 a VLR can elect to use an -EVLR, even for predefined VLRs such as Coordinate Reference System (CRS) -information. This ability is useful, for example, when a user wishes to update -information normally contained within a VLR without the need of rewriting the -point data. - -A new LASF_Spec "Superseded" (value 7) has been defined to allow a writer to -indicate that 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 is no longer in use. - -Coordinate Reference System Information -................................................................................ - -The Coordinate Reference System (CRS) information for the point data is -required for all data. The CRS information will be placed in Variable Length -Records or Extended Variable Length Records (note that if the writer wishes to -maintain legacy compatibility, then GeoTIFF in VLRs must be used). The CRS is -represented by either GeoTIFF or Well Know Text as indicated by the WKT Global -Encoding bit. Point Record Formats 0-5 can use either GeoTIFF or WKT (but not -both simultaneously). Point Record Formats 6-10 must use WKT. - -Georeferencing Information using WKT -................................................................................ - -For definition of WKT, we refer to Open Geospatial Consortium (OGC) -specification "OpenGIS coordinate transformation service implementation -specification" revision 1.00 released 12 January 2001, section 7 (coordinate -transformation services spec). This specification may be found at -www.opengeospatial.org/standards/ct. As there are a few dialects of WKT, please -note that LAS is not using the "ESRI WKT" dialect, which does not include -TOWGS84 and authority nodes. - -WKT georeferencing information can be specified in two optional variable length -records, the OGC math transform WKT record and the OGC coordinate system WKT -record, as follows. Note that the math transform WKT record is added for -completeness, and a coordinate system WKT *may* or *may not* require a math -transform WKT record (a parameterized math transform definition). - -OGC Math Transform WKT Record -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Projection | -+-----------------+-----------------------------+ -| Record ID | 2111 | -+-----------------+-----------------------------+ - -This record contains the textual data representing a Math Transform WKT as -defined in section 7 of the Coordinate Transformation Services Spec, with the -following notes: - -* The OGC Math Transform WKT VLR data shall be a null-terminated string. -* The OGC Math Transform WKT VLR data shall be considered UTF-8. -* The OGC Math Transform WKT VLR data shall be considered C locale-based, and - no localization of the numeric strings within the WKT should be performed. - -OGC Coordinate System WKT -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Projection | -+-----------------+-----------------------------+ -| Record ID | 2112 | -+-----------------+-----------------------------+ - -This record contains the textual data representing a Coordinate System WKT as -defined in section 7 of the Coordinate Transformation Services Spec, with the -following notes: - -* The OGC Coordinate System WKT VLR data shall be a null-terminated string. -* The OGC Coordinate System WKT VLR data shall be considered UTF-8. -* The OGC Coordinate System WKT VLR data shall be considered C locale-based, and - no localization of the numeric strings within the WKT should be performed. - -Georeferencing Information using GeoTIFF -................................................................................ - -The GeoTIFF specification is defined by http://www.remotesensing.org/geotiff/geotiff.html. - -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 necessary when -using GeoTIFF records instead of WKT records. The ModelTiePointTag (33922), -ModelPixelScaleTag (33550), and ModelTransformationTag (34264) records can be -excluded. The GeoKeyDirectoryTag (34735), GeoDoubleParamsTag (34736), and -GeoASCIIParamsTag (34737) records are used. - -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, depending on the content of the GeoKeyDirectoryTag -record. - -GeoKeyDirectoryTag Record -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Projection | -+-----------------+-----------------------------+ -| Record ID | 34735 | -+-----------------+-----------------------------+ - -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 view for someone interested in -implementation. - -The GeoKeyDirectoryTag is defined as just an array of unsigned short values. -But, programmatically, the data can be seen as something like this: - -:: - - 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 - -.. tabularcolumns:: |p{4.5cm}|p{12.0cm}| - -.. table:: GeoKey Four Unsigned Shorts - - +---------------------------------+----------------------------------------------------------+ - | Name | Definition | - +=================================+==========================================================+ - | ``wKeyID`` | Defined key ID for each piece of GeoTIFF data. IDs | - | | contained in the GeoTIFF specification. | - +---------------------------------+----------------------------------------------------------+ - | ``wTIFFTagLocation`` | Indicates where the data for this key is located: | - | | | - | | * 0 means data is in the ``wValue_Offset`` field as an | - | | unsigned short. | - | | * 34736 means the data is located at index | - | | ``wValue_Offset`` of the GeoDoubleParamsTag record. | - | | * 34737 means the data is located at index | - | | ``wValue_Offset`` of the GeoAsciiParamsTag record. | - +---------------------------------+----------------------------------------------------------+ - | ``wCount`` | Number of characters in string for values of | - | | GeoAsciiParamsTag, otherwise is 1 | - +---------------------------------+----------------------------------------------------------+ - | ``wValue_Offset`` | Contents vary depending on value for wTIFFTagLocation | - | | above | - +---------------------------------+----------------------------------------------------------+ - - - -GeoDoubleParamsTag Record (optional) -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Projection | -+-----------------+-----------------------------+ -| Record ID | 34736 | -+-----------------+-----------------------------+ - -This record is simply an array of doubles that contain values referenced by tag -sets in the GeoKeyDirectoryTag record. - -GeoAsciiParamsTag Record (optional) -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Projection | -+-----------------+-----------------------------+ -| Record ID | 34737 | -+-----------------+-----------------------------+ - -This record is simply an array of ASCII data. It contains many strings separated -by null terminator characters which are referenced by position from data in the -GeoKeyDirectoryTag record. - -Other Specification Defined VLRs --------------------------------------------------------------------------------- - -Classification Lookup (optional) -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Spec | -+-----------------+-----------------------------+ -| Record ID | 0 | -+-----------------+-----------------------------+ - -Record Length after Header: 256 recs * 16 byte struct len - -:: - - struct CLASSIFICATION { - unsigned char ClassNumber; - char Description[15]; - }; - - -Text Area Description (optional) -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Spec | -+-----------------+-----------------------------+ -| Record ID | 3 | -+-----------------+-----------------------------+ - -This VLR/EVLR is used for providing a textual description of the content of the -LAS file. It is a null terminated, free-form ASCII string. - -.. include:: ./13.3_extra_bytes.txt - -Superseded (optional) -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Spec | -+-----------------+-----------------------------+ -| Record ID | 7 | -+-----------------+-----------------------------+ - -This LASF Record ID is used to negate an existing VLR/EVLR when rewriting the -file (to remove 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 has been superseded must be -marked with the SUPERSEDED Record ID. - -Waveform Packet Descriptor -................................................................................ - -+-----------------+-----------------------------+ -| User ID | LASF_Spec | -+-----------------+-----------------------------+ -| Record ID | n: where n > 99 and n <355 | -+-----------------+-----------------------------+ - -.. warning:: - - This VLR is REQUIRED internally or externally when using Point Data Record - Formats 4, 5, 9 or 10. - -These records contain information that describes the configuration of the -waveform packets. Since systems may be configured differently at different -times throughout a job, the LAS file supports 255 Waveform Packet Descriptors. - - -.. tabularcolumns:: |p{6.5cm}|p{4.0cm}|p{2.0cm}|p{1.5cm}| - -.. table:: Waveform Packet Descriptor User Defined Record - - +------------------------------+-------------------------+-----------+--------------+ - | Item | Format | Size | Required | - +==============================+=========================+===========+==============+ - | Bits per sample | unsigned char | 1 byte | yes | - +------------------------------+-------------------------+-----------+--------------+ - | Waveform Compression Type | unsigned char | 1 byte | yes | - +------------------------------+-------------------------+-----------+--------------+ - | Number of samples | unsigned long | 4 bytes | yes | - +------------------------------+-------------------------+-----------+--------------+ - | Temporal Sample Spacing | unsigned long | 4 bytes | yes | - +------------------------------+-------------------------+-----------+--------------+ - | Digitizer Gain | double | 8 bytes | yes | - +------------------------------+-------------------------+-----------+--------------+ - | Digitizer Offset | double | 8 bytes | yes | - +------------------------------+-------------------------+-----------+--------------+ - -Bits per sample -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -2 through 32 bits are supported. - -Waveform Compression type -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -It is expected that in the future standard compression types will be adopted by -the LAS committee. This field will indicate the compression algorithm used for -the waveform packets associated with this descriptor. A value of 0 indicates no -compression. Zero is the only value currently supported. - -Number of Samples -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The number of samples associated with this waveform packet type. This value -always represents the fully decompressed waveform packet. - -Temporal Sample Spacing -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The temporal sample spacing in picoseconds. Example values might be 500, 1000, -2000 and so on, representing digitizer frequencies of 2 GHz, 1 GHz and 500 MHz -respectively. - -Digitizer Gain -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The gain and offset are used to convert the raw digitized value to an absolute -digitizer voltage using the formula: - -.. math:: - - VOLTS = OFFSET + GAIN * Raw\_Waveform\_Amplitude - -Digitizer Offset -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -The gain and voltage offset are used to convert the raw digitized value to a -voltage using the formula: - -.. math:: - - VOLTS = OFFSET + GAIN * Raw\_Waveform\_Amplitude - - - -Defined Extended Variable Length Records (EVLRs) --------------------------------------------------------------------------------- - -Waveform Data Packets -............................................................................... - -.. warning:: - - This EVLR is REQUIRED internally or externally when using Point Data Record - Formats 4, 5, 9, or 10. - -+-----------------+-----------------------------+ -| User ID | LASF_Spec | -+-----------------+-----------------------------+ -| Record ID | 65535 | -+-----------------+-----------------------------+ - -The packet of Raw Waveform Amplitude values for all records immediately follow -this variable length header. Note that when using a bit resolution that is not -an even increment of 8, the last byte of each waveform packet must be padded -such that the next waveform record will start on an even byte boundary. - diff --git a/source/13.3_extra_bytes.txt b/source/13.3_extra_bytes.txt deleted file mode 100644 index 7ff34fc..0000000 --- a/source/13.3_extra_bytes.txt +++ /dev/null @@ -1,168 +0,0 @@ -Extra Bytes (optional) -................................................................................ - -+---------------------+-----------------------------+ -| User ID | LASF_Spec | -+---------------------+-----------------------------+ -| Record ID | 4 | -+---------------------+-----------------------------+ -| Record Length after | n records * 192 bytes | -| Header | | -+---------------------+-----------------------------+ - -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 meaning of the extra -bytes will simply copy these bytes when manipulating files. - -This record is only needed 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, when a LAS file that contains -point type 1 has a point record size of 32 instead of 28 there are 4 "extra -bytes". The Extra Bytes VLR contains a simple description of the type and the -meaning of these "extra bytes" so they can be accessed in a consistent manner -across applications. The 4 "extra bytes" could, for example, be of data_type 9 -- a floating point value - that specifies an "echo width" for each return. In -this case there would be one EXTRA_BYTES struct in the payload of this VLR. An -example with two EXTRA_BYTES struct in the payload are 14 "extra bytes" that -have data type 29 - a floating point vector of length 3 - followed by data type -3 - an unsigned short - that specify the "laser pulse direction" and a -"normalized reflectivity". - -The "extra bytes" are made accessible via a unique name. The "name" field -distinguishes the additional point attributes that a LIDAR software may add to -the points in a LAS file so they can be accessed later 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" is discouraged. - -The bit mask in the options field specifies whether the min and max range of -the value have been set (i.e. are meaningful), whether the scale and/or offset -values are set with which the "extra bytes" 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. - -If the selected data_type is less than 8 bytes, the no_data, min, and max field -should be upcast into 8-byte storage. For any float these 8 bytes would be -upcast to a double, for any unsigned char, unsigned short, or unsigned long -they would be upcast to an unsigned long long and for any char, short, or long, -they would be upcast to a long long. - -:: - - 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[3]; // 24 = 3*8 bytes - anytype min[3]; // 24 = 3*8 bytes - anytype max[3]; // 24 = 3*8 bytes - double scale[3]; // 24 = 3*8 bytes - double offset[3]; // 24 = 3*8 bytes - char description[32]; // 32 bytes - }; // total of 192 bytes - -The "reserved" field and the "unused" field must be set to zero. Any unused -"no_data", "min", "max", "scale", or "offset" fields must be set to zero. Any -unused characters in the "name" or "description" fields must be set to zero. - - -.. tabularcolumns:: |p{3.0cm}|p{5.0cm}|p{5.0cm}| - -.. table:: Values for ``data_type`` Field - - +-------------------------------+-------------------------------+-------------------+ - | Value | Meaning | Value | - +===============================+===============================+===================+ - | 0 | undocumented extra bytes | specify value in | - | | | ``options`` field | - +-------------------------------+-------------------------------+-------------------+ - | 1 | unsigned char | 1 byte | - +-------------------------------+-------------------------------+-------------------+ - | 2 | char | 1 byte | - +-------------------------------+-------------------------------+-------------------+ - | 3 | unsigned short | 2 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 4 | short | 2 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 5 | unsigned long | 4 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 6 | long | 4 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 7 | unsigned long long | 8 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 8 | long long | 8 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 9 | float | 4 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 10 | double | 8 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 11 | unsigned char[2] | 2 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 12 | char[2] | 2 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 13 | unsigned short[2] | 4 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 14 | short[2] | 4 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 15 | unsigned long[2] | 8 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 16 | long[2] | 8 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 17 | unsigned long long[2] | 16 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 18 | long long[2] | 16 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 19 | float[2] | 8 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 20 | double[2] | 16 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 21 | unsigned char[3] | 3 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 22 | char[3] | 3 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 23 | unsigned short[3] | 6 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 24 | short[3] | 6 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 25 | unsigned long[3] | 12 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 26 | long[3] | 12 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 27 | unsigned long long[3] | 24 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 28 | long long[3] | 24 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 29 | float[3] | 12 bytes | - +-------------------------------+-------------------------------+-------------------+ - | 30 | double[3] | 24 bytes | - +-------------------------------+-------------------------------+-------------------+ - - -.. tabularcolumns:: |p{2.0cm}|p{6.0cm}|p{8.5cm}| - -.. table:: Encoding of ``options`` Bit Field - - +-----------+-------------------------+------------------------------------------+ - | Bits | Field Name | Description | - +===========+=========================+==========================================+ - | 0 | no_data_bit | If set the no_data value is relevant. | - +-----------+-------------------------+------------------------------------------+ - | 1 | min_bit | If set the min value is relevant | - +-----------+-------------------------+------------------------------------------+ - | 2 | max_bit | If set the max value is relevant | - +-----------+-------------------------+------------------------------------------+ - | 3 | scale_bit | If set each value should be multiplied | - | | | by the corresponding scale value (before | - | | | applying the offset) | - +-----------+-------------------------+------------------------------------------+ - | 4 | offset_bit | If set each value should be translated | - | | | by the corresponding offset value (after | - | | | applying the scaling). | - +-----------+-------------------------+------------------------------------------+ - - diff --git a/source/conf.py b/source/conf.py index 0f6a180..c73ad3e 100644 --- a/source/conf.py +++ b/source/conf.py @@ -56,7 +56,7 @@ # The short X.Y version. #version = u'1.4' # Custom non-keyword version tag for header -myversion = u'1.4 - R14' +myversion = u'1.4 - R14 DRAFT' # The full version, including alpha/beta/rc tags. release = u'VERSION ' + myversion releasename = release @@ -205,7 +205,7 @@ def get_git_revision_short_hash(): 425 Barlow Place, Suite 210\\ Bethesda, Maryland 20814-2160\\ Voice: 301-493-0290\\ -Fax: 301-493-0208\\ +Fax: 225-408-4422\\ Web: \underline{www.asprs.org}\\ diff --git a/wiki/LAS_FWF_illustration_constant.png b/wiki/LAS_FWF_illustration_constant.png new file mode 100644 index 0000000..951cf1c Binary files /dev/null and b/wiki/LAS_FWF_illustration_constant.png differ diff --git a/wiki/LAS_FWF_illustration_refracted.png b/wiki/LAS_FWF_illustration_refracted.png new file mode 100644 index 0000000..65757de Binary files /dev/null and b/wiki/LAS_FWF_illustration_refracted.png differ