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

Sandro Santilli strk at keybit.net
Thu Jan 19 07:26:30 PST 2012


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



More information about the postgis-devel mailing list