Figure 1: This example Commit shows the incremental changes in the plain text files of the specification itself. In this case, a “Byte Offset” column was inserted into the EVLR header table.
The meeting of the LAS Working Group (LWG) on 18 January 2021 meeting began with a review of updates to its wiki pages[1]. With a new sidebar, we’ve made navigation within the wiki significantly easier. We also added a new page with wiki editing tips to facilitate community edits to the wiki.
Most importantly, the Standard System Identifiers[2] page was officially released as the first published public registry now being maintained on the LWG GitHub page. In the works for a couple of years, this registry provides a concise methodology for encoding multiple sensors and/or platforms into the System Identifier field of the LAS header. This is a necessity for properly representing the source system for tiled LAS datasets that contain data from multiple sources. Examples and lookup tables are also provided to make integration into existing software significantly easier.
PDF build procedure
Figure 2: Every change to the specification automatically results in a new draft PDF that incorporates those changes in a human-readable PDF. These PDF “artifacts” persist for 60 days before being automatically deleted to prevent circulation of unwanted drafts.
Over the holidays, the LWG also made a significant behind-the-scenes change in how the specification is maintained. Let’s begin with a little background.
The LAS specification’s raw format is a set of text files encoded with mostly Markdown formatting and a sprinkling of LaTeX. By storing the raw format as text instead of binary (such as the Microsoft Word *.docx format) we can leverage the power of Git and GitHub to show line-by-line differences and merge multiple versions together with minimal effort. This approach has an added advantage: most software developers are familiar with GitHub.
Despite the convenience of maintaining plain text files, however, a static and versioned PDF is far easier to read, reference and cite when one is using the specification for development, contracting and standards. Therefore, we needed some sort of automated system for conveniently converting the plain text files into PDFs, preferably with zero manual effort and minimal maintenance.
When we made the transition to GitHub, LWG elected to use Sphinx[3], an open-source documentation generator that can convert raw text files into a human-readable and attractively formatted PDF, for this purpose. Every time a new Commit was made to the GitHub repository, an elaborate series of scripts would create a virtual machine using third-party software, run Sphinx, and post the PDF to an Amazon Web Services (AWS) S3 bucket, which was generously paid for by an LWG member. This system was extremely complex, hard to maintain, and relied on the member to continue his munificence.
The new system still relies on Sphinx, but instead leverages GitHub Actions[4] to create the virtual machine and run Sphinx within GitHub itself. The build system no longer relies on third-party software or AWS, making it much easier to maintain. Now, a draft PDF is available directly on GitHub every time someone makes a change. These PDFs are temporary objects that stay available for 60 days, after which they disappear. They can be recreated on-demand by rerunning the GitHub Action.
For example, in this Commit[5] (Figure 1), I inserted the byte offset column (see below) into the Extended Variable Length Record header table. When I finished my edits, I saved the Commit, and GitHub automatically began running this action[6] (Figure 2). Two and a half minutes later, the plain text files were transformed into a PDF incorporating the changes from that commit (Figure 3).
Byte offset columns
Figure 3: The draft PDF was automatically generated and provides an opportunity to review the incremental change enacted by the Commit – in this case, the insertion of the Byte Offset column into the EVLR header table.
The remainder of the LWG call reviewed upcoming changes in the LAS 1.4 Revision 16. Most notably, the point data record format tables will have byte offset columns added (Issue-55[7]) to improve readability and usability of the specification for programmers.
Byte offset columns were added also to the VLR, EVLR and LAS header tables. This set of changes is nearly finished and currently under review by LWG.
LWG moderation notes
All public forums are vulnerable to off-topic posts and potential hijacking, and the LWG GitHub page is no different. Maintaining a helpful, positive and collaborative environment without stringent barriers on public access requires everyone’s cooperation.
All posts on a topic must be directly relevant to the original post. If a topic strays from its original purpose or is hijacked by personal interests, LWG members and the Chair are empowered to remove off-topic posts at will. If the post is helpful, but simply a different topic, we will likely seed a new Issue with that post so that both conversations may continue unabated.
If the errant posts are not relevant to LWG at all or obviously motivated by personal interests, the user will receive a public warning or ban for repeated or egregious offenses. In the spirit of collaboration and community, I’d prefer to keep this to a minimum. The formula seems to have worked so far. Let’s keep it that way.
Welcome new members and closing remarks
In January, LWG welcomed new member Carol Lockhart (Woolpert), an expert in the topobathymetric domain. To join LWG, you must be a paid member of ASPRS, so that the organization can continue its leadership position in the remote sensing community.
Keep an eye on the ASPRS newsletter and LAS homepage[8] for the final review of LAS 1.4 Revision 16, which is expected to go up for publication in the first quarter of 2021.
[1] https://github.com/ASPRSorg/LAS/wiki
[2] https://github.com/ASPRSorg/LAS/wiki/Standard-System-Identifiers
[3] https://www.sphinx-doc.org/en/master/
[4] https://github.com/ASPRSorg/LAS/actions
[5] https://github.com/ASPRSorg/LAS/commit/482aea026be1e9bf96429ddb8b621e60f10d4604
[6] https://github.com/ASPRSorg/LAS/actions/runs/494835288