lidR (version 2.2.5)

grid_terrain: Digital Terrain Model

Description

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.

Usage

grid_terrain(
  las,
  res = 1,
  algorithm,
  keep_lowest = FALSE,
  full_raster = FALSE,
  use_class = c(2L, 9L)
)

Arguments

las

An object of class LAS or LAScatalog.

res

numeric. The resolution of the output Raster. Can optionally be a RasterLayer. In that case the RasterLayer is used as the layout.

algorithm

function. A function that implements an algorithm to compute spatial interpolation. lidR implements knnidw, tin, and kriging (see respective documentation and examples).

keep_lowest

logical. This option forces the original lowest ground point of each cell (if it exists) to be chosen instead of the interpolated values.

full_raster

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.

use_class

integer vector. By default the terrain is computed by using ground points (class 2) and water points (class 9).

Value

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)

Working with a <code>LAScatalog</code>

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

Supported processing options for a LAScatalog in grid_* functions (in bold). For more details see the LAScatalog engine documentation:

• 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.

See Also

lasnormalize

Examples

# 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)
# }