-
-
Notifications
You must be signed in to change notification settings - Fork 15
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
Invalid reading of lax file on windows #50
Comments
Here is the result of lasinfo -i "C:\TMP\lidR_bug\transfer_85074_files_52cf1058\clip.las"
> extended number of point records: 8143683 |
I tried with las2las -first_only -i 157668.5_243478.3.las -o test.las
lasindex -i test.las Linux las <- rlas::read.las('~/issue 408/test.las', filter = "-inside 157980 243480 158270 243770")
dim(las)
#> [1] 5292612 18 Windows las <- rlas::read.las('~/issue 408/test.las', filter = "-inside 157980 243480 158270 243770")
dim(las)
#> [1] 686183 18 |
Does that mean that we should not use spatial indexing in windows?? This has quite broad implications! |
Have you ever encountered other issues on windows ? You are the first one to report an problem and so far we were only able to reproduce on this file. It is definitively a complex problem that needs much more investigation. |
Sure... But I don't want to manually check if something went wrong after using spatial indexing. I hope you will soon find how to fix this :-) |
Bad new for today. I've updated |
I made very little progress today. It seems that the coordinates of some points are badly read for unkown reasons. This starts at interval [72200247, 72517435] Linux
Windows
|
Hi, I would like to use spatial indexing again but I'm afraid to experience this bug again and not see it. Is there a way to test if the bug occurred in my process? |
I'm closer and closer to the bug. I reached very deep lines of code but I'm not yet sure where does it come from. I cannot say anything about this bug expect that I'm sure the lax files is properly read. What happens is that after a certain number of file cursor moves it seems that there is a lag of few bits between where the cursor should be and where it actually is. It is windows specific and never reproduced with another dataset. Your dataset is very big and this does not help to figure out the issue. It is not reproducible in all OS, not reproducible in other dataset, not reproducible with LAStools, not alway reproducible with another spatial query. My best guess so far is that it is specific to the c++ compiler used by R on windows but cannot explain why only with this dataset. But I'm still investigating regularly getting closer and closer to the problem. |
Good new I finally identified the issue 👍 . Now let try to fix it. |
Wow... Great news! |
I fixed it 🎉. That was a big issue actually and I'm surprised nobody reported it before. I'm tagging @bi0m3trics wondering if you already encountered such problem. To make it simple the problem came from the fact that your file was more than ~2GB. This is not expected to be a problem to read such big file in the regular case. However when using a lax file, the reader can jump to different parts of the files. If the file is bigger than ~2GB it may try to jump to positions bigger than 2147483647. The problem was that the code badly handled the case when compiled with |
Great |
Thank you for reporting. Please try |
I just tested... It's now working using |
Based on r-lidar/lidR#408 and using the las + lax files reported there. This issue is only reproducible on Windows
Expected behaviour (tested on R 4.0.3, Linux,
rlas
1.3.9)Observed behaviour (tested on R 4.0.3, Windows,
rlas
1.3.9)Oberservation:
rlas::writelax()
does not helplasindex
does not helpOne last thing to test on windows with LAStools (tested on Linux)
las2las -i 157668.5_243478.3.las -inside 157980 243480 158270 243770 -o clip.las lasinfo clip.las > extended number of point records: 8143683
The text was updated successfully, but these errors were encountered: