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

[Nicklas Avén]

I want to join this discussion.
I think it is an important one.


On Fri, 2011-03-18 at 00:06 -0400, Paragon Corporation wrote:
> Paul,
> 
> Hope you are enjoying your tripping.
> 
> Regarding the 2D, 3D index.  You mentioned those have to be separate
> indexes.
> 
> 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?
> 
> My main request is that we have an &&& and the 3D index version of && just
> does a 2D check.
> 
> There are a couple of reasons for this:
> 
> 1) We agreed that all 3D relationship functions would be ST_3D...   So those
> should rightfully use a 3D interacts index (I'll call this &&&).
> 

That naming thing is one of my bad consciences... 
It will be done, some day soon I hope


> The consensus was also that the ST_Intersects etc.. Should remain as 2D
> checks.  This means that even for 3D geometries, they can't use a 3D
> interacts check.
> 
> If they did  we would have a situation where the 2D footprint of a 3D
> geometry intersects a 2D footprint of another 3D geometry, but the
> ST_Intersects returns false.  THIS IS VERY BAD.
> 
> 
> 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 fully agree here.

I have been in the situation that I wasn't even aware that I was working
with 3D data because I just had it from the shapefile and st_astext
didn't reveal the z coordinate. 

Then if I think that I do a 2D intersection I might get false negative
answers from the index if it uses a 3D index and the geoemtries are on
different altitudes. 



> So with that said -- lets say I have a building and I have 3D stuff in it.
> In order to know what stuff is in what building, I would be doing a 2D check
> -- not a 3D check.  Any 3D  object that shares the same footprint as the
> building is in the building for most cases unless its floating on top or
> under the building which is rarely the case :).
> 

Yo are right that the distance/intersects functions doesn't handle
volumes. Me and Olivier discussed this question about how to know if it
is a volume or not some time ago. As I understand it now there is a flag
in new serialized form that will tell if it is a volume. I still don't
know what the standards say. If I remember right Ilivier said that the
standard wasn't ready yet. Am I right. If it should follow 2D I mean it
have to be a separate geometry type like the distinction between
linestring and polygon. But that is not the case? 



About 2D 3D index and functions it must be most correct that the user in
all cases have to specify if they want to do the calculations with
respect to the z-value or not.

I think that we also should decide something about what we mean with 2D,
2.5D and 3D. In documetation there is now a little messy where I know
some functions is mentioned as 3D but actually just handles the
untouched z-value to the resulting geometry.

/Nicklas



> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>