-
Notifications
You must be signed in to change notification settings - Fork 18
Standard ExtraByte Definitions
Table of Contents:
A point has "extra bytes" when the Point Data Record Length in the LAS header is set to a larger value than the minimum required by the Point Data Record Format. LAS 1.4 introduced a new VLR that describes these "extra bytes" with one descriptor per attribute.
Adding Standard ExtraBytes to this registry makes it easier to create and understand these optional point attributes across different software packages and applications.
By including this registry in the wiki and not in the specification itself, we (the LAS Working Group) hope to keep this registry flexible and make it easier to add additional attributes.
The existence of this registry does not in any way preclude users from using and defining their own ExtraBytes. We do, however, ask that if you name an ExtraByte with the same name as one of the standard ExtraBytes, the original and agreed-upon meaning is preserved.
During an extended meeting in the summer of 2021, the LWG established the following guidelines for standardizing an ExtraByte:
- The meaning of the ExtraByte field must be consistent across all usages.
- The formal (encoded) name of the ExtraByte field must be consistent, and lowercase names are universally preferred.
- An identifier field will be added to the ExtraBytes VLR in a future revision.
- The units and data type for an ExtraByte will be considered standard. Deviations are allowed but will be considered non-standard. (see below)
- Description, scale, offset, and NODATA values will be recommended but not required.
Draft ExtraByte definitions that meet these guidelines can be promoted by the LWG to full Standard ExtraBytes.
The data types provided for the published standard ExtraBytes were carefully selected to minimize storage requirements while also considering the potential valid range of values. In many cases the range can be adapted by modifying the offset and scale to suit your application. If using offset and scale is insufficient to achieve the desired range, a larger data type may be used. This is considered nonstandard, but the standard formal name may be used.
It is also worth reiterating that in nearly every case an integer with valid scale and offset values will be more suitable than using single- or double-precision float. Integers enable exact comparisons of raw values (such as for NODATA checks) and require less storage space on disk.
These ExtraByte definitions have been accepted by the LWG and are considered final. These ExtraBytes should be used in the manner intended if present in a LAS file.
Don't see one that fits your use case? Scroll down to the Drafts section to see if one has been started, or propose a new addition on the GitHub issues page.
Published standard ExtraBytes are defined in the table below. Detailed descriptions are provided in the subsections following.
| Common Name | ID | Formal Name (required) | Size | data_type | Options Bit Field | Description |
|---|---|---|---|---|---|---|
| Echo Width | 200 | echo width |
2 | 3 (ushort) | All | Full width at half maximum [ns] |
| Height Above Ground | 201 | height above ground |
2 | 4 (short) | All | Vertical point to TIN distance |
| Beam ID | 1 | beam id |
1 | 1 (uchar) | NODATA, min, max | Extended channel ID |
- Click field names to scroll down to extended field descriptions, including standard units, valid ranges and example scale, offset, and NODATA values. As a general guideline, the maximum possible value is a good default NODATA value, except in the cases when zero has the same meaning as null and is therefore preferable.
- Standard ExtraByte IDs have not yet been implemented and are reserved for future use.
- The standard formal name must be encoded exactly as defined (in lowercase). Unused space must be zero-filled.
- Standard size and data type are provided. Deviations are permitted but considered non-standard.
- Recommended use of the ExtraBytes descriptor VLR
optionsbit field is provided. When applicable, minimum and maximum values encoded in the ExtraBytes descriptor VLR should reflect the true minimum and maximum values of the field within the LAS file, after the scale and offset values are applied. - The provided description is a suggested default but may vary. Unused space must be zero-filled.
The echo width is defined as full width at half maximum of the received echo signal and is measured in nanoseconds (ns). The echo width can be regarded as a quality indicator of received echo signals. The width of a received echo signal depends on the geometry of the hit target.
- Valid range: 0.1 to 1000.0.
- Preferred units: Nanoseconds [ns]
- Recommended NODATA: 0 raw, 0.0 scaled
- Recommended scale: 0.1
- Recommended offset: 0.0
- Alternative name:
pulse width
Stores the point’s height above a ground surface. Units will often be whatever vertical units are relevant to the LAS file, but meters are recommended for uniformity between implementations. Points below the ground surface will have negative values. This attribute can also be used for surfaces other than ground, such as a water or canopy surface.
There is a variant of this using 4-byte integers (signed long), but the standard version is 2 bytes.
- Valid range: -327.68 to 327.67
- Preferred units: Meters [m]
- Recommended NODATA: 32768 raw, 327.68 scaled
- Recommended scale: 0.01
- Recommended offset: 0.00
- Alternative name:
height above surface
Conceptually identical to the Channel field in PDRF 6-10, but with a larger valid range. This field provides a method to uniquely identify the source pulse, beam, or pixel of the point.
- Valid range: 0 to 254
- Preferred units: n/a
- Recommended NODATA: 255 (max)
- Recommended scale: n/a
- Recommended offset: n/a
- Alternative name:
extended channel
These definitions are currently draft and not yet finalized. Use them with caution, as they'll be subject to change. Want one finalized? Come to our next LWG meeting or post an issue on GitHub!
Draft standard ExtraBytes are defined in the table below. Detailed descriptions are provided in the subsections following.
| Common Name | ID | Formal Name (required) | Size | data_type | Options Bit Field | Description |
|---|---|---|---|---|---|---|
| Group/Object ID | 202 | groupid |
8 | 8 (ulonglong) | NODATA | 64-bit group identifier |
| Horizontal Uncertainty | 112 | sigma xy |
1 | 1 (uchar) | All | Horiz. coordinate uncertainty |
| Vertical Uncertainty | 113 | sigma z |
1 | 1 (uchar) | All | Vert. coordinate uncertainty |
| Bathymetric Flags | 104 | bathymetric flags |
1 | 1 (uchar) | None | Bathymetric bit flags |
| Refracted Range | 114 | refracted range |
2 | 3 (ushort) | All | Submerged vector length post-ref |
| Reflectance | 100 | reflectance |
2 | 4 (short) | All | Radiometric calibration output |
| Water Column Optical Depth | 102 | water column optical depth |
1 | 1 (uchar) | All | Water column optical depth |
Provides an identifier for grouping points together as an object or group, such as an index value to a shapefile polygon, lookup identifier for an attribute table stored externally, or feature identifier for fine-grained segmentation.
- Valid range: 1 to max?
- Preferred units: n/a
- Recommended NODATA: 0??
- Recommended scale: n/a
- Recommended offset: n/a
Provides an alternative means to convey the total propagated uncertainty of a point’s coordinates, replacing the now-deprecated “XYZ Coordinate Uncertainty” previously included with the Topobathy LDP. Informally this could also be referred to as the accuracy or precision of the point coordinates.
The XY dimensions have been combined to make the horizontal uncertainty independent from the projection.
- Valid range: 0.00 to 2.54
- Preferred units: Meters [m]
- Recommended NODATA: 255 raw, 2.55 scaled
- Recommended scale: 0.01
- Recommended offset: 0.00
The bathymetry bit flags are intended as a means of indicating other topobathymetric point or processing attributes that have not yet been identified and/or do not merit a separate point class or separate Extra Bytes VLR.
Bit 0 is used to flag whether or not a refraction correction has been applied.
Currently, the other 7 bits are reserved for future use.
This attribute is defined in the Topobathy LDP.
- Valid range: 0 to 1
- Preferred units: n/a (bit field)
- Recommended NODATA: n/a
- Recommended scale: n/a
- Recommended offset: n/a
The submerged distance along the slanted range vector from the origin to the measured point, defined as the post-refraction distance from the point of intersection with the water surface to the measured point itself. Useful for depth-based intensity corrections based on attenuation.
Also known as refracted vector length.
- Valid range: 0.01 to 655.35
- Preferred units: Meters [m]
- Recommended NODATA: 0 raw, 0.00 scaled
- Recommended scale: 0.01
- Recommended offset: 0.00
- Alternative names:
refracted vector length,refracted depth
The Reflectance field stores a value that is computed from the raw waveform or the recorded “intensity” value through some type of radiometric calibration procedure. While the types of corrections that may be applied as part of this process vary, the general goal is to produce an output that is more physically-meaningful (i.e., more closely related to actual surface characteristics) than the unitless, system-specific “intensity” values. If a rigorous radiometric calibration has not been performed, the calculated value may be termed “pseudo-reflectance” or “relative reflectance,” depending on the corrections applied. When a rigorous radiometric calibration is performed, this value may represent “true” surface/seafloor reflectance (i.e., the fraction of incident optical power that is reflected by the surface/seafloor) at the laser wavelength.
- Valid range: ?
- Preferred units: Decibels [dB]
- Recommended NODATA: 65535 raw, 655.35 scaled
- Recommended scale: 0.01
- Recommended offset: 0.00
- Alternative names:
(pseudo-)reflectance
Water Column Optical Depth is the dimensionless product of depth and attenuation coefficient (Kd). It is an extremely important parameter in bathymetric lidar processing and analysis, as laser pulse energy decreases exponentially with optical depth.
Because increments of .25 are deemed sufficient for this attribute the use of an unsigned char (data type 1) and a scaling factor of 0.25 are recommended.
- Valid range: 0.00 to 60.00?
- Preferred units: Unitless
- Recommended NODATA: 255 raw, 63.75 scaled
- Recommended scale: 0.25
- Recommended offset: 0.00
Need to know more? Want a wiki page on another topic? Found an error? Submit an issue or contact the LAS Working Group at [email protected].