[GRASS-dev] Announcing libLAS

[Hamish]

Mateusz:
> Yes, it confirms what I've read in GRASS docs and Wiki pages,
> that there is no direct support to ASPRS LAS format.
...
> I'm willing to contribute a module for LAS read/write. However, I'm not
> an experienced GRASS user nor developer, so I'll likely need to prepare
> myself a little (read docs and code) before I can start. Means, I'm not
> sure I can provide you with ready solution very soon.
...
> The libLAS building follows well-known *nix patterns and there is 
> autotools-based builder. Optionally, users are provided with cmake 
> configuration as well as project files for Visual C++ 2005.
> The library itself has no external dependencies.

Hi,

I don't claim to know anything about what libLAS does, so sorry if this
doesn't make sense. But if it is purely vector format I/O would it be
better to write it as a new format for GDAL's OGR and have grass access
it with v.in.ogr? Then other FOSS softwares could easily gain advantage
of it too.

http://liblas.org/wiki/LASElements

Or is the dataset size/model such that it is better to directly
import/process it in GRASS using fast C modules as a front end to the
lib?

or simply DAS export to a text file:
DAS -> x|y|z|extra1|extra2|extra3|... + header metadata  | r.in.xyz ?


Helena:
> > But this will raise a question for GRASS dev whether we want to add 
> > another dependency to GRASS in addition to GDAL and PROJ and a number
> > of optional ones?

I see no problem adding new optional depenencies, if they are useful,
added into the build system properly, switched off by default, and
license compatible.



Hamish





      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