<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
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.<br>
I might be wrong and subjective on some points but my impressions
were: <br>
GRASS is great up the the million points limit, (2 Gb machine) then
things get problematic<br>
Postgres/postgis is great for playing with complex queries but what
about visualization?<br>
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.<br>
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.<br>
Cheers everyone and thanks for the interesting conversation.<br>
Ciao<br>
Francesco P.<br>
<br>
Il 07/04/2011 06:59, Hamish ha scritto:
<blockquote cite="mid:20110407165936.24658242.hamish_b@yahoo.com"
type="cite">
<pre wrap="">Mike Grant wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">We use GRASS for a lot of this (perhaps you've covered it
with qgis?).
</pre>
</blockquote>
</blockquote>
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, grass is on my list but got omitted from the mail.
</pre>
</blockquote>
<pre wrap="">
the offerings are not unsubstantial.
fwiw see
<a class="moz-txt-link-freetext" href="http://grass.osgeo.org/wiki/LIDAR">http://grass.osgeo.org/wiki/LIDAR</a>
<a class="moz-txt-link-freetext" href="http://grass.osgeo.org/grass-wiki/images/LAS_serpent_nviz.jpg">http://grass.osgeo.org/grass-wiki/images/LAS_serpent_nviz.jpg</a>
v.outlier, v.lidar.correction, v.lidar.edgedetection,
v.lidar.growing, v.surf.bspline, processing modules, etc.
<a class="moz-txt-link-freetext" href="http://grass.osgeo.org/grass64/manuals/html64_user/vector.html">http://grass.osgeo.org/grass64/manuals/html64_user/vector.html</a>
...
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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 :/
</pre>
</blockquote>
</blockquote>
<pre wrap="">
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:
<a class="moz-txt-link-freetext" href="http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2011#3D_visualization">http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2011#3D_visualization</a>
I'll follow your LAG progress with interest, maybe we can learn
something from each other's efforts/approaches.
Etienne wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap="">
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
<a class="moz-txt-link-abbreviated" href="mailto:Liblas-devel@lists.osgeo.org">Liblas-devel@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/liblas-devel">http://lists.osgeo.org/mailman/listinfo/liblas-devel</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font face="Arial, Helvetica, sans-serif" size="-1">
**************************************************<br>
<b>Francesco Pirotti</b> <br>
Dep. TESAF <br>
CIRGEO – Interdepartmental Research Center on Cartography
Photogrammetry <br>
Remote Sensing and G.I.S. <br>
University of Padova <br>
Web: <a
href="http://www.cirgeo.unipd.it/cirgeo/francescopirotti.htm">http://www.cirgeo.unipd.it/cirgeo/francescopirotti.htm</a>
<br>
Email: <a href="mailto:francesco.pirotti@unipd.it">francesco.pirotti@unipd.it</a>
<br>
Phone: +39 049 827 2710 <br>
Phone: +39 349 55 39 261<br>
**************************************************
</font></div>
</body>
</html>