[Liblas-devel] Open source lidar software?

Peder Axensten Peder.Axensten at slu.se
Thu Apr 7 04:27:40 EDT 2011


I'm working on an R library to interface with libLAS. My idea is to implement most of the functionality in C++ operating on files. You create an object that only holds meta data of the files and then this object is used in the R environment, e.g. as.data.frame( las-object ) and SpatialPointsDataFrame( las-object ) reads the las-files etc. I have such basic functions implemented, but I'd like to implement rasterisation of las files (various metrics) before making it available on R-forge.

Does this sound useful?
If there is enough interest, I guess I could make it available earlier.

The library uses the libLAS and Boost libraries and will use GDAL for rasterisation. 

Best regards,

Peder Axensten
Research engineer

Swedish University of Agricultural Sciences
Dept. of Forest Resource Management
Forest Remote Sensing


On 7 apr 2011, at 07.28, francesco wrote:

> 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 
> Phone: +39 049 827 2710 
> Phone: +39 349 55 39 261
> **************************************************
> _______________________________________________
> Liblas-devel mailing list
> Liblas-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/liblas-devel



More information about the Liblas-devel mailing list