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