Hello,<br>
<br>
The current proposal for the new LAS 1.4 specification breaks away in compatibility from the LAS 1.0 – LAS 1.3 family. In an open letter [1] I explain why this is a terrible idea. I also show how easy it would be to fix the current proposal. So far the ASPRS committee has ignored these concerns that are shared among a number of reputed LAS developers. What can you do? Contact the ASPRS LAS committee [2,3], ask for a copy of the proposed specification, and join a discussion [4] in an open forum (maybe not on this list (-:).<br>

<br>
[1] <a href="http://www.cs.unc.edu/%7Eisenburg/lastools/download/open_letter_broken_LAS_1_4_specification.pdf" target="_blank">http://www.cs.unc.edu/~isenburg/lastools/download/open_letter_broken_LAS_1_4_specification.pdf</a><br>

[2] <a href="http://www.asprs.org/a/society/committees/standards/lidar_exchange_format.html" target="_blank">http://www.asprs.org/a/society/committees/standards/lidar_exchange_format.html</a><br>[3] <a href="http://groups.google.com/group/ASPRS-LAS/members">http://groups.google.com/group/ASPRS-LAS/members</a><br>
[4] <a href="https://lidarbb.cr.usgs.gov/index.php?showtopic=13592" target="_blank">https://lidarbb.cr.usgs.gov/index.php?showtopic=13592</a><br>
<br>
Some more detail: The proposed LAS 1.4 specification is not backwards compatible and also breaks the forward compatibility of the LAS 1.X family that, for example, had allowed a LAS 1.1 reader to read a LAS 1.3 file that contains only points of type 0 or 1. Furthermore, it - for the first time - will require a LAS programmers to implement at least two different LAS specifications if they want their software to read and write LAS content other than LAS 1.4.<br>

<br>
Fixing this broken LAS 1.4 specification requires nothing more than to rearrange a few count and offset fields in the LAS header as detailed in the open letter [1].<br>
<br>
Regards,<br>
<br>
Martin @lastools