[Liblas-devel] Open source lidar software?

[Hamish]

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