[Liblas-devel] Some ideas for class organization

[Howard Butler]

On Dec 16, 2007, at 8:54 PM, Martin Isenburg wrote:

> hi guys,
>
> thanks for keeping me in the loop. i work more on the science part  
> of things and am not really software engineer so i trust your design  
> decisions.

Ok.  If you join the mailing list, we'll keep most traffic and  
activities there or in IRC if you want to follow along closely.   
Again, thanks for providing an excellent jumping off point.

>
>
> but do you think it is necessary to provide support for indexed  
> access to the points? are there any applications for that? accessing  
> individual points by inxe would break whenever the LASfile is  
> gzipped (or provided as a piped stream). i would assume that most  
> applicaitons will batch process the points. a conditional read (sort  
> of implemented in las2las) might be more useful. like read only  
> points that are classified as ground points ... etc
>

One immediate application of indexed reads I can see is to hook up the  
ids to something like spatialindex http://research.att.com/~marioh/spatialindex/ 
  where storing the Rtree alongside the .las file can provide quick  
bbox query support.  An application where this utility might be  
important is data warehousing/dissemination applications, where you  
have an index of .las files, each .las file has a spatial index, and a  
user requests data for a specified area within one of the files.

We need to think more about the piped stdin case, but one approach  
might be to mmap (or some such) it.  I can see how the proposed  
approach would be limiting in that case though.  Mateusz and Phil may  
have some other ideas...



> also ... assuming that lasformat 2.0 will eventually be  
> standardized. followed by 2.1 ... etc ... it seems the single  
> LASFile class could need more flexibility to be easy to upgrade in  
> the future. if the class would use writer and reader objects that  
> might be easier to realize.
>
> apart from wrapping my code into a new .. more useful design are you  
> also planning to create new funcitonality? such as LAS2.0 support?  
> gridding? clean-up? etc ...?
>

The eventual hope is to use libLAS to provide a driver for GDAL/OGR.   
GDAL/OGR has simple gridding support, and many other tools such as  
GRASS use GDAL as a data format reader, so making a driver for LAS can  
provide a lot of leverage to other applications.  It also supports  
projections, spatial referencing, datum transformations, etc.

As far as other new functionality, an immediate need is providing  
wrappers to other languages like C# and Python.  I want to keep an eye  
on LAS 2.0 and engineer things in a way that we can easily provide  
support for it (or maybe even just do it).  Do you happen to know when  
2.0 will be finalized?

Howard