# lidR turns airborne LiDAR into forestry analysis in R

> lidR is an R package for reading, writing and analysing airborne LiDAR data, with canopy height model algorithms, individual tree segmentation, wall-to-wall tile processing and full waveform support, all aimed at forestry research. It suits a forest scientist working with LAS and LAZ tiles, and it needs a stack of geospatial system libraries.

**r-lidar/lidR** — Airborne LiDAR data manipulation and visualisation for forestry application

- Repository: https://github.com/r-lidar/lidR
- Website: https://CRAN.R-project.org/package=lidR
- Stars: 715 · Forks: 141
- Language: R
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/r-lidar-lidr

## A research package with published algorithms in it

lidR is an R package for airborne LiDAR data manipulation and visualisation for forestry applications, and the feature list at the top of the README tells you what the package is actually for. It reads and writes .las and .laz files, plots point clouds, computes metrics using an area-based approach, computes digital canopy models, thins LiDAR data, manages a collection of LAS and LAZ files, automatically extracts ground inventories, processes a collection of tiles using multicore processing, segments individual trees, classifies points from geographic data, and provides other tools to manipulate LiDAR data in a research and development context. The phrase in a research and development context is doing real work in that list, because several of these features are research conveniences rather than production utilities, and the individual tree segmentation rules illustrate it. The segment_trees() function has several algorithms from the literature, and each has been coded from the source article to be as close as possible to what was written in the peer-reviewed papers, with the stated goal of making published algorithms usable, testable and comparable. That is a strong position for a scientific package, because it means a result from the literature can be reproduced rather than approximated.

## Reading and plotting a point cloud is three lines

The entry point is the file, and the plotting function follows the R convention of being called plot. The README describes it as based on rgl, which enables the user to display, rotate and zoom a point cloud:

```r
las <- readLAS("<file.las>")
plot(las)
```

That is the whole quickstart, and the point of it is that a LAS file is a research object rather than a picture, so the first thing you do with it is look at it in three dimensions. The same function is used for the derived products, which is why the package feels coherent. Once you have a canopy height model you plot it, and once you have segmented trees you plot them coloured by tree ID. The tree segmentation example shows the pattern, with a segmentation algorithm applied to the point cloud and then a plot coloured by the tree identifier using a random colour palette. The underlying data model is that everything, raw points, a raster canopy model, a segmented point cloud, is a first class R object with a matching plot method.

## Canopy height models come from point-to-raster or triangulation

The canopy height model is the central derived product in forestry, and lidR has several algorithms from the literature to compute it, either point-to-raster based or triangulation based. The point is that this allows testing and comparison of methods that rely on a CHM, such as individual tree segmentation or the computation of a canopy roughness index. The example in the README uses the Khosravipour et al. pitfree algorithm, with a threshold vector and an edge vector, rasterised onto a one metre grid:

```r
las <- readLAS("<file.las>")

# Khosravipour et al. pitfree algorithm
thr <- c(0,2,5,10,15)
edg <- c(0, 1.5)
chm <- rasterize_canopy(las, 1, pitfree(thr, edg))

plot(chm)
```

A pitfree-style method works by interpolating the canopy surface between points that are above a height threshold, and the threshold vector means the interpolation changes as the height band changes, which is how it handles gaps under dense canopy. The edge parameter controls how edges are treated. The structure of the call, an algorithm generator passed to a generic rasterizer, is the pattern for the whole package, since the same rasterize_canopy function also accepts a triangulation based algorithm such as p2r.

## A catalog turns a folder of tiles into one dataset

Real forestry surveys are not one file, they are a folder of tiles that together cover a property, and lidR's answer is the LAScatalog object. The readLAScatalog function builds one from a folder, and the plot function displays the collection on an interactive map using the mapview package if it is installed:

```r
ctg <- readLAScatalog("<folder/>")
plot(ctg, map = TRUE)
```

From a catalog you can extract regions of interest with clip_roi(), and the documentation is explicit that using a catalog for the extraction of the ROI guarantees fast and memory-efficient clipping, since the work happens tile by tile rather than on a merged file. The catalog also unlocks the multicore processing path, and the wall-to-wall processing example shows the payoff, where a catalog is loaded and then processed exactly like a LAS file, with the rasterize_canopy call taking the catalog and the same algorithm that worked on a single file. The engine takes advantage of point indexation with laz files, takes care of processing tiles with a buffer so that edge effects do not appear at tile boundaries, and allows for processing big files that do not fit in memory. Users can create their own methods with catalog_apply().

