[R-sig-Geo] decimate points from a Lidar file

[Michael Denslow]

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