[Liblas-devel] libLAS 1.6.0b4 Released

Howard Butler hobu.inc at gmail.com
Fri Jan 7 16:24:25 EST 2011


All,

The libLAS team is pleased to announce the release of libLAS 1.6.0b4 and the inaugural release of Martin Isenburg's stand-alone, LGPL'd LASzip LAS compression library.  I would like to thank both Martin Isenburg and Michael Gerlek for their hard work developing and integrating LASzip into libLAS.

I'll let Martin answer any questions about LASzip's inner workings, but my experience with it has been wonderful.  LASzip is meant to provide lossless compression for ASPRS LAS data, and its integration in libLAS allows you to directly read .laz (LASzip compressed LAS files) directly like you would an uncompressed .las file.  You can compress your data from the command line via las2las, as well as use the new liblas::{ReaderFactory|WriterFactory} to work with compressed data in your software.  LASzip compression has not yet come to the C or Python APIs yet, but this is planned for a future release.

As with anything, there's no free lunch, and LASzip's compressed data comes with both a reading performance cost and a writing performance cost.  It is up to you to determine where and how to use the technology to your benefit, but there are certainly situations where the tradeoff is worth it.  http://liblas.org/samples/ can provide you an example of what kinds of compression ratio and variability you might expect with LASzip with each file now provided in both compressed and uncompressed form.  Here are some simple 5-run /usr/bin/time examples of a las2las invocation on the hobu.las file from the sample library.  It has about 1.3 million points.  Times are in seconds.  It's not definitive (or repeatable!), but it should give you some idea of the tradeoffs you'll be making.

> fire:data hobu$ ./check_compression.sh 
> Testing  hobu.las
> Writing compressed data...
>         1.15 real         0.93 user         0.15 sys
>         1.11 real         0.93 user         0.14 sys
>         1.11 real         0.93 user         0.14 sys
>         1.12 real         0.93 user         0.15 sys
>         1.11 real         0.93 user         0.14 sys
> Filesize: 7.4M
> Writing uncompressed data...
>         0.76 real         0.30 user         0.33 sys
>         0.79 real         0.30 user         0.34 sys
>         0.91 real         0.30 user         0.37 sys
>         0.76 real         0.30 user         0.33 sys
>         0.79 real         0.30 user         0.33 sys
> Filesize: 32M
> Ratio: 4:1
> Reading compressed data...
>         1.58 real         1.55 user         0.02 sys
>         1.58 real         1.55 user         0.02 sys
>         1.58 real         1.55 user         0.02 sys
>         1.59 real         1.55 user         0.02 sys
>         1.59 real         1.55 user         0.02 sys
> Reading uncompressed data...
>         0.52 real         0.43 user         0.07 sys
>         0.51 real         0.43 user         0.07 sys
>         0.52 real         0.43 user         0.07 sys
>         0.52 real         0.43 user         0.07 sys
>         0.51 real         0.43 user         0.07 sys

Another very important note is that random reading through the file, in the form of ReadPointAt and friends is rudimentarily supported, and you should expect lots of pain (each call means decompressing the entire file to that point before giving you your data) if you do so.  It is hoped that future work will provide some knobs to allow "slighly random" access through the LASzip-compressed file in the form of chunking.

Here's a list of other things that have been fixed since 1.6.0b3:

* liblas-config script should be available and working again for Unix clients that were using the autoconf-based version
* pkgconfig script now available (thanks Ed Hill)
* liblas::Schema::GetDimension now returns boost::optional< Dimension const&> instead of throwing exception
* libLAS-specific std::exceptions are now thrown (still based on std::runtime_error) to provide more granularity than just the runtime_error that was rampantly thrown previously
* numerous performance tweeks, in the form of eliminating unnecessary function calls and reordering operations where it made sense.  b4 is significantly faster, especially for common operations like simple las2las filtering jobs
* lasblock --write-points actually writes out all of the blocks instead of the first block over and over again
* las2txt: the classification number was being written out as a byte instead of int
* libLAS libraries, liblas and liblas_c, are now versioned with SONAMEs on unixes
* RPM spec file now available (thanks Ed Hill)

Thanks to all who provided bug reports and especially Mauricio Terneus of Certainty3D for the performance and LASzip testing help on IRC.  I look forward to hearing of your experiences with libLAS.  Head to http://liblas.org/download.html to obtain your copy of both LASzip and libLAS.  The OSGeo4W builds have also been updated to include both.

Howard 

 


More information about the Liblas-devel mailing list