2021 was not the post-pandemic year we all hoped it would be. As covid fatigue settled in, committee participation and other non-essential work diminished to a trickle for lack of energy. I’m no exception—my own contributions to this magazine have been far less numerous than intended and my naïve predictions for LAS 1.4 R16 publication in 2021 fell short as activity stalled for most of the year. With conferences canceled or struggling to survive as virtual events, volunteer participation in organizations like ASPRS has been down all year long while we all continue to white-knuckle our way through a global pandemic.
Nevertheless, despite kids screaming in the background, cats lounging on keyboards, sourdough needing constant attention and omicron rearing its ugly head, the ASPRS LAS Working Group (LWG) has convened three times since our last written update in mid-May1. Here’s a look at some of the topics covered in the May, July and November 2021 meetings and currently in work.
Topobathymetric Lidar Domain Profile v2
The topobathymetric lidar community has evolved considerably since the first release of the topobathymetric lidar domain profile (LDP) in 20132. The community has rallied around the LDP, with some adaptations that can and should be standardized in an update3. Items being addressed include:
- Adjustment of topobathymetric classifications, such as clarification for water surface (41) and submerged noise (45) classes, removal of IHO object class (44) and addition of a submerged vegetation class (46)
- Overhaul of topobathymetric ExtraBytes
- Migration to the LAS wiki
- Release of Version 2 of the topobathymetric LDP
Since the topobathymetric LDP is the only LDP currently in publication, its iteration sets the precedent for handling LDPs under the GitHub management paradigm. In November 2021, the LWG agreed that the wiki would be an appropriate place to store the LDPs, if a versioned static PDF copy of each LDP could be made available for referencing in tender documents.
Several other domains could potentially benefit from standardization around LDPs, such as transportation, electrical utilities, or oil and gas, and we invite contributions from experts in each domain.
First Standard ExtraBytes published
Following its success publishing the Standard System Identifier registry, the LWG is in the process of publishing its first standard ExtraBytes definitions4. The wiki states:
“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 VLR5 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.”4
During an extended meeting in summer 2021, the LWG established the following guidelines for standardizing an ExtraByte:
- The meaning and formal name of the ExtraByte field must be consistent across all usages, and lowercase names are 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
- Description, scale, offset and NODATA values will be recommended but not required
As of this writing, three ExtraByte definitions have been identified as having passed review:
- Beam ID—an extension of the existing Channel field in point formats 6-10 to support more than 4 possible values
- Echo Width—an approximation of the curve width of the returning echo’s waveform that is calculated during the full-waveform digitization (Figure 1)
- Height Above Ground—height of the point compared to a reference surface such as the ground, canopy or water
Other definitions will follow, especially as LDPs continue to develop.Readers are invited to propose their own Standard ExtraByte definitions by filing a new Issue on the LWG GitHub page6.
Wiki updates
In addition to the release of the Standard ExtraBytes registry, the LAS wiki7 received several other updates in 2021.
In fall 2021 the LWG began a registry of user-contributed VLR definitions8 to the LAS wiki. This fresh, exciting page provides a location for open-source projects, governments and even private companies to voluntarily contribute VLR definitions that are associated with their publicly registered VLR keys9.
Although VLR publication is entirely optional, doing so in a central location enables users to derive even greater value from community-created VLRs and the LAS files in which they live. BayesMap Solutions began the process with the first contribution, then others committed to follow. If readers would like to make a contribution, I would be happy to assist if interacting with GitHub’s wiki format is not comfortable.
Other additions to the wiki include:
- Clarification of the complex LittleEndian and BigEndian nature of the LAS header’s ProjectID and addition of example files (Issue #11110)
- Addition of the “How to View Edits” page11 to assist maintainers wanting to review their edits in the resultant PDF
- Explanation of storage size encoding for full-waveform data12
Preparing for LAS 1.5
Work has begun on LAS 1.5, the next version of the LAS specification13. Although the LWG is reluctant to iterate LAS after the sluggish and disruptive adoption of LAS 1.4, two important and pressing problems can only be mitigated by the release of a new version.
Address loss of GPS time precision
Adjusted Standard GPS Time as defined in LAS 1.2 through LAS 1.4 has been losing precision since 2011. In fact, it has been unable to designate timestamps with 0.1-microsecond precision (~8 MHz) since 2015, and it will be unable to differentiate past 0.2-microsecond precision (~4 MHz) in 2028 (Figure 2). Given that 2-MHz sensors are already on the market, it won’t be long before it is technically impossible to differentiate between pulses using Adjusted Standard GPS Time.
The proposed Offset Standard GPS Time in LAS 1.514 will provide the needed flexibility to provide 0.1-microsecond precision or better for any 8-year period, with minimal coding needed to add support. A table of recommended standard offset values will be provided by the LWG on the LAS wiki to promote standardization.
Adjusted Standard GPS Time will continue to exist in LAS 1.5 using the existing global encoding bit, but this new option will likely require the addition of a new global encoding bit to protect backwards compatibility. Fortunately, the real strength of this proposal is that it will not require the addition of yet another set of point record formats, because it utilizes the existing double-precision float in all modern point formats.
Temporal datum encoding
NOAA NGS is currently working on new datums that are inherently temporal, tied to specific moments in time15. Coordinate systems in LAS 1.4 are defined using WKT v1, which unfortunately has no mechanism for defining temporal datums16. OGC developed WKT v2 in part to mitigate this issue, and a new version of LAS will be needed, as LAS 1.4 is explicitly tied to WKT v1.
The release of NATRF2022 and related reference frames is expected to be in 2024 or 2025. This gives time to prepare and release LAS 1.5, so long as the software companies keep up with our developments.
Other proposed changes in LAS 1.5
Given that a new version is therefore necessary, we also have the opportunity to introduce new trimmed-down point formats more suitable for point clouds derived from sources other than lidar17, and potentially encode LDP references in the LAS header itself, rather than relying on VLRs for this information.
Importantly, the LWG rejected a proposal to deprecate the old point formats 0-5 in LAS 1.518. We felt that leaving them helped preserve backwards compatibility. This demonstrates the value of community involvement and soliciting feedback in a public forum that can be reviewed later if the matter resurfaces.
Other modifications will certainly be included as LAS 1.5 is developed. Having learned from the confusion and resultant delays surrounding the release of LAS 1.4, however, LWG intends to make the upgrade from LAS 1.4 to LAS 1.5 as propitious as possible. I expect a release toward the end of 2022 or early 2023.
LWG business and future meetings
Welcome new LWG member Jochen Keil from rapidlasso GmbH19, stepping in for our dearly missed friend and longstanding LWG veteran Martin Isenburg. Jochen will be a valuable addition to our team.
The agenda for the meeting scheduled for January 17, 2022 was headed by a final review of LAS 1.4 Revision 16 before submission for publication. It also included a review of the wiki updates described in this article. The meeting will be reported in the next article in this series.
1 https://lidarmag.com/2021/05/22/las-exchange-las-working-group-releases-first-public-registry-2/
2 https://www.asprs.org/wp-content/uploads/2010/12/LAS_Domain_Profile_Description_Topo-Bathy_Lidar.pdf
3 https://github.com/ASPRSorg/LAS/issues/117
4 https://github.com/ASPRSorg/LAS/wiki/Standard-ExtraByte-Definitions
5 Variable Length Record
6 https://github.com/ASPRSorg/LAS/issues
7 https://github.com/ASPRSorg/LAS/wiki
8 https://github.com/ASPRSorg/LAS/wiki/User-Contributed-VLRs
9 https://www.asprs.org/misc/las-key-list.html
10 https://github.com/ASPRSorg/LAS/issues/111
11 https://github.com/ASPRSorg/LAS/wiki/How-to-View-Edits
12 https://github.com/ASPRSorg/LAS/wiki/Waveform-Data-Packet-Descriptors-Explained#storage-size
13 https://github.com/ASPRSorg/LAS/milestone/6
14 https://github.com/ASPRSorg/LAS/issues/6
15 https://www.ngs.noaa.gov/datums/newdatums/index.shtml
16 https://github.com/ASPRSorg/LAS/issues/95
17 https://github.com/ASPRSorg/LAS/issues/93
18 https://github.com/ASPRSorg/LAS/issues/94
19 https://rapidlasso.de/