C04u_18 EOTW G-Z LTIRSC LiDAR Process.pdf

End of the World G-Z Volume Estimation Process

Raymond Craig, Forester – Nez Perce Clearwater National Forest

Volume Estimates Based on Individual Lidar Derived Trees Provided by Eyler White.

Trees from 2015 Lidar and 2019 Lidar were kept as separate feature classes to prevent incorrect growth being applied.

Using Jungle Bird Cruise Data from 2020 Compared to Cruise data from same plots in 2025. The trees on each plot where then compared and any trees that grew into plot or died where removed along with extreme outliers (trees that had a negative growth or grew at a rate of 1”+ per year) were removed from the analysis. The avg growth was then calculated on the remaining trees and found to be 0.537770898 inches dbh and 5.682656827 feet height from 2020 to 2025. Tree growth of .11” / year dbh growth (rounded value) and 1.1’ / year height growth (rounded value). any height or bdh that had an end measure less than the start measure are not included.

The Lidar identified trees were grown at the above per year rate from 2015 or 2019 based on Lidar collection date to 2026 year of planned contract award. This equates to a total of 1.21” of dbh growth and 12.1’ of height growth for 2015 and .77” of dbh growth and 7.7’ of height growth for 2019. These adjusted dbhs and heights were used to estimate the project volume.

When comparing the Jungle Bird units cruised cut volume with the Lidar derived volume for those same units it was determined that the Lidar derived total volume was approximately the same. So, for all other project areas it was assumed that the Lidar derived volume would be the cut volume for those units.

Individual Lidar trees volume was estimated using ((dbh^2)*ht)/100

Using select by location each individual tree point was then assigned to the appropriate project area.

The individual tree volumes were then summed by project area and logging system.

See below for Logging System determinations.

Logging Systems Determination

R01_NCF_ELEVATION_LIDAR was converted to integer type = LoggingBreaks_FromRaster

LoggingBreaks_FromRaster Converted to polygons = RasterTo_LoggingPoly1

The grid code field in RasterTo_Poly1 was then used to determine ground-based vs skyline where ground based is all values < 36 and skyline is all values >=36 this polygon was then dissolved bases on the ground-based and skyline categories to create EOTW_EstimatedLoggingSystem and then clipped by the End of the World NEPA polygons.

To create EstimatedLoggingSystems_EOTW_NEPA_Units polygon and changed from multi part to single part = EstimatedLoggingSystems_EOTW_NEPA_Units_2

Acres were then calculated for each logging system.

Eyler White, GIS Program Manager – Nez Perce-Clearwater NFs 20260211

To extract “trees” from LiDAR derived point clouds, I used an R based script called “cloud2trees.” Full documentation can be found here:

GitHub - georgewoolsey/cloud2trees: Extract a tree list, CHM, DTM, and more from .las|.laz point cloud data

Summary of Process cloud2trees() converts .las/.laz airborne/UAS point clouds into a DTM, CHM, and an individual-tree list (crowns + treetops). By default it returns spatial objects and writes a delivery folder; enabling specific estimate_ flags computes DBH, CBH, HMD, competition, and biomass.

With the basic outputs of this tool (spatial point with estimated height/dbh) we can apply some basic volume calculations to find volume or other measurement metrics.

Steps

1. Required inputs: .las or .laz file(s); example MixedConifer.laz from lidR is used.

2. Required packages: core cloud2trees, tidyverse, sf, terra; lidR, lasR, TreeLS used;

optional leafR + LadderFuelsR for CBH.

3. Default call: cloud2trees(output_dir = tempdir(), input_las_dir = i) — returns crowns_sf, treetops_sf, dtm_rast, chm_rast, foresttype_rast.

4. Output files (written under <output_dir>/point_cloud_processing_delivery/):

CHM/DTM GeoTIFFs, final_detected_crowns.gpkg, final_detected_tree_tops.gpkg, forest type raster, model RDS/CSV files, tracking CSVs, and auxiliary files (see

README).

5. Enable optional processing by setting flags: estimate_tree_dbh=TRUE, estimate_tree_cbh=TRUE (requires leafR/LadderFu elsR), estimate_tree_type=TRUE, estimate_tree_hmd=TRUE, estimate_tree_competi tion=TRUE, estimate_biomass_method="landfire" (or "cruz").

6. ITD tuning: use itd_tuning() to evaluate and select a window-size function (ws) for cloud2trees() to improve individual tree detection. Custom ws functions are supported.

https://github.com/georgewoolsey/cloud2trees?tab=readme-ov-file#extract-trees-from-point-cloud-default https://github.com/georgewoolsey/cloud2trees?tab=readme-ov-file#extract-trees-from-point-cloud-default

7. Caveats: many columns are NA unless corresponding estimate_ flags are on;

methods are developed mainly for conifer forests and may not generalize; consider splitting heterogeneous regions for per-region tuning/processing.

Further considerations

1. CRS: use projected coordinates; ensure point cloud and vector layers share CRS (there is a force_same_crs option).

2. Sampling/model options: parameters such as cbh_tree_sample_n, cbh_estimate_missing_cbh, hmd_tree_sample_prop, and hmd_estimate_missing_hmd control training/sample sizes and modeling of missing values.

3. LANL TREES integration: use cloud2trees_to_lanl_trees() to convert outputs into LANL TREES inputs; requires specifying surface fuel parameters.