The LAS format – introduced in 2004 by the ASPRS – has become the de-facto international standard for storing and exchanging point data acquired by airborne LIDAR scanners. It has wide acceptance and can be read and written by almost any LIDAR processing software. There now exist Exabytes of LIDAR that can easily be exchanged via the LAS format thanks to the foresight of the ASPRS in creating this standard. However, these accomplishments will be blemished by a broken LAS 1.4 specification that – if ratified – will crash software and corrupt data.
The LAS format – introduced in 2004 by the ASPRS – has become the de-facto international standard for storing and exchanging point data acquired by airborne LIDAR scanners. It has wide acceptance and can be read and written by almost any LIDAR processing software. There now exist Exabytes of LIDAR that can easily be exchanged via the LAS format thanks to the foresight of the ASPRS in creating this standard. However, these accomplishments will be blemished by a broken LAS 1.4 specification that – if ratified – will crash software and corrupt data.
On August 22, 2011, the LAS Working Group (LWG) submitted a LAS 1.4 specification for ratification that breaks away in compatibility from the LAS 1.0 – LAS 1.3 family. Previously approved specifications had always been forward compatible. For example, a LAS 1.1 reader is able to read a LAS 1.3 file as long as it only contained points of type 1. Sort of like an Adobe 6.0 reader is able to read a file created by Adobe 7.0 as long as it contain only text and images. Many commercial LIDAR software implements forward compatible LAS readers such as Terrascan, LP360, QT Modeler, ArcMap, Leica Cyclone, Fugroviewer, Topcon ScanMaster, etc. An incompatible LAS 1.4 will prevent them from reading old content stored in the new format. But worse, it will crash some of them or make them read corrupt data.
In 2009 we had the same issue with LAS 1.3 and had been able to convince the LWG to maintain compatibility (see this link for background). So as early as December 2010 we voiced similar concerns about LAS 1.4 but this time our request for compatibility was not taken seriously. Therefore I wrote an open letter to the committee, explaining the issue and suggesting a simple fix for the broken LAS 1.4 draft. I also created an open forum for discussing the LAS 1.4 specification and became a member of the LAS Working Group. But I could not stop the submission of the incompatible LAS 1.4 specification to the ASPRS board for public review.
In order to have a tangible document I created an alternate LAS 1.4 specification [PDF] that achieves the same goal as the official LAS 1.4 specification but remains compatible with the LAS 1.x family. Lewis Graham, the chair of the LWG, claimed on several occasions that the backwards / forwards compatibility described in my alternate proposal would cause software to “crash” calling it the “Isenburg Uncertainty Format”. As much as I liked his pun, quite the contrary was true as I would soon demonstrate: the incompatibility of the official proposal crashes software and corrupts data.
The official specification changes the meaning of the first 227 bytes of the LAS header by enlarging 7 counter and offset fields from 32 to 64 bit and by adding 10 new counters. This is done to accommodate larger point counts and more returns per pulse. The alternate specification achieves the same without changing the first 227 bytes by appending the enlarged and new fields at the end of the header. This replicates 7 fields but enables full forward-compatibility for those who expect it.
Many commercial vendors have implemented forward-compatible LAS readers such as Terrascan, LP360, QT Modeler, PointVueLE, DTMaster, QT Reader, Topcon ScanMaster, ArcMap, RiScan PRO, FUSION, Autodesk Map 3D 2011, Globalmapper, VrOne, Leica Cyclone, DTMaster, BCAL LiDAR Tools, Fugroviewer, 3DEM, LAStools, etc. These software packages expect a compatible LAS header. When they are given the incompatible LAS 1.4 header, they load the wrong bytes into the wrong fields. As a result, some software programs either crash or generate corrupted data. An industry-wide “LAS 1.4 shootout” was even more staggering than I expected. The official proposal resulted in 6 crashes, 15 data corruptions, one hang-up and two errors. The alternate proposal performed flawlessly.
Without any technical arguments left and despite overwhelming support for the compatible alternative, select key members of the ASPRS committee hold onto their plans to ratify an incompatible LAS 1.4 format. It bogs many people’s minds why some LWG members insist on an incompatible specification as there is no functional gain or technical reward offered by incompatibility while compatibility does not take anything away.
In personal conversations with various industry leaders I was reassured that the alternate proposal LAS 1.4 was the obvious choice but that the LAS 1.4 debate had turned into a political powerplay at this point. The LWG consists of representative of several large LIDAR players [PDF] that do not openly participate in any discussion. Several agree with me in private about the importance of maintaining compatibility but seem unwilling to comment since they are doing business with other parties involved. Plagued by outside interest that interfere with technical decision making and composed of many non-participatory members, the LWG – in its current form – is simply not a functioning standardization committee.
Should the proposed 1.4 specification be ratified it will blemish past accomplishments of the LAS format, undermine the credibility of LAS as a standard, and diminish trust in ASPRS’ ability to act in the role of a standardization body. Comments on the proposed LAS 1.4 specification can be submitted until Oct. 22 to [email protected].
