Closed mosscoder closed 4 years ago
Why do you want a index = TRUE
in catalog_apply()
? I mean, you have an index or you don't have an index. If you have lax files along with your las file this will be leveraged automatically.
I think your problem is the hidden function lidR:::catalog_laxindex()
right? If the function is not exported and not documented it is because I think one should better use lasindex
from LAStools. catalog_laxindex
is just a wrapper around the (open) source code of lasindex
but with simplifications so it can only uses the default parameters without any tuning.
In some cases the products of catalog_apply are for me intermediate, and I plan to use catalog_apply later in subsequent processes. Applying all of the functions in a single call of catalog_apply is not always as efficient because of differences in memory demands between functions, and catering tile size and number of workers for each function can speed up a pipeline. Having an index output would save having me remember to call laxindex.
Ok so to simplify you want that e.g. lasfilterdecimate
returns a catalog already indexed instead of a regular set of files without index. More generally, you want that, if catalog_apply()
writes LAS files, those files should be indexed.
This feature should better belong in writeLAS()
writeLAS(las, path, index = TRUE)
With an access to the option through the drivers
ctg@output_options$drivers$LAS$param$index = TRUE
This way there are much more benefits of such feature. That makes sense and it is easy to implement this way. I'll do that this afternoon.
Done. I added index = FALSE
in writeLAS()
. This way everything is controlled by the drivers. With
ctg@output_options$drivers$LAS$param$index = TRUE
It should work everywhere in lidR in theory.
Thanks for this!
Would it be possible to include an index=TRUE/FALSE logical argument in catalog_apply? Save folks from having to extract lidR:::catalog_laxindex from the documentation?