[Liblas-devel] Open source lidar software?

[francesco]

Hi,
I've been trying out the following open source on lidar data: GRASS, 
postgres/postgis, R, Martin Isenberg's lastools (not clear if source is 
all open). I also use commercial TerraSolid's products to compare.
I might be wrong and subjective on some points but my impressions were:
GRASS is great up the the million points limit, (2 Gb machine) then 
things get problematic
Postgres/postgis is great for playing with complex queries but what 
about visualization?
R is great, you get a lot of analysis tools there is a gl library so you 
can see points (but of course not optimized for massive points view - 
i.e. it does not spatially organize the points in quadtree structures) - 
but there is a lot of dancing you can do to elegantly overcome such 
things - for example you can use "chunk" to read every nth point. 
Classic R objects are all stored in RAM but there are specific modules 
for massive data to store in disk space (ff). Importing is still done 
thru a csv file - it would be great to port  liblas to R to read 
directly into a data frame the points.
Today I am trying R with postgres postgis to processa 4 Gb of Riegl's 
multi-echo  terrestrial laser dataset. Il'' put some stuff on my website 
as soon as I find the time.
Cheers everyone and thanks for the interesting conversation.
Ciao
Francesco P.

Il 07/04/2011 06:59, Hamish ha scritto:
> Mike Grant wrote:
>>> We use GRASS for a lot of this (perhaps you've covered it
>>> with qgis?).
> QGIS's GRASS toolbox only supplies simplified access to GRASS
> modules. I think there's a self-imposed 3-parameter limit to
> any particular module(?). So a great way to get access to some
> of GRASS's analysis modules, but you just get access to some of
> the power (e.g. spline tuning, anisotropy, and cross-validation
> options may require full-GRASS).
> Currently, AFAICT r.in.xyz is supported by QGIS's GRASS toolbox (but
> without file pre-scanning capability), but not any of the more
> specialized v.lidar modules.
>
>
> Michael Gerlek wrote:
>> Yes, grass is on my list but got omitted from the mail.
> the offerings are not unsubstantial.
>
> fwiw see
>    http://grass.osgeo.org/wiki/LIDAR
>    http://grass.osgeo.org/grass-wiki/images/LAS_serpent_nviz.jpg
>    v.outlier, v.lidar.correction, v.lidar.edgedetection,
>      v.lidar.growing, v.surf.bspline, processing modules, etc.
>    http://grass.osgeo.org/grass64/manuals/html64_user/vector.html
>    ...
>
> I think the current record for biggest-file-attempted with
> r.in.xyz's statistical gridding is the US Fish&  Wildlife
> Service's processing of a c.600GB dataset into a 1m DEM (and
> that took just hours). A 20gb dataset would run almost as fast
> as you can read it from the disk, and RAM needs are minimal.
> I regularly work with 50-200GB (similar x,y,z,return strength
> multibeam sonar) datasets without much trouble.
>
> Dealing with massive vector maps in GRASS 6+ still takes a
> little dance to avoid memory issues (ie you need to disable/
> ensure not to enable attribute database and topology support),
> but most of the modules you'd use with LIDAR data (e.g. filtering,
> display, and DEM creation modules) have gotten bypass-flags added
> to them now so they can run in "lean and mean" mode. GRASS 5's old
> points format handles the huge datasets better, but what you can do
> with it is much more limited.
>
>>> We wrote a LAS viewer (GPL) for bigger-than-RAM LIDAR data
>>> but we've not published it yet so it also doesn't count :/
> Helena Mitasova of N. Carolina State Univ. has some ideas from
> her lab to extend GRASS's venerable NVIZ (n-dimensional OpenGL
> visualization) suite to play better with massive point swarm
> datasets. It's one of GRASS's Google Summer of Code 2011 project
> ideas:
>    http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2011#3D_visualization
>
> I'll follow your LAG progress with interest, maybe we can learn
> something from each other's efforts/approaches.
>
>
> Etienne wrote:
>> For specific usages (individual point processing and interaction
>> with other geometries) I'm using Postgis. However, I don't know of
>> any way to directly load .las files.(GPL)
> I'm sure we could whip something together quickly to do that (pipe
> las2txt ->  sed ->  pgsql, or for cross-platform support do a similar
> script using python). The trick, as always, is to find how to do that
> efficiently.. which probably means a rather simple las2pgsql C[++]
> program to write, with the added benefit that the metadata could be
> transferred into PostGIS without a bunch of automated cut&  paste.
>
> How about LAS ->  Spatialite/SQLite ? anyone tried that with a large
> dataset? How does performance compare vs. PostGIS?
>
>
> regards,
> Hamish
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel
>
>


-- 
**************************************************
*Francesco Pirotti*
Dep. TESAF
CIRGEO -- Interdepartmental Research Center on Cartography Photogrammetry
Remote Sensing and G.I.S.
University of Padova
Web: http://www.cirgeo.unipd.it/cirgeo/francescopirotti.htm
Email: francesco.pirotti at unipd.it <mailto:francesco.pirotti at unipd.it>
Phone: +39 049 827 2710
Phone: +39 349 55 39 261
**************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/liblas-devel/attachments/20110407/e2cdc6fb/attachment.html