Interpolates the ground points and creates a rasterized digital terrain model. The algorithm uses the points classified as "ground" (Classification = 2 according to LAS file format specifications) to compute the interpolation. How well the edges of the dataset are interpolated depends on the interpolation method used. Thus, a buffer around the region of interest is always recommended to avoid edge effects.
grid_terrain(las, res = 1, algorithm, keep_lowest = FALSE,
full_raster = FALSE)An object of class LAS or LAScatalog.
numeric. The resolution of the output Raster. Can optionally be a RasterLayer.
In that case the RasterLayer is used as the layout.
logical. This option forces the original lowest ground point of each cell (if it exists) to be chosen instead of the interpolated values.
logical. By default the interpolation is made only within the convex hull of the point cloud. This prevent against meaningless interpolations where there is no data. If TRUE each pixel of the raster is interpolated.
A RasterLayer containing a numeric value in each cell. If the RasterLayers
are written on disk when running the function with a LAScatalog, a virtual raster mosaic is
returned (see gdalbuildvrt)
This section appears in each function that supports a LAScatalog as input.
In lidR when the input of a function is a LAScatalog the
function uses the LAScatalog processing engine. The user can modify the engine options using
the available options. A careful reading of the
engine documentation is recommended before processing LAScatalogs. Each
lidR function should come with a section that documents the supported engine options.
The LAScatalog engine supports .lax files that significantly improve the computation
speed of spatial queries using a spatial index. Users should really take advantage a .lax files,
but this is not mandatory.
Supported processing options for a LAScatalog in grid_* functions (in bold). For
more details see the LAScatalog engine documentation:
tiling_size: How much data is loaded at once. The tiling size may be slightly modified internally to ensure a strict continuous wall-to-wall output even when tiling size is equal to 0 (processing by file).
buffer: This function guarantees a strict continuous wall-to-wall output. The buffer option
is not considered.
alignment: Align the processed clusters. The alignment may be slightly modified.
chunk size: How much data is loaded at once. The chunk size may be slightly modified internally to ensure a strict continuous wall-to-wall output even when chunk size is equal to 0 (processing by file).
chunk buffer: This function guarantees a strict continuous wall-to-wall output. The buffer
option is not considered.
chunk alignment: Align the processed chunks. The alignment may be slightly modified internally to ensure a strict continuous wall-to-wall output.
progress: Displays a progress estimate.
output_files: Return the output in R or write each cluster's output in a file. Supported
templates are XLEFT, XRIGHT, YBOTTOM, YTOP, XCENTER, YCENTER
ID and, if chunk size is equal to 0 (processing by file), ORIGINALFILENAME.
select: The grid_* functions usually 'know' what should be loaded
and this option is not considered. In grid_metrics this option is respected.
filter: Read only the points of interest.
# NOT RUN {
LASfile <- system.file("extdata", "Topography.laz", package="lidR")
las = readLAS(LASfile)
plot(las)
dtm1 = grid_terrain(las, algorithm = knnidw(k = 6L, p = 2))
dtm2 = grid_terrain(las, algorithm = tin())
dtm3 = grid_terrain(las, algorithm = kriging(k = 10L))
# }
# NOT RUN {
plot(dtm1)
plot(dtm2)
plot(dtm3)
plot_dtm3d(dtm1)
plot_dtm3d(dtm2)
plot_dtm3d(dtm3)
# }
Run the code above in your browser using DataLab