decimate points from a Lidar file
Dylan, Ken & Roger, Thank you for the suggestions and advice. This gives me a great place to start. Michael These are all
On Tue, Sep 8, 2009 at 2:36 PM, Roger Bivand<Roger.Bivand at nhh.no> wrote:
On Tue, 8 Sep 2009, Dylan Beaudette wrote:
On Tuesday 08 September 2009, Michael Denslow wrote:
Dear R-sig-geo, I am posting the following question for one of my professors. I would appreciate it if you could help me point him in the right direction. He is looking for a function which could take a lidar point shapefile and decimate (remove) a selected number of points from the file. Below is what he asked me. The file of the merged LIDAR tiles contains roughly 350,000,000 points. "I am looking for some software to take a shapefile of lidar elevation points and remove a selected number of points. The shapefile (with fewer points) would then be used to generate a DEM. A calculation of the appropriate resolution for a DEM can be made based on a relationship between the number of points and extent of the study area. The goal is to create DEMs at a series of resolutions with the appropriate points to area relationship. So a software program with which you could remove a selected number of lidar points would be helpful." I imagine that one of the packages that deals with point data (e.g. sp, spatstat) can do this kind of thing but I am not sure how to get him started. Can anyone point me to a specify function or make a suggestion. Thanks in advance, Michael
Hi, I would recommend the r.in.xyz command within GRASS GIS. It can be used for operations very similar to what you are looking for. The resulting file is a raster, decimated to some set resolution. Some screen shots: http://hamish.bowman.googlepages.com/grassfiles#xyz
Right, it is not possible to read 350 M points into R and do anything with them. I would actually suggest using a database as a store directly, possibly with some spatial support, but not necessarily. If the data were, say, in a database, subsets could be read in by selecting, or sample inclusion fields could be added to a table for samples, giving the FID values to be chosen. I feel that this would give the flexibility needed. Both SQLite and PostgreSQL are supported by OGR, so may also be accessed from rgdal functions if the appropriate drivers are present, but dumping to CSV files for smaller samples ought to be OK. If you are on Windows, see OSGeo4W or FWTools for ideas. The advantage of a database over a flat text file is that selection is much easier. You could also look at the SQLiteMap package, which uses an alternative set of spatial extensions for SQLite. Import the data outside R, then select from inside (untried). Hope this helps, Roger
Cheers, Dylan
-- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: Roger.Bivand at nhh.no
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Michael Denslow Graduate Student I.W. Carpenter Jr. Herbarium [BOON] Department of Biology Appalachian State University Boone, North Carolina U.S.A. -- AND -- Communications Manager Southeast Regional Network of Expertise and Collections sernec.org