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
