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
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
_______________________________________________
Liblas-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/liblas-devel
