Dear AMAPVox team,
First of all, a happy and successful new year to you all!
We encountered an issue with AMAPVox, where we are not sure if this is a bug or if something is wrong with our configuration file. We have multiple (50) TLS scans around a single, isolated tree. Each scan should have a substantial amount of points representing the tree. The scans were performed using a Riegl VZ400i. The scans are loaded into AMAPVox using LAZ files and scan positions are defined. However, even though it is certain that several thousands to millions of points correspond to the tree in question, the .vox output file is somehow empty. The voxel space was defined to fully cover the tree in question. Progress report also reports, that all shots are either discarded (inconsistent shots) or outside the defined voxel space. This behavior only occurs for some scans, where the scan position lies outside the defined voxel space. But this is not consistent, i.e. some scans outside the voxel-space are being processed normally. If I increase the voxel space, so the scan position in question lies within the voxel space, the voxel traversal seems to work fine and we get a desired output.
Can you see anything wrong or strange in how we setup the configuration file or could this be a potential bug? It seems as if the initial check, whether the shot is intersecting the voxel-space is not working properly. We tried this with both version 2.2.1 and 2.3.2 of AMAPVox with the same outcome.
Please find attached a laz file of a scan where we encountered this issue. Due to the file size restriction of github, I downsampled the laz file to only have first returns and to only cover the immediate surroundings of the tree. The behaviour is the same as with the unfiltered point-cloud though. Also in the zip file are the config file (Ahorn_wslgarten_20230925.xml) as well a DTM asci file and the empty output.vox file.
Any help would be greatly appreciated. Please let me know if you need any further information
Thank you very much and have a great day,
Daniel Kükenbrink
BugReport.zip
Dear AMAPVox team,
First of all, a happy and successful new year to you all!
We encountered an issue with AMAPVox, where we are not sure if this is a bug or if something is wrong with our configuration file. We have multiple (50) TLS scans around a single, isolated tree. Each scan should have a substantial amount of points representing the tree. The scans were performed using a Riegl VZ400i. The scans are loaded into AMAPVox using LAZ files and scan positions are defined. However, even though it is certain that several thousands to millions of points correspond to the tree in question, the .vox output file is somehow empty. The voxel space was defined to fully cover the tree in question. Progress report also reports, that all shots are either discarded (inconsistent shots) or outside the defined voxel space. This behavior only occurs for some scans, where the scan position lies outside the defined voxel space. But this is not consistent, i.e. some scans outside the voxel-space are being processed normally. If I increase the voxel space, so the scan position in question lies within the voxel space, the voxel traversal seems to work fine and we get a desired output.
Can you see anything wrong or strange in how we setup the configuration file or could this be a potential bug? It seems as if the initial check, whether the shot is intersecting the voxel-space is not working properly. We tried this with both version 2.2.1 and 2.3.2 of AMAPVox with the same outcome.
Please find attached a laz file of a scan where we encountered this issue. Due to the file size restriction of github, I downsampled the laz file to only have first returns and to only cover the immediate surroundings of the tree. The behaviour is the same as with the unfiltered point-cloud though. Also in the zip file are the config file (Ahorn_wslgarten_20230925.xml) as well a DTM asci file and the empty output.vox file.
Any help would be greatly appreciated. Please let me know if you need any further information
Thank you very much and have a great day,
Daniel Kükenbrink
BugReport.zip