Understanding rayextract trees vs rayextract forest

[ShukhratSh]

Hi Thomas,
I've recently been working with the Rayextract module and have encountered some interesting observations regarding the differences in output between the "rayextract trees" and "rayextract forest" commands. I wanted to share my findings and seek your expertise to better understand the results.

To provide some context, I ran both "rayextract trees" and "rayextract forest" commands on a small multiscan plot with a 25-meter radius. Here are the specifics of the commands used:

Rayextract trees:
rayextract trees *_raycloud_decimated.ply *_raycloud_decimated_mesh.ply --distance_limit 0.05 --height_min 2 --girth_height_ratio 0.12

Rayextract forest:
rayextract forest *_raycloud_decimated.ply --ground *_raycloud_decimated_trees_mesh.ply --trunks *_raycloud_decimated_trunks.txt --smooth 15

My observations are as follows:

"RayExtract Trees" detected a total of 174 trees.
"RayExtract Forest" detected a total of 52 trees.

The calculated volumes of trees differ significantly between the two methods.

Notably, the chosen parameters for "--distance_limit" and "--girth_height_ratio" in 'rayextract trees' have a significant impact on the tree volume.
Lower values tend to produce more realistic volume estimates, whereas higher values result in bulkier trees.
I would appreciate if you help me understand the underlying reasons for these discrepancies and to explore the possibility of creating similar data from each method.

Thank you,

Kind regards,
Shukhrat

[thomas-lowe]

Hi Shukhrat, rayextract forest is designed for aerial data where the undercanopy is considered to be so sparse as to not be trusted. So the algorithm ignores all undercanopy and converts the highest lidar points in to a height map, with the option to include any trunks that you have found using rayextract trunks. So rayextract forest only finds trees where there is a dome-like protrusion in the canopy, and adds a trunk under that dome (adjusted to the input trunks if one exists). rayextract trees assumes that the trees are well-represented by the lidar points, so reconstructs all trunks and branches from the points. This is better suited to ground-based lidar. It would be nice if they both produced the same number of trees, but they are very different methods. One likely reason for the fewer trees in rayextract forest is that it is unable to find the small trees. That can happen if the crown is small, ill-defined, or if it is hidden under larger tree crowns. A smaller 'smooth' value might get you a few more trees. Regarding the other parameters: --distance_limit is how far it looks to connect lidar points from the ground up. I am surprised it works well down at 5cm, you must have a dense lidar map with few occlusions. Too small a value means branches of the trees that are disconnected by this distance will not be reconstructed.

…

--girth_height_ratio is how high up the tree it estimates the trunk girth. This depends on your forest, the best value is above the undergrowth but below the first branches on the trunks, so that it gets a clean cylinder to estimate the girth. Happy to discuss further Thomas Lowe

[ShukhratSh]

Hi Thomas,

Thank you for your prompt response; it's greatly appreciated. Your input has provided a lot of clarity.

I do have another question: From what I understand, using the command "rayimport *.ply ray 0,0,0 --max_intensity 0 --remove_start_pos" designates the initial point as 0, and subsequently determines the XYZ coordinates of other points in relation to this initial point.

However, when executing "rayextract terrain," the tool identifies terrain points and constructs a mesh that represents the terrain.
Consequently, the heights of the trees are also calculated from the underlying mesh surface, which might not necessarily begin from 0. As a result, this disparity leads to inaccurate tree height calculations.

Is there a way to assign a base value of 0 to all terrain points, allowing for tree height calculations based on the terrain, like the methodology employed in generating canopy height models? However, I'm concerned that I might be overlooking something.

Thank you once again for your assistance.
Shukhrat

[thomas-lowe]

Hi Shukhrat,
if you do rayimport forest.ply --remove_start_pos then yes, the output forest_raycloud.ply will be offset so the first point in the cloud is at (0,0,0).
If you then do rayextract terrain forest_raycloud.ply the output mesh will be in the same coordinates as forest_raycloud.ply
If you then do rayextract trees forest_raycloud.ply forest_raycloud_mesh.ply the output _trees.txt will be in this coordinate frame.

So if your terrain is on a hill, the tree root positions will be on a hill.
The easiest way to get the tree heights is to run treeinfo forest_raycloud_trees.txt which adds a height value for each tree in its output _trees_info.txt tree file. This is in treetools: https://github.com/csiro-robotics/treetools
You can visualise these heights with e.g. treecolour .._info.txt tree height and then see the coloured meshed result with treemesh .._info_coloured.txt -v. You can read them in to your code either by parsing the trees .txt file yourself, or including raycloudtools as a C++ library and using the ray::ForestStructure load command.

I don't have a function to 'subtract' the ground heights to make the trees all aligned vertically at the base.

[ShukhratSh]

Hi Thomas,

Thank you for your quick response. It looks like there is a need for a function to identify ground points, assign them a value of 0, and then calculate tree heights based on this ground reference. It ensures the accuracy of tree height measurements. From the attached screenshot, the existing approach doesn't provide accurate tree heights as the lowest point values for the trees are not 0. I might be missing some important steps, please let me know.

[thomas-lowe]

There are multiple ways to calculate tree height relative to the ground: Height of reconstructed branches: treeinfo cloud_trees.txt --> cloud_trees_info.txt with a height field per-tree. Either parse the txt file yourself or use the raycloudtools C++ library function ray::ForestStructure::load(). Height range of the lidar points for each tree: raysplit cloud_segmented.ply colour, then use rayinfo on each output tree to see the bounding box range. Or using the C++ interface: Ray::Cloud::load("cloud_segmented.ply"); then iterate through all points to get highest and lowest for each colour (height is cloud.ends[i][2]). I don't have a function to flatten the ground (and move everything down) as it distorts the cloud and rays are no longer straight. But you could write that using the C++ interface. Thomas Lowe Senior Experimental Scientist Data61 | CSIRO ***@***.******@***.***> | 07 3327 4027 | 0487 433 606 (optional) 1 Technology Court, Pullenvale, QLD, 4069 CSIRO acknowledges the Traditional Owners of the land, sea and waters, of the area that we live and work on across Australia. We acknowledge their continuing connection to their culture and we pay our respects to their Elders past and present. CSIRO Australia’s National Science Agency

[ShukhratSh]

Hi Thomas,

Thanks for the clarification. I wasn't aware that "treeinfo" accounts for ground when extracting tree heights. It makes perfect sense why you are not flattening the ground. Your software is truly impressive!!