Suboptimal hierarchy generated with coords in lon/lat degrees and Z in meters

[wonder-sk]

When using untwine with a dataset that has X/Y coordinates in degrees (and Z in meters), the resulting hierarchy is quite suboptimal:

• some leaf nodes have very high number of points (nearly 900K points in a single node)
• there are various intermediate nodes with zero points (apparently that is allowed by the spec, but maybe not desired?)

Test file: https://noaa-nos-coastal-lidar-pds.s3.amazonaws.com/laz/geoid18/6209/WakeCoNC/20140208_LA_37_20164901.laz

Related QGIS bug: qgis/QGIS#48311 (QGIS was not allowing nodes with zero points, fix in qgis/QGIS#49834)

Here's a dump of the hierarchy generated by untwine (D X Y Z count):

  0 0 0 0 count 569
  1 0 0 0 count 0
  2 0 0 0 count 0
  3 0 0 0 count 0
  4 0 0 0 count 0
  5 0 0 0 count 0
  6 0 0 0 count 0
  7 0 0 0 count 87128
  7 0 0 1 count 222
  8 0 0 2 count 0
  9 0 0 4 count 116961
  9 0 0 5 count 168283
  8 0 0 3 count 0
  9 0 0 6 count 253713
  9 0 0 7 count 310784
  6 0 0 1 count 0
  7 0 0 2 count 519
  8 0 0 4 count 0
  9 0 0 8 count 0
  10 0 0 16 count 189771
  10 0 0 17 count 165428
  9 0 0 9 count 0
  10 0 0 18 count 174603
  10 0 0 19 count 186679
  8 0 0 5 count 0
  9 0 0 10 count 0
  10 0 0 20 count 191338
  10 0 0 21 count 225442
  9 0 0 11 count 0
  10 0 0 22 count 245423
  10 0 0 23 count 258218
  7 0 0 3 count 1003
  8 0 0 6 count 0
  9 0 0 12 count 0
  10 0 0 24 count 279492
  10 0 0 25 count 273957
  9 0 0 13 count 0
  10 0 0 26 count 314121
  10 0 0 27 count 412480
  8 0 0 7 count 0
  9 0 0 14 count 0
  10 0 0 28 count 529741
  10 0 0 29 count 658572
  9 0 0 15 count 0
  10 0 0 30 count 839400
  10 0 0 31 count 846679
  5 0 0 1 count 0
  6 0 0 2 count 1406
  7 0 0 4 count 0
  8 0 0 8 count 0
  9 0 0 16 count 0
  10 0 0 32 count 869505
  10 0 0 33 count 899607
  9 0 0 17 count 0
  10 0 0 34 count 697704
  10 0 0 35 count 522273
  8 0 0 9 count 0
  9 0 0 18 count 0
  10 0 0 36 count 456234
  10 0 0 37 count 265011
  9 0 0 19 count 0
  10 0 0 38 count 190288
  10 0 0 39 count 165754
  7 0 0 5 count 0
  8 0 0 10 count 0
  9 0 0 20 count 287739
  9 0 0 21 count 260210
  8 0 0 11 count 0
  9 0 0 22 count 244611
  9 0 0 23 count 237456
  6 0 0 3 count 370
  7 0 0 6 count 0
  8 0 0 12 count 0
  9 0 0 24 count 219842
  9 0 0 25 count 202668
  8 0 0 13 count 0
  9 0 0 26 count 172119
  9 0 0 27 count 135518
  7 0 0 7 count 0
  8 0 0 14 count 143616
  8 0 0 15 count 14894

[hobu]

Entwine and Untwine assume rectilinear coordinates with the units of all dimensions being the same. That's not the case with lng/lat/m data like this. Possible options:

• Store the data as ECEF where that assumption is met
• Modify Entwine/Untwine to try to do magic when this condition is encountered.

[uclaros]

An extent to this issue is that those point clouds may get coordinates in their info VLR's center_x and center_y that are not valid geographic coordinates, causing issues when trying to display them in QGIS