Michael:
Typically Lidar files come "tiled", e.g. you get a set of point
clouds pre-subsetted to, say, 1km x 1km window. These subsetted data
are usually a LOT easier to write some batch scripts to deal with than
trying to analyze the entire database at once. Have you seen if the
source of the Lidar data has a tiled set (most companies will provide
the data this way)? This will expand the number of things you can do
with the data...
--j
Michael Denslow wrote:
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.biv...@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.biv...@nhh.no
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
--
Jonathan A. Greenberg, PhD
Postdoctoral Scholar
Center for Spatial Technologies and Remote Sensing (CSTARS)
University of California, Davis
One Shields Avenue
The Barn, Room 250N
Davis, CA 95616
Cell: 415-794-5043
AIM: jgrn307, MSN: jgrn...@hotmail.com, Gchat: jgrn307
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
