[postgis-devel] VOTE: Should EMPTY be spatially equal to self ?

[Chris Hodgson]

I actually think that true is more practical for the join case - if 
you're joining possibly empty geometries on equals(), what else could 
you mean? Use NULLs if you want the NULL behaviour. Also for me 
personally, I'm marginally happier to have compatibility with Oracle 
than with MSSQL.

I'll stick my neck out with a +1.

Chris


On 12-01-19 11:12 AM, Paul Ramsey wrote:
> I'm +0 on anything at all, I don't think it matters in a day-to-day
> way, and it seems that on the one hand Oracle say true and the other
> MSSQL says false, so we don't even have any kind of consensus to hew
> to. I think false is more practical (for the join case) and true is
> more conceptually clean (since A == A almost all the time).
>
> P.
>
> On Thu, Jan 19, 2012 at 7:26 AM, Sandro Santilli<strk at keybit.net>  wrote:
>> On Thu, Jan 19, 2012 at 07:43:56AM -0500, Paragon Corporation wrote:
>>>> Pretty much. Internally, the predicates do use DE9IM, except
>>>> for some optimizations implemented _before_ computing the
>>>> whole intersection matrix. Optimizations currently include
>>>> bounding box comparosons.
>>>>
>>>>> FFF.FFF.FF2 is a sensible DE9IM matrix for empty - empty in set
>>>>> theoretical terms, but does it make sense to apply it for spatial
>>>>> predicates?  Many say yes, some say no.
>>>> I don't think anyone is suggesting NOT to use the matrix in
>>>> spatial predicates. I think what I'm suggesting to change the
>>>> definition of ST_Equals in matrix terms, or to introduce an
>>>> explicit corner case for the EMPTY case.
>>>>
>>>> --strk;
>>>>
>>> I had one of my Oracle firends test and his response.
>>> "This is what Oracle has:
>>>
>>>   SELECT
>>> ST_Geometry.ST_Point(0,0,NULL).ST_Equals(ST_Geometry.ST_Point(0,0,NULL)) as
>>> testequals
>>>     FROM dual;
>>>
>>> TESTEQUALS
>>> ----------
>>> 1
>>>
>>> That is, TRUE. as it should be."
>>>
>>> At this point I don't really care strk.  I'm tired of arguing about it.  So
>>> I will vote:
>>>
>>> 0-
>>>
>>>
>>> I'm still not clear the benefit of changing and would rather not bother if
>>> there is no benefit.
>> We'll need a change anyway, or we'll have _st_equals return true
>> and st_equals return false. I'd be consistent on the TRUE answer
>> for having the advantage of any gemetry being equal to self.
>>
>> Internally this will mean switching ST_Equals from use of&&  to use
>> of =~ (now that =~ is fixed to use the index).
>>
>> My vote for this change is +1.
>>
>> I'd also like =~ to get back into the manual page, the version
>> that was removed by r8799.
>>
>> --strk;
>>
>>   ()   Free GIS&  Flash consultant/developer
>>   /\   http://strk.keybit.net/services.html
>> _______________________________________________
>> 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