lmfx tree detection algorithm
mikoontz opened this issue · 6 comments
Hello again,
I'm revising a paper in which I tested a number of tree detection algorithms (and parameter sets) on drone-collected forest data. (the paper is in revision, but up as a preprint here if you're interested)
The best performer (as measured by a combination of forest metrics) was the lmfx algorithm from an old version of lidRplugins. I don't see that algorithm available anymore, and it also seems like it wasn't migrated to lidR. Is there a new home for it, or did it disappear? It looks like it was deleted in this commit.
I can always install lidRplugins from an old commit to get it back, but wanted to be sure I'm not missing it elsewhere.
Thanks!
For posterity, install lidRplugins from this commit to get lmfx back (though this doesn't work because lidR was built under a different version of R; I can tinker and check back in):
Edit: I was able to get this to work by first installing lidR version 2.0.2 from GitHub:
devtools::install_github("cran/lidR@fd23e40058363f2e1ea29ade94fd06504422ed1f")
devtools::install_github("Jean-Romain/lidRplugins@a06022664534778aa7c10e4681f64f61c89aad24")
It was removed in this commit 7fa8acf 5 months ago. I don't remember why. It seems to be a clean up commit.
I updated the README to more explicitely mention that lidRplugins is not a package you should rely on for important workflow.
Users should not base their important workflow on this package. It should be seen as a laboratory with more or less interesting content inside and this content can change without warning.
The point is that you should not have used the lmfx for a publication. This method relied on nothing documented in a peer-reviewed document. Even if the method were still there you should not have used it for a publication.
Algorithms based on, or backed by, a peer-reviewed paper are likely to stay in the package (or to be moved to lidR). Other tools or algorithms without any reference may be changed or may disappear without warning.
lidRplugins is not lidR. lidR is a big package with a large amount of test to ensure its robustness, to ensure backward compatibility, to check the input, outputs, with normalized version number increment, changelogs and so on. lidRplugins is just a laboratory to test some stuff, I don't even always update the version number.
Also please do not use old versions of lidR. Version 2.0.2 is 1 year old. Many improvements were made 1 one year but also many bugs were fixed. See https://github.com/Jean-Romain/lidR/blob/master/NEWS.md
citation("lidR")
#> @Manual{,
#> title = {lidR: Airborne LiDAR Data Manipulation and Visualization for Forestry Applications},
#> author = {Jean-Romain Roussel and David Auty},
#> year = {2020},
#> note = {R package version 2.2.5},
#> url = {https://github.com/Jean-Romain/lidR},
#> }The same applies to other packages mentionned
I understand the risk associated with using the experimental algorithm, and I made the decision to use it in a publication which I stand by. I did my own validation to field-measured trees in the paper-- that is sufficient for my purposes. I assume it would have been sufficient for other forest ecologists' purpose too!
I'm sorry to see lmfx go, since it was not only the best tree detector, but also was orders of magnitude faster than the next best algorithm.
I think I removed it because it was too slow
It could be back again if you want. Nothing is set in stone. As I said it is a lab with no changelog, no roadmap, no version number. If you ask me for it it is back.
However I still believe that you should not use it in a paper because it relies on nothing known and backed by a peer-reviewed document. The only publication-acceptable way to use it, in my opinion, is to describe it carefully in you M&M. Then your paper could be used to attribute a reference to the algorithm. In that case to be fair with my work you could also add me in the authorship of your paper. Then the algo could be moved to lidR and be accessible to everyone.
Hah! Fair enough. I understand your criteria for algorithms to go into lidR is that they be well-described by a methods paper.
The tree detection is a small part of the paper that I'm currently revising, so that paper won't require such a detailed description of the lmfx algorithm. I do of course cite both of your packages (lidR and lidRplugins).
If you are interested in leading a methods paper on that algorithm, then I might be able to help (with validation data and speed comparisons, etc.). I don't have the bandwidth for that until the summer at the earliest, but it could be a good contribution to the burgeoning field of lidar-inspired methods that work for structure-from-motion-derived point clouds!
In any case, thanks for your thoughts and I'm happy to close the issue (and am also happy to reopen should you decide a methods paper on the algorithm is something you'd like to lead).