[postgis-devel] Death to Pointless Operators

[Paul Ramsey]

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