[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