Adjusting the "R" parameter within the li2012() algorithm

[mcoghill]

I have been trying to segment trees multiple ways, and while it can be slow I always appreciated the simplicity of the li2012() segmentation algorithm, as it only requires that the LAS object is passed to it. In comparison, other provided segmentation algorithms require a CHM be provided in order to run (or both a CHM and calculated treetops found through a separate tree detection algorithm).

I was interested in understanding the li2012() algorithm further, so I looked at the coding of the provided algorithm which follows the exact steps intended from the original paper, with some optimizations. The algorithm has a parameter R, which is the search radius for a local maxima. This maxima is found on this line, which effectively uses the defined R parameter as the search radius in the filter_local_maxima C++ function.

My thought was that the R parameter can be more finely tuned in the li2012() algorithm. Much like how the lmf() tree detection algorithm can accept either a single number or a function for its ws parameter, I am proposing that the R parameter in the li2012() algorithm should be able to handle a function and pass on the resulting window sizes for each point to the filter_local_maxima function to be able to define the search radius for each point. I am admittedly a novice when it comes to C++ programming, but I have created a fork of the lidRplugins package which contains a prototype function li2012_auto(), which can be found here.

Also within that fork, I have created a similar function to the lmfauto() tree detection algorithm, lmfxauto(). The main difference between the original and my implementation is that the first step uses lmfx(5) instead of lmf(5), which increases the speed of that function a bit. The coding for generating the window size within lmfxauto() is re-used inside the li2012_auto() function when the R parameter is defined as NULL; in other words, window size (aka: R) is automatically calculated for each point before running the filter_local_maxima function. I have placed that all into the R function file algo-li2012_auto.R.

I wonder if this is something that is worth implementing into the existing li2012() algorithm? Or if this should stand alone in my own plugin? The only significant change to the C++ coding is that the data type of the R parameter changes from double to NumericVector within both the LAS::segment_trees and C_li2012 functions, and then implementing the acceptance of a function to the R parameter in the li2012() algorithm. Please feel free to browse my forked repository of lidR.li2012enhancement here. Thanks for any and all feedback!

[Jean-Romain]

I wonder if this is something that is worth implementing into the existing li2012() algorithm?

Test it, compare it, measure it and publish it. If you can go to last step I'll happy to add it into lidR if you wish. But at this step I can't say anything about it.

lidR contains only peer reviewed algorithms. lidRplugins contains either peer reviewed algorithm that do not actually work as claimed in their respective paper, or algorithm of mine that were not peer-reviewed and published. So, in a first step you could make your own plugin for lidR. Later if you can reach the publication step I'll be happy make a native implementation in lidR.

---

Also please rename your fork and update your readme. You removed almost everything from lidRplugin and copy many things from lidR. Your fork is no longer really a fork of lidRplugin. You are better to create a brand new repo with your own name.

[mcoghill]

Thanks @Jean-Romain, I have renamed my package to lidR.li2012enhancement and updated the Readme file as requested.

As for the testing, comparison, measurements, and publishing - I will have to get on that at some point!

I have a question as well that expands beyond what I have done here. As I mentioned, I'm not well versed in C++, so I'm wondering if anyone sees any opportunity in being able to parallelize the currently existing li2012() algorithm? I'm not sure if it's possible or not, but happy to hear out thoughts on it. Thanks again!

[Jean-Romain]

If it were trivially parallelisable I would have written a parallel version. Sadly the processing of one point depends on the previous one in Z order. This makes the algorithm non trivially parallelizable. However, I think there it is room for improvement (greater than what can be achieve with parallelism) by writing it in a smarter way. This is not trivial and this is why I never took time to think about it. But if you want to collab with me to sudy an "improved version" of li2012 I'm keen to dedicated time on it.