[Liblas-devel] Plans for libLAS 1.3

Howard Butler hobu.inc at gmail.com
Fri Apr 3 21:40:03 EDT 2009


On Apr 3, 2009, at 6:19 PM, Mateusz Loskot wrote:
>> - Reading strategies (choose between trading for cpu/memory)
>
> Perhaps it could be achieved with help from Boost Flyweight,
> an implementation of Flyweight Pattern
> http://en.wikipedia.org/wiki/Flyweight_pattern

That's interesting.  I'd like to also see some work toward multi- 
threaded read access, but I don't know that I have the skills to go  
too far.  It might be hard to do with our current design though.

>
>
>> - More documentation, using Sphinx to manage it, similar to the
>> MapServer website http://mapserver.org/docs
>
> Personally, I like all-in-one idea of Trac.

Our needs are too great for doing it in just Trac.  If we want PDF,  
HTML, and Windows .chm, Sphinx is the way to go.  We already maintain  
things like the README/homepage in subversion.

>
>
>> - A new utility, lasvalid, that will attempt to validate a  
>> 1.0/1.1/1.2
>> LAS file and tell you what might be wrong with it.  This will be
>> something more than the '-c' option of lasinfo.  It will have  
>> options to
>> validate header value domains, point value domains, and file layout.
>
> las2las utility could be also improved to support more complex
> filtering, for instance I'd like to be able to filter N number of
> classifications or range(s) of intensities at once.
>
> las2las --eliminate-class 0,5,7
> las2las --eliminate-intensity 0-32,128-255
>

That will get easier with real optparse-like argument parsing.   
lasvalid is needed to ensure that libLAS has a realistic shot at  
becoming the reference implementation for the ASPRS LAS format.

Howard



More information about the Liblas-devel mailing list