Incorrectly indexed file with null bounding box

[wonder-sk]

A user has pointed me to this dataset (28 MB LAZ):
https://drive.google.com/file/d/1YNBnZvc_85cXuMm9Tn1uS3Uzbkn7lKEt/view?usp=drive_web

Untwine indexes it incorrectly with the following hierarchy:

{
"0-0-0-0": 1,
"1-0-0-0": 0,
"2-0-0-0": 0,
"3-0-0-0": 0,
"4-0-0-0": 0,
"5-0-0-0": 0,
"6-0-0-0": 0,
"7-0-0-0": 7700716
}

Looking at the file's metadata, it seems the source of the trouble could be the fact that min/max X/Y/Z coordinates are all zero.

The user says the file was produced with CloudCompare, and CloudCompare also correctly displays it (which I can confirm).

I am not sure what to do here - is the file simply incorrectly written? Or is it valid? Should untwine detect such cases and handle them gracefully or just fail with some error message?

[abellgithub]

Do we know why cloud compare produced a file with invalid bounds?

[abellgithub]

The title here say "incorrectly indexed", but I don't know that it's invalid as such.

I'm not sure what should happen here. We use the bounds and point count provided in the header to make decisions so that we don't have to read the data an extra time to determine this. The bounds could be a little bad or a lot bad. Are you wanting a test to make sure that if the area of the bounds is zero then we report an error? Something else?

[wonder-sk]

After some investigation done by users, it seems the issue is the following: CloudCompare has two LAS read/write implementations - one is based on LASLib (shown to the user as LAS 1.3 or 1.4 (*.las *.laz) filter), the other one is based on PDAL (shown to the user as LAS cloud (*.las *.laz) filter). Using PDAL implementation works fine, but the LASLib-based implementation ends up writing null bounding box. The LASlib plugin is only available on Windows as far as I can tell. Users have barely any idea what is the difference between those two choices so they may randomly pick one or another.

CloudCompare seems a popular choice when it comes to basic operations such as merging and clipping of point clouds. So there may be many LAS/LAZ files floating around with null bounding box due to that, it seems that some software does not worry about the bounding box issue when loading such data. I am not a big fan of introducing workarounds for bad implementations, so I am wondering just like you what to do. I guess we can just detect cases when maxx <= minx || maxy <= miny and then either

• decide to fail immediately with an error message
• spit out a warning, then read all points to calculate the true bounding box before doing pre-flight phase

The latter solution would be of course nicer for the user, but I would be also happy with the former if we can propagate the message to the user...

Maybe @hobu has any thoughts on that?

[abellgithub]

I put a warning in the code, but perhaps someone (me?) should send a fix for CC to deal with this?