-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error when files are overwritten with CRS set #69
Comments
What you want is to create new LAZ files with the same names as the LAS files and later remove the LAS files. Replacing the original collection of LAS files on-the-fly would technically be possible but requires custom developments such as the internal list of files is updated on-the-fly with a lot of tests to guarantee that everything is ok and valid.
I tried this minimal reproducible example. Everything looks good to me library(lasR)
file <- system.file("extdata", "MixedConifer.las", package = "lasR")
pipeline = set_crs(25832) + write_las(ofile = paste0(tempfile(fileext = ".laz")))
ans = exec(pipeline, on = file)
file.size(file)
#> [1] 1356219
file.size(ans)
#> [1] 266571
library(lidR)
las1 = readLAS(file)
las2 = readLAS(ans)
plot(las1)
plot(las2) |
sorry for mixing this up, compressing files in place was just my initial thought and has nothing to do with this issue I guess. In my example above we overwrite a file which initially has no proper CRS set (it is compressed before already). It should have the same number of points and its area is 1kunits² before and should be 1km² afterwards. |
Does this looks like your use case? In this case you have an error and you corrupted your original file. I should add a protection against overwriting files. What is happening is that library(lasR)
file <- system.file("extdata", "MixedConifer.laz", package = "lidR")
file2 = tempfile(fileext = ".laz")
file.copy(file, file2)
file.size(file)
file.size(file2)
pipeline = set_crs(25832) + write_las(ofile = file2)
ans = exec(pipeline, on = file2)
file.size(file)
file.size(file2)
file.size(ans) |
Yes exactly, I tried this because if we are trying to update files (e.g. set CRS, compress,...) it would be convenient to not duplicate memory on disk if running it on large collections (temporarily if we delete old files afterwards). But if it is not possible there should be an error instead of corrupting files I think.
With your example I also get a slightly smaller file which is corrupted, but I also get an error |
I understand. Your use case is not supported yet but this is not something technically impossible. By the way you could do it by forcing the data to be loaded in memory. In this case overwriting the file does not corrupt it reading because it has already been read. Yet, if the pipeline crashes for any reason you loose your original file. This is why a better method would be to write a temporary file and move it if the writing is successful. pipeline = set_crs(25832) + lasR:::nothing(read = TRUE) + write_las(ofile = file2)
ans = exec(pipeline, on = file2)
Absolutely
Please provide a reproducible example then. |
Not yet sure how to do this, probably by making the CRS in header invalid. trying to do this like this crashes R instantaneously library(lasR)
file <- system.file("extdata", "MixedConifer.laz", package = "lidR")
file2 = tempfile(fileext = ".laz")
pipeline = set_crs(0) + write_las(ofile = file2)
ans = exec(pipeline, on = file) while |
I added a test to prevent overwritting the processed files ( |
I was wondering if it would be possible to update/overwrite existing files in place. My original intend was to compress files from LAS to LAZ and directly get rid of uncompressed files, but I guess this is not possible with lasR.
I also tried to update files with wrong CRS information, what happens is that files are actually overwritten, and in this case header information about CRS is updated. However, files are only 257kb in size afterwards, it seems they are cropped to smaller extent.
I guess this is not intended, otherwise its easy to corrupt entire archives of data!?
Created on 2024-07-08 with reprex v2.1.0
The text was updated successfully, but these errors were encountered: