[Liblas-devel] Squeeze me

[Etienne Bellemare Racine]

That seems like a good idea. I was wondering if it would be possible, to 
add an option to also order the points coordinates in a spatial order 
instead of (I think) a temporal one, it would be much faster to scan the 
file that way to extract any point. within a given coordinate. Would it 
enter in the laszip specifications ? Of course, it would be much slower 
to write, I know, but it would be for a longtime gain in speed of 
reading. What do you think ?

Etienne

Howard Butler wrote :
> All,
>
> I would like to announce an upcoming development effort to bring Martin Isenburg's laszip [1] [2] [3] to libLAS.  I'll let Martin explain laszip algorithms, benefits, and performance in more detail, but this email is going to outline the development effort within libLAS and describe how the pieces are going to hook together.
>
> Over the past couple of months, I have been laying the groundwork for this effort by internally refactoring a number of elements.  The first is the internal LAS reader and writers were reimplemented to behave as a few independent units rather than a monolithic class for each format file type (1.0 file, 1.1 file, etc).  Instead of liblas::detail::writer10, we now have something like liblas::detail::writer::Header and liblas::detail::writer::Point.  This decoupling allows a developer to implement their own point writer but still use our existing header writer.
>
> The mechanism by which this will work in the upcoming release are the new ReaderI and WriterI interfaces.  We will implement ReaderI and WriterI classes that will work with the laszip code to compress and decompress LAS data through the regular libLAS interface.  A few of the details have yet to be worked out, and I would like to hear some feedback on our proposal.
>
> First, a LAS file that has been compressed with laszip is much like a regular LAS file except the points have been compressed.  The header would be very much the same as a regular LAS file with a few exceptions.  Our current plan is to set the high bit on the point format id of the header so that instead of format 0, 1, 2, 3, ... we'd now have 128, 129, 130, ... as their compressed doppelgänger.  This would hopefully prevent any unaware client from attempting to read into the point data.  Second, we would add a few liblas.org VLR records that would describe some parameters of the compression (chunk size, verification bits, algorithm version, and so on).  The combination of the VLR records plus the point format high bit would trigger libLAS to use the laszip-enabled readers and writers.  
>
> The laszip code has been released as LGPL, and this prevents inclusion of it directly in libLAS source tree unless we were to make that LGPL as well (I'm not in favor of this at all).  Our current thinking is to initially allow a user to include support for it at compile time.  We hope to have the integration work done soon, but I would like to get your feedback on the effort and hear if we're planning to do something really silly before we do it.  
>
> Is seamless, lossless compression of LAS data through a libLAS interface very appealing?
>
> Howard
>
> [1] http://www.cs.unc.edu/~isenburg/lastools/download/laszip_README.txt
> [2] https://lidarbb.cr.usgs.gov/index.php?showtopic=8455
> [3] http://hg.liblas.org/zip_______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel
>