[postgis-devel] 3D Index / 2D Index concerns

[Paragon Corporation]

Paul,

>> I guess that means in order to implement the && (2d interacts)  vs.  
>> &&& (3d
>> interacts) --- you had have them share separate set of index creation 
>> and operators?

> They are actually two totally different indexes on the same serialization.
The 2D index builds based on a fixed-length key and the ND index builds
based on a variable-length key.
Not quite sure what the above means, but maybe I'll have a better idea if
you answer these questions:

a) Do you have to explicitly specify you want a 2D/3D index during the build
process or does it go by the dimensionality of geometry?
b) If it goes by the dimensionality of the geometry, what happens if you
have a table where the column is just geometry with no constraints etc.  Is
it a mix of both types?  Is that what you mean by they share the same
serialization?
c) does 3D have an && and if so is it just an alias for &&&?
d) Is it possible to do a intersect check between a 2D geometry and 3D
geometry or because the indexes are built differently this is invalid?


> My main request is that we have an &&& and the 3D index version of && 
>> 2) Getting to the THIS IS VERY BAD issue.  I don't think our 3D checks 
>> make provisions for volumetric they are basically checking surface
intersection.
>> Nicklas can corect me if I am wrong, but I don't see how they Can 
>> since we can't distinguish right now between volumes and surfaces 
>> unless we assume all closed surfaces are volumes (which technically isn't
correct).

> I don't see that this is any different from the current case where the
bounds of a large irregular polygon can easily subsume the bounds of many
many many other smaller polygons nearby. It's sub-optimal, sure, but it's
not a crisis or anything.


I apologize for the bit of false alarm.  After giving it more thought
reading what you have said and Nicklas' comment, I realize now my thinking
was flawed and the 3D bbox check would give the right answer for the use
case I was talking about but would just be suboptimal.

The only cases where it would be different from the regular && (which still
concern me) would be the case Nicklas mentioned where you have 3D geometries
and you didn't know they are 3D and you really don't care about the Z.  I
guess it gets back to if you have a choice of building a 2D index on a 3D
geometry.
Which might be the reason why Mark wanted an explicit index creation opts
different for  2D vs. 3D.

Given everything people have said, would seem preferable to make this
decision at runtime rather than at index build.