lidR (version 2.0.2)

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)

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.

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:

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

• cores: How many cores are used.

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

• laz_compression: is not supported because this function will never write las/laz files.

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