Adding max_depth to COPC info VLR

[leo-stan]

What does everyone think about adding 'max_depth' to the copc info VLR? It would allow to easily know what the maximum resolution of an octree is based on 'spacing', without having to go through the whole hierarchy to find that value?

[connormanning]

What would this be used for? This is an extremely poor indicator of dataset resolution, and I can't think of any other way to use this information.

[leo-stan]

Well since the spacing is halved at each level we would be able to quickly know what the minimum spacing is.

[connormanning]

How would you put such a value to use? I don't understand why you'd want to know the minimum spacing. It doesn't hold throughout the entire tree, so you still need to traverse intelligently to the leaf nodes to get the data.

[CCInc]

Here is the use case:

I want to determine what depth contains a certain resolution, exactly akin to

https://github.com/PDAL/PDAL/blob/1a7415f67cfe13f816345ce4b7fc1c68f0a45c83/io/EptReader.cpp#L243-L266

However, PDAL does not cap the depth it returns to the maximum depth it finds in the file; instead, it returns depths that go beyond the maximum depth.

I need to cap the depth to the maximum real depth within the file. As a result, I currently have to read in the entire file hierarchy, when this computation should be able to be done without the hierarchy, given the max_depth is provided. To me, there is no usefulness of returning a depth that does not exist. If a user queries a resolution and that resolution goes beyond what the file can provide, then providing the lowest depth level that exists in the file would be the expected behavior.

[connormanning]

I need to cap the depth to the maximum real depth within the file

I still don't really understand the real-life use-case here, and cannot envision a scenario where this would be helpful. Why is this? What are you trying to do with this information? The usefulness of the max_depth completely disappears if you are doing spatial filtering (e.g. searching for data within a bounds or polygon), and I'd argue it is hardly useful even dealing with a full dataset. Here are a couple analyses I've run on some EPT data, listing the number of nodes at each depth (these datasets differ in point count by about 25x):

Dataset A
0: 1
1: 8
2: 23
3: 64
4: 179
5: 559
6: 1901
7: 6866
8: 26290
9: 102257
10: 402098
11: 1590066
12: 6393939
13: 4612534
14: 584980
15: 68

Dataset B
0: 1
1: 8
2: 27
3: 74
4: 223
5: 647
6: 1481
7: 4181
8: 12020
9: 31147
10: 74199
11: 147018
12: 106105
13: 17312
14: 2679
15: 190
16: 2

As you can see, the max_depth values of 15 and 16 tell you almost precisely nothing about the datasets themselves - that's all you'd get in these cases: the numbers 15 and 16 here with no other context. They are nowhere near as dense as their max_depth values would imply, and the spatial extents of the actual data described by the max_depth is on the order of 0.001% of the full dataset.

To me, there is no usefulness of returning a depth that does not exist

What does "return" mean in this context? I still don't really understand the use-case here - can you go up an abstraction level in your description? E.g. is this a user-facing proxy for a notion of the dataset resolution, or something else?