## Full waveform support exists but is early

Full waveform LiDAR records the complete laser pulse rather than a single return, and lidR can read it from LAS files with interpreter functions that convert the raw data into something easier to manage and display in R. The README is careful about the state of it, saying the support of FWF is still in the early stages of development, and the example reflects that framing. You read the waveform file, interpret it, and then plot the discrete points and the waveforms together, with the interpreted object carrying an amplitude attribute that drives the colour:

```r
fwf <- readLAS("<fullwaveform.las>")

# Interpret the waveform into something easier to manage
las <- interpret_waveform(fwf)

# Display discrete points and waveforms
x <- plot(fwf, colorPalette = "red", bg = "white")
plot(las, color = "Amplitude", add = x)
```

The add argument to the second plot call is what layers the interpreted points over the waveform rendering. A reader should treat this as a feature to watch rather than a settled one, given the stated maturity, and it is worth checking the NEWS file for the current state of the interpreter before relying on it for a specific analysis.

## System dependencies are the real install story

Because the package links against geospatial C libraries, the GNU/Linux install instructions list a set of development packages that have to be present before R can build it. On Ubuntu you add the ubuntugis unstable repository, update, and then install libgdal-dev, libgeos++-dev, libudunits2-dev, libproj-dev, libx11-dev, libgl1-mesa-dev, libglu1-mesa-dev, libfreetype6-dev, libxt-dev and libfftw3-dev. On Fedora the equivalent set is gdal-devel, geos-devel, udunits2-devel, proj-devel, mesa-libGL-devel, mesa-libGLU-devel, freetype-devel and libjpeg-turbo-devel. The set is not arbitrary, it maps to the four things the package does, which are projection handling through PROJ and GDAL, geometry through GEOS, units through udunits2, and 3D rendering through the X11 and OpenGL libraries. The install of the R package itself is a single call, install.packages("lidR"), and the package is on CRAN, with a GPL-3 licence and a build status badge. The README also points at a book, the lidRbook, for a fuller introduction, and mentions a newer companion package, lasR.

## Conclusion

Adopt lidR when your forestry work involves airborne LiDAR tiles and you want published algorithms, area based metrics and tree segmentation in the same R workflow. Do not adopt it for a one-off point cloud inspection, since the system library requirements are heavy, and do not treat it as a general purpose point cloud library for other domains. Verify first that you can install the geospatial dependencies on your platform, that your LAS and LAZ files carry the classification and extra bytes the algorithms need, and that the version on CRAN matches the documentation of the functions you plan to use.

## FAQ

### What can lidR do with airborne LiDAR data?

It reads and writes .las and .laz files, plots point clouds, computes metrics with an area-based approach, computes digital canopy models, thins data, manages a collection of LAS and LAZ files, extracts ground inventories automatically, processes tiles with multicore, segments individual trees, classifies points from geographic data, and reads full waveform data.

### How do I compute a canopy height model with lidR?

Pass an algorithm generator to rasterize_canopy with a resolution and your point cloud. The README example uses the Khosravipour et al. pitfree algorithm with a threshold vector and an edge vector, rasterised at one metre, and the package has several algorithms from the literature available in both point-to-raster and triangulation based forms.

### What does an LAScatalog give me in lidR?

A LAScatalog is built from a folder with readLAScatalog and can be displayed on an interactive map with mapview. It enables fast and memory-efficient ROI clipping, multicore processing, and wall-to-wall processing of a tile collection with buffering so tile edge effects do not appear, and users can add their own methods through catalog_apply().

### What system libraries does lidR need on Linux?

On Ubuntu the instruction is to add the ubuntugis unstable repository and install libgdal-dev, libgeos++-dev, libudunits2-dev, libproj-dev, libx11-dev, libgl1-mesa-dev, libglu1-mesa-dev, libfreetype6-dev, libxt-dev and libfftw3-dev. On Fedora the equivalents are gdal-devel, geos-devel, udunits2-devel, proj-devel, mesa-libGL-devel, mesa-libGLU-devel, freetype-devel and libjpeg-turbo-devel.

## Sources

- [License: GPL-3.0](https://github.com/r-lidar/lidR/blob/master/LICENSE)
- [Project website](https://CRAN.R-project.org/package=lidR)
- [README](https://github.com/r-lidar/lidR/blob/master/README.md)
- [Releases](https://github.com/r-lidar/lidR/releases)
- [r-lidar/lidR on GitHub](https://github.com/r-lidar/lidR)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/r-lidar-lidr