[postgis-devel] Death to Pointless Operators

[Paragon Corporation]

>> Is it really a lot of effort to keep those.  Sadly we have some 
>> examples in our book that use those and I can't change those chapters 
>> since they've already gone to final proofing.

> It's not zero effort, I have to write new functions for them all. And I
have never used them in all my years of PostGIS'ing.

I don't think they are useful for GIS work.  I was thinking along the lines
of asset management where you have floor plans and room plans that are
organized in aisles, rows etc.
And the space you are allocating are pretty much boxed areas.  Then in those
cases I think those operators become useful.

If it’s a lot of work for you I suppose we can add them back later in 2.1 if
the need arises.

>> We have on occasion found them useful when we only care about box 
>> checks really fudge factors like basic position of objects relative to 
>> another for say an inventory app.

> You've used overleft and overright? Really? I means, yes, overlaps,
contains, within. But below? Above?
Yes but not recently.   Though for one of the projects we are working on
which isan't really a GIS project -- more asset management, we can forsee
using them.  We can work around it I'm sure.


>> If you get rid of anything you should really get rid of that ~ -- its 
>> just confusing because it means something completely different as 
>> Nicklas mentioned a while ago (when you are talking about the built-in 
>> polygon/point and I think even pgsphere --

> ~ is the opposite of @. But it can be any symbol we like. How about !@ ?

> ~ means true geometric equality.

> Does it? And what means box equality?
Hmm it looks like they deprecated the ~ operator in PostgreSQL 8.2 -- how
did I miss that.
http://www.postgresql.org/docs/8.4/interactive/functions-geometry.html

And they used ti to mean contains 

 ~= means sames as.
http://www.postgresql.org/docs/8.1/interactive/functions-geometry.html  

Well doesn't matter I guess.  Why can't we just overload the = sign like
ltree does?  http://www.postgresql.org/docs/current/interactive/ltree.html  
Then in group by the = will use the btree operator and in WHERE it will use
the faster gist  index which is kind of what people are expecting naturally
anyway.


> I say we keep these -- and BTW all those duplicated functions that 
> cause code bloat that don't start with ST_ -- put them in a legacy.sql 
> script that doesn't get installed by default in PostGIS 2.0.

> That's book-keeping stuff, not going to happen until the underlying things
work. And I'm sure people will hate me if I do it. So maybe you should do
it? :)
I'm prepared to be hated.  Okay I'll do that.