[postgis-devel] Death to Pointless Operators

[Paragon Corporation]

Paul,

What's wrong with &&&.  You already have that right?  Keep it.  && for 2D,
&&& for 3D. Lets have an @@ etc.   I don't care if the index underneath is
the same as long as I can easily distiguish when I'm doing a 2D vs. 3D
check?

My point is even if you have 2 3D geometries there seemed to be a consesus
from this discussion http://trac.osgeo.org/postgis/ticket/576  that we want
ST_Intersects to always be a 2D check.  

We can't have ST_Intersects doing a 3D bbox check and a 2D true intersect
check (what happens when the 3D bounding box does not intersect but the 2D
one does).
That's kinda sorta wrong.

I don't like Mark's idea either if I understand him correctly.  

Mark,
Are you saying you want  people to define an index before hand and have the
index determine how the operation behaves?  What if there is no index? What
then.
Also the thought that ST_Intersects may return a different answer if I have
a 2D vs.  3D index in place is even more disturbing. 

Thanks,
Regina


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Tuesday, December 21, 2010 9:29 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Death to Pointless Operators



P.

On 2010-12-21, at 11:41 AM, "Paragon Corporation" <lr at pcorp.us> wrote:

> Mark,
> 
>> IMO this is the wrong approach. The correct way to do this would be 
>> to
> implement a new GiST opclass for the higher dimensions which is likely 
> based upon the contrib/cube operators and operator class. Then users 
> specify at build time what
>> dimensionality they want in the index and we can match an existing
> operator class API/behaviour for migration purposes.
> 
> Do you mean at build time of the index?  I presume you don't mean 
> build of the code?
> 
> Paul and Mark,
> 
> I'm beginning to think that perhaps we do need two sets of operators.  
> The problem is with the way you are doing it Paul -- If I understand 
> correctly is
> 
> && now becomes a 3D overlap check.  Which would be fine with me -- 
> except it makes ST_Intersects a sorta 3D check.

It is 3d if called in a 3d context... That is 3d && 3d.  It would be a 2d
check if either side is 2d.

P

Unfortunately, a new op class will mean new operators... Hello &&& and &&&&.

P

> 
> Remember I asked whether we really need a ST_3DIntersects and can't we 
> just overload  the ST_Intersects since if I have a #D geometry 
> wouldn't I want a 3D check?
> 
> I lost that battle:  As Bitner wrote in
> http://trac.osgeo.org/postgis/ticket/576
> 
> "Regina,
> 
> I prefer explicit 3D naming for functions that use the third 
> dimension. The underlying assumption right now is that all functions 
> are 2D. A lot of people just throw data into their dbs without even 
> knowing that it has a third dimension and they would be thrown quite 
> off guard if all of the sudden they started getting different results. 
> If there is a SQL/MM standard for naming, all the better.
> 
> David"
> 
> Thanks,
> Regina
> 
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel