In the documentation

It shows that the key design of the 64 bit identifier cellid is
4 bit lod | 24 bit z | 12 bit y | 24 bit x

lod | z | y | x

However, in the mapindex.h when I examine struct CellID
it has the layout

z | y | x | lod

the lod is in a different position in the bits.
Should I trust the mapindex.h or the documentation?

Ultimately I am trying to have different behavior in an extension for LOD0 then the others, and I was having issues and not sure if this is related.  Its hard to extract some of the runtime parameter values from the extension v1_getVoxels.  Since there is no easy way to see it, aside from setting up arbitrary unusual behavior to test, and when things crash, its hard to better understand.
0 0
The image has a mistake, which is the x and z fields are swapped. Aside from that, the order is correct. Please note the first field to be declared in the structure lands on the least significant bits. The order is:

lod | x | y | z

Where LOD is the most significant bits.

As long as you use the packCellId() and unpackCellId() functions, the actual key layout should be opaque to your code. If you are using these functions it is likely the issues you see are not related to key layout.
0 0
I found out what my underlying issue of confusion. I had been assuming that the LOD bits were 1:1 with their names?  So does that make LOD_1 equivalent to 3?

//from VoxelFarmConfig.h
/// First level of the world octree that is actually visible
static const int8_t LOD_0 = 2;

Why is LOD_0 = 2?  Why not 0 or 1? 
0 0
LOD_0 is set to 2 to make today Voxel Farm applications future proof. If for instance we introduce a method that increases detail by storing data at actual LOD 0 and LOD 1, any of the data created by your application and its users would benefit from this without having to remap your cell key space. Your spatial databases would load, procedural algorithms would not require updating, etc.

Another way to look at it is, you can think of the LOD system as a pyramid. Content is written into sections of this pyramid. By starting at actual lod 2, we have reserved a high-resolution slice of the pyramid for future use.

Why 2 and not 1 or 3? Two slices are enough to allow the complexity grow by 64 times in the future, which seems an adequate trade-off for the reserved levels. That means your application could be released today, and you would need to consider remapping your key space only after the fidelity of your voxel data has increased by 64 times.
0 0