Closed wonder-sk closed 3 years ago
I believe this is due to the threading used in the identify tool, and thread unsafe use of the Las decoder. I looked into this yesterday and the point data being read from the dataset is getting randomly corrupted during the block creation, leading to points with random coordinates (which consequently don't fall within the search area).
I believe this is due to the threading used in the identify tool, and thread unsafe use of the Las decoder. I looked into this yesterday and the point data being read from the dataset is getting randomly corrupted during the block creation, leading to points with random coordinates (which consequently don't fall within the search area).
I removed QtConcurrent::blockingMappedReduced from the identify code and the same problem occurs: the values for X, Y and Z are 0 when I get them from the point data
Fix is here: https://github.com/qgis/QGIS/pull/40847
Basically we can't assume x/y/z values in the laz files are always integers
Awesome - tested and it works fine now
It seems that if a dataset is indexed to EPT with laszip data type, identify does not work well - for example it does not return any identify results, or some points can't be identified at all when zoomed in. It seems this is not a problem with binary/zstandard encoding - maybe some issue with offset/scale stuff?