LAS: What’s on the Horizon

Since its introduction in 2003, the LAS file format has become the de facto standard format for point-cloud data, with support for it in nearly every relevant lidar software package. I’ll be the first to say that LAS is not perfect by any stretch of the imagination—it has no built-in indexing system, it doesn’t lend itself well to web-based streaming, and it is difficult to extend with custom attributes. Nevertheless, I believe that its widespread adoption affirms that LAS has accomplished its design objective of being a simple, compact exchange format for transferring point-cloud data between software packages.

Editor’s note: A PDF of this article as it appeared in the magazine is available HERE.

Yet there is still work to be done. LAS 1.4 has a great deal of untapped potential, particularly with the formalization of ExtraBytes that enabled limitless customization—for example, the graphics in this article show multiple applications of encoding imaging data directly in a point cloud. Lidar remote sensing technology continues to evolve at a rapid pace, and there is growing interest in LAS point clouds produced from sources other than lidar. LAS must evolve alongside these developments to remain useful, without compromising its mission to be a simple and compact exchange format.

But who stewards the LAS format? Well, that’s us—the American Society for Photogrammetry and Remote Sensing (ASPRS)¹ LAS Working Group.

ASPRS is a nonprofit scientific association whose mission is “to advance knowledge and improve understanding of mapping sciences,” including lidar. Having accepted responsibility for managing the LAS specification shortly after its initial publication, ASPRS formed the LAS Working Group (LWG), which became part of the ASPRS Lidar Division² when it was formed in 2011. Lewis Graham led the LWG admirably for well over a decade, tackling crucial advances, such as timestamp encoding, sensor fusion, full-waveform processing, and multichannel scanners, with each iteration of LAS from version 1.0 to the current standard, LAS 1.4. Anyone interested can contribute and the LWG meets remotely every two months.

Jason Stoker, then president of the ASPRS Lidar Division, invited me to take over as chair of the LWG in 2017, an offer I eagerly accepted because I believed it would drive innovation in a way that benefited the entire geospatial industry.

Role of the LWG

I see the role of the LWG as straightforward and threefold:

1. Sustain the LAS specification by improving support for new applications and technologies
2. Guide changes through free, formal, public, and transparent communication channels that can provide background on all design decisions for the specification
3. Support adoption and standardization of LAS across industries by publishing and maintaining supplemental documentation³, tables and FAQs.

As the chair, it’s my responsibility to recruit members, safeguard the specification, and foster a productive and collaborative environment within the LWG so that we can effectively exercise our responsibility to the geospatial community.

Getting Practical

Say that you have an idea for an addition to the LAS specification. How can you contribute?

You’d begin by going to the LAS specification’s Issues page on GitHub⁴ and searching the open and closed Issues for a similar idea. Assuming you don’t find your idea or question there, you can open a new Issue by creating one there using your free GitHub account. If you don’t have and don’t want an account, you can also email me at las@asprs.org with your idea and I’ll create the new Issue for you.

An Issue is rather like a discussion thread on a forum. Once an Issue is created, those who are subscribed will receive an email notification, and anyone at all can provide feedback either via email or directly on GitHub. If the idea results in a potential change to the specification, a member of the LWG will create a new Branch on GitHub dedicated to your idea and assign it to a Milestone that corresponds to a future Revision or Version (more on that later). This Branch will automatically generate a new draft of the specification, which members of the public and the LWG can comment on and revise.

Once the draft stabilizes, the changes can be submitted by anyone for inclusion in the Milestone’s draft Branch (such as the draft-1.4-R16 branch⁵) via a Pull Request. Members of the LWG are automatically notified by email that a proposal is ready, and we can accept, reject, modify, or comment on the proposed changes.

Once a Milestone’s queued Issues have all been resolved, the draft can go out for public comment via a Pull Request on to the specification’s Master Branch⁶ on GitHub. The comment period and distribution method depend on whether the new draft is a new Revision or Version of LAS.

• • Revisions: Minor changes to the specification itself, such as errata, typos, organization, and formatting, that improve the interpretation of the specification without impacting the format’s form, meaning, or structure. No changes in a revision can negatively impact existing software.
    • Example: LAS 1.4 Revision 15⁷.
    • Public comment period is two weeks, or more if needed for consensus.
    • ASPRS members are notified through the ASPRS Newsletter. GitHub members are notified automatically via email if subscribed. LWG members are notified through a private forum and the bimonthly meeting. Finally, I send out an email to all non-GitHub members of the public who subscribed their email address via the online form⁸.
  • Versions: Significant changes to the file format that impact its structure, form or meaning.
    • Minor version updates (such as LAS 1.5) maintain some level of compatibility with existing software, while adding new features or functionality.
    • Major version updates (such as the short-lived and hypothetical LAS 2.0) would significantly alter the organization of the LAS file to such an extent as to break compatibility with existing software.
    • New versions are considered an entirely new specification and must conform with the ASPRS Standards Process Policy⁹, including a 60-day public comment period and formal approval from the ASPRS Board of Directors.

My preference is to minimize expensive disruptions by avoiding releasing new Versions as much as possible. Instead, I tend to guide changes into Revisions, Domain Profiles, and the Wiki¹⁰ as much as possible, and actively work with the community to come up with creative ways to improve the experience for everyone without breaking what already exists.

This approach seems to be working. In March 2019 we released LAS 1.4 R14¹¹, the first official modification to LAS since 2013. The full change history is available¹², but in brief we added four new standard classifications, simplified the ExtraBytes data types, clarified full waveform data descriptions (published on the wiki¹³), and added language to support technologies other than conventional linear-mode lidar scanners, such as photo-derived and Geiger-mode point clouds.

Not afraid to admit when we make a mistake, we quickly published LAS 1.4 R15¹⁴ in July 2019, which was largely errata from the conversion to GitHub¹⁵.

The Future

The next revision of LAS 1.4 (R16)¹⁶ is already underway for publication later in 2020 and awaiting your contributions.

It does appear that we will need to create LAS 1.5¹⁷ within the next couple of years to support the new datums from NOAA’s National Geodetic Survey (NGS), which were recently delayed and are now scheduled to be released in the 2024-25 timeframe¹⁸. At the same time, we will probably also add a stripped-down point format that’s better suited for generic point clouds for applications other than airborne lidar remote sensing, and possibly introduce a new timestamp format that resists loss of precision over time.

My goal is for the LWG to have a representative from every software vendor, hardware manufacturer, research university, data producer, and data user.

Learn more about how you can get involved¹⁹, even if you just want the occasional email update. We’d love to have you.

---