MoreOn August 22nd, the LAS Working Group (LWG) of the ASPRS Lidar Division released a draft proposal for version 1.4 of the LAS specification for review. Based on the LWG operating protocol, the revised draft was first circulated among the core group through email, with revisions made until everyone within the LWG was in agreement.
On August 22nd, the LAS Working Group (LWG) of the ASPRS Lidar Division released a draft proposal for version 1.4 of the LAS specification for review. Based on the LWG operating protocol, the revised draft was first circulated among the core group through email, with revisions made until everyone within the LWG was in agreement. The consensus draft was then sent to the ASPRS board of directors, who have since made it available to the full ASPRS membership for a review period of 60 days before ratification.
According to software developer and LWG member Martin Isenburg, the proposed specification is flawed and shouldn’t have been sent to the ASPRS board in the first place. “The specification is broken,” he said. “The lack of forward compatibility is a major problem that the LWG was made aware of well before the draft proposal was sent out for public review, but they either ignored or underestimated the implications.”
Primarily designed to address the need for more points, additional classifications, and larger return counts, LAS 1.4 contains changes in the header - changes that Isenburg said prevent existing software from reading older content stored in the LAS 1.4 format. “Many commercial [software] vendors have implemented-forward compatible LAS readers,” he said. “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, the software programs either crash or generate corrupted data.
Isenburg, who is the developer of the LAStools command line tools for LiDAR processing, created an alternate proposal for the LAS 1.4 specification that he said achieves the goals of LAS 1.4 while remaining compatible with previous versions of the specification. To test both specifications, he created an "up-converter" that turns existing LAS files into both the officially proposed and the alternate LAS 1.4 format. He then conducted a “shootout” in which he tried to open a simple up-converted test file with many different commercially available software packages. The results, he said, were even more staggering than he expected. “The official proposal resulted in 6 crashes, 15 data corruptions, one hang-up and two errors,” he said, noting that it refused to open the file in all other cases. “The alternate proposal performed flawlessly.”
Isenburg believes the official specification will cause problems because of the tendency of users to request the latest version of LAS even though a prior version would suffice. With a forward-compatible specification, the content remains accessible or requires just a simple down-conversion. He said this is frequently done for LAS 1.3 files that only contain point types 0 to 3. Down-converting them to LAS 1.2 (so they can be read by older software) only requries changing a few header bits. However, if compatibility is broken, many more users will need to down-convert their files because all forward-compatible LAS readers will suddenly fail, and the down-conversions will become much more complex. “From a technical standpoint, breaking compatibility just doesn’t make sense,” Isenburg said.
The comment period for the official draft proposal is scheduled to end on Oct. 22. However, a statement released by the LWG noted that the issue of compatibility was closed and wouldn’t be considered as part of the comment period. “This subject was extensively discussed within the LWG,” the statement said. “Our decision was against this desire because of the extreme difficulty of software support that such a scheme would present to vendors of commercial software. The problematic scenario is a LAS 1.3 reader that simply crashes when reading a LAS 1.4 file with new point record types. It should be noted that the LWG has never made any statements regarding forward compatibility of the format. It would be akin to expecting PowerPoint 2003 to read a PowerPoint 2007 file (it can’t). The LWG does not intend to revisit this issue during the comment period.”
Lewis Graham, the LWG chair, could not be reached for further comment. Isenburg said it appears that the LWG intends to move forward with the proposed official draft despite the “shootout” results and will only consider minor changes. He believes the real intent behind breaking LAS compatibility might be to “force” LiDAR users into upgrading their software quickly to accelerate acceptance of the new point formats - a move he believes will backfire. “The situation threatens to undermine the credibility of the LAS format and of ASPRS as a standardization organization,” he said. “The shootout results irrefutably demonstrate that forward compatibility in LAS 1.4 would be a useful feature for the majority of commercial LiDAR software out there, and in particular for their users.”
Comments on the proposed LAS 1.4 specification can be submitted until Oct. 22 to las@asprs.org. Discussion about the proposed specification can be found in the Google group “The LAS room.”
Additional resources: www.cs.unc.edu/~isenburg/lastools/download/open_letter_broken_LAS_1_4_specification.pdf
https://lidarbb.cr.usgs.gov/index.php?showtopic=13592
https://lidarbb.cr.usgs.gov/index.php?showtopic=11725
On August 22nd, the LAS Working Group (LWG) of the ASPRS Lidar Division released a draft proposal for version 1.4 of the LAS specification for review. Based on the LWG operating protocol, the revised draft was first circulated among the core group through email, with revisions made until everyone within the LWG was in agreement. The consensus draft was then sent to the ASPRS board of directors, who have since made it available to the full ASPRS membership for a review period of 60 days before ratification.
According to software developer and LWG member Martin Isenburg, the proposed specification is flawed and shouldn’t have been sent to the ASPRS board in the first place. “The specification is broken,” he said. “The lack of forward compatibility is a major problem that the LWG was made aware of well before the draft proposal was sent out for public review, but they either ignored or underestimated the implications.”
Primarily designed to address the need for more points, additional classifications, and larger return counts, LAS 1.4 contains changes in the header - changes that Isenburg said prevent existing software from reading older content stored in the LAS 1.4 format. “Many commercial [software] vendors have implemented-forward compatible LAS readers,” he said. “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, the software programs either crash or generate corrupted data.
Isenburg, who is the developer of the LAStools command line tools for LiDAR processing, created an alternate proposal for the LAS 1.4 specification that he said achieves the goals of LAS 1.4 while remaining compatible with previous versions of the specification. To test both specifications, he created an "up-converter" that turns existing LAS files into both the officially proposed and the alternate LAS 1.4 format. He then conducted a “shootout” in which he tried to open a simple up-converted test file with many different commercially available software packages. The results, he said, were even more staggering than he expected. “The official proposal resulted in 6 crashes, 15 data corruptions, one hang-up and two errors,” he said, noting that it refused to open the file in all other cases. “The alternate proposal performed flawlessly.”
Isenburg believes the official specification will cause problems because of the tendency of users to request the latest version of LAS even though a prior version would suffice. With a forward-compatible specification, the content remains accessible or requires just a simple down-conversion. He said this is frequently done for LAS 1.3 files that only contain point types 0 to 3. Down-converting them to LAS 1.2 (so they can be read by older software) only requries changing a few header bits. However, if compatibility is broken, many more users will need to down-convert their files because all forward-compatible LAS readers will suddenly fail, and the down-conversions will become much more complex. “From a technical standpoint, breaking compatibility just doesn’t make sense,” Isenburg said.
The comment period for the official draft proposal is scheduled to end on Oct. 22. However, a statement released by the LWG noted that the issue of compatibility was closed and wouldn’t be considered as part of the comment period. “This subject was extensively discussed within the LWG,” the statement said. “Our decision was against this desire because of the extreme difficulty of software support that such a scheme would present to vendors of commercial software. The problematic scenario is a LAS 1.3 reader that simply crashes when reading a LAS 1.4 file with new point record types. It should be noted that the LWG has never made any statements regarding forward compatibility of the format. It would be akin to expecting PowerPoint 2003 to read a PowerPoint 2007 file (it can’t). The LWG does not intend to revisit this issue during the comment period.”
Lewis Graham, the LWG chair, could not be reached for further comment. Isenburg said it appears that the LWG intends to move forward with the proposed official draft despite the “shootout” results and will only consider minor changes. He believes the real intent behind breaking LAS compatibility might be to “force” LiDAR users into upgrading their software quickly to accelerate acceptance of the new point formats - a move he believes will backfire. “The situation threatens to undermine the credibility of the LAS format and of ASPRS as a standardization organization,” he said. “The shootout results irrefutably demonstrate that forward compatibility in LAS 1.4 would be a useful feature for the majority of commercial LiDAR software out there, and in particular for their users.”
Comments on the proposed LAS 1.4 specification can be submitted until Oct. 22 to las@asprs.org. Discussion about the proposed specification can be found in the Google group “The LAS room.”
Additional resources: www.cs.unc.edu/~isenburg/lastools/download/open_letter_broken_LAS_1_4_specification.pdf
https://lidarbb.cr.usgs.gov/index.php?showtopic=13592
https://lidarbb.cr.usgs.gov/index.php?showtopic=11725
