"retrieve_pulses" does not work in LAScatalog framework?

[antoniobelchiorferraz]

ctg <- readLAScatalog("folder/with/las/inputs")
opt_chunk_size(ctg) <- 500
opt_output_files(ctg) <- "folder/where/to/store/outputs/dtm_{ORIGINALFILENAME}"
las_pulseID <- retrieve_pulses(ctg)
#> Error: Argument is not a LAS object

[bi0m3trics]

Your ctg is a catalog, not a an object of class las, and retrieve_pulses works on las objects. You'll need to use readLAS (either separately or within your custom catalog function) for that function to work.

[antoniobelchiorferraz]

Sure, I was wondering why it works with a few functions (e.g. "decimate_points") but not with a few others, including retrieve_pulses and whether there is a workaround that.

[Jean-Romain]

Two main reasons:

1. retrieve_pulse requires to create a new LAS file to store the result. Consequently retrieve_pulse applied on a LAScatalog will create a entire new collection of files for a feature that is almost instantaneous to compute on-the-fly and that have very little value added. The function may be (rarely) useful on a point cloud loaded in memory but I can't see any relevant use case on a LAScatalog
2. More importantly it is impossible to create a continuous set of pulse IDs from tile to tile. This is the exact same problem we have with locate_tree and segment_trees. See section Uniqueness in the man page of locate_trees for more details. The problem has been solved for trees but I can't see any good reason for adding so much complexity in retrieve_pulse. Especially the gpstime IS already the pulse ID so the "gpstime" strategy is meaningless.

That being said with lidR v4 you can map any function on a LAScatalog easily.

ctg <- readLAScatalog("folder/with/las/inputs")
opt_chunk_size(ctg) <- 500
opt_output_files(ctg) <- "folder/where/to/store/outputs/dtm_{ORIGINALFILENAME}"
ctg_pulseID <- catalog_map(ctg, retrieve_pulses)

But remember that pulseID will be restarted to 1 on each chunk.The problem being unsolvable this is why I did not offered a built in option

[antoniobelchiorferraz]

I see your point, but if the tiles are relatively small and the scan angle large the `retrive_pulse` suffers from tile/edge effect as unique pulses will be considered twice in adjacent tiles. Am I correct? With a LAScatalog approach, the buffer will take care of the bias.

[Jean-Romain]

It's not only a matter of edge artifacts.The engine handles that with the buffer. The problem is that pulseID necessarily restart at 1 on each chunk meaning that:

1. Two points from the same pulse spread in two chunks will have different IDs
2. On overall you will have as many pulse labelled "1" as you have chunk. pulseID cannot be unique over the entire coverage.

You should read section 1.4.1 of the book, it is the exact same problem.