[geos-devel] Binary Predicate Bug - Even Worse!

Paul Ramsey pramsey at refractions.net
Tue Jun 12 13:17:58 EDT 2007


Perhaps we are talking at cross purposes here. The definition of 
Within() on page 2-27 of SFSQL 1.1 seems to imply to me that A.Within(A) 
is TRUE. So A.Contains(A) is also TRUE.

And I agree, if that is the case, then Equals() would be redundant, 
since the only way A.Contains(B) and A.Within(B) is if A.Equals(B).

I only used "Intersection()" because I couldn't type in the 
upside-down-U set intersection symbol that appears in the manual.

Do you feel page 2-27 means something else?

Best regards,


Todd Jellett wrote:
> Read the post Paul. I very aware of what the spec is and says.
> Note that nowhere do I talk about Intersection(A,B). I'm talking about 
> the inverse of disjoint(), intersects(), the Binary Predicate.
> A.equals(B) = TRUE implies that A.intersects(B) = TRUE  A.touches(B) = 
> TRUE implies that A.intersects(B) = TRUE
> A.contains(B) = TRUE implies that A.intersects(B) = TRUE
> A.within(B) = TRUE implies that A.intersects(B) = TRUE
> A.overlaps(B) = TRUE implies that A.intersects(B) = TRUE
> on the other hand this *does not* work the same way for contains/within
> A.equals(B) = TRUE *does not imply* that A.within(B) = TRUE  
> A.touches(B) = TRUE *does not imply* that A.within(B) = TRUE
> A.contains(B) = TRUE *does not imply* that A.within(B) = TRUE
> A.disjoint(B) = TRUE *does not imply* that A.within(B) = TRUE
> So I excluded the binary predicate intersects() to simplify my example 
> (which you seem to have missed altogether).
> My example has a simple 1-ring 5-point polygon that is a square. When 
> this geometry is tested against itself by calling each of the binary 
> predicates in turn, I observe that A.equals(B) = TRUE, A.contains(B) = 
> TRUE *and* A.within(B) = TRUE. This is what I am questioning the 
> validity of.
> Nowhere, absolutely nowhere in the OGC SFSQL does it say that a single 
> geometry (any two geometries for that matter) can be equal to each 
> other, and at the same time have A be contained in itself (or another 
> geometry B) *and* have A within itself (or another geometry B).
> If this is how it is supposed to be then the equals() predicate is 
> redundant and could be eliminated. (equal = contains && within).
> Todd
> Paul Ramsey wrote:
>> The OGC SFSQL document says that
>> A.Within(B) implies Insersection(A,B) == A
>> And Contains is just defined for commutative purposes against Within():
>> A.Within(B) implies B.Contains(A).
>> So, you might not like the semantics, but they are implemented as 
>> defined by the standards body.
>> Paul
>> Todd Jellett wrote:
>>> It turns out that this is also the case for identical geometries!
>>> If you take just GeomA and run all the listed binary predicates 
>>> (below) against itself, you get exactly the same as below.
>>> Running GeomA->GeomA I get:
>>> Disjoint    False
>>> Equal       True
>>> Touch      False
>>> Contain    True
>>> Within      True
>>> Overlap    False
>>> Running a simple geometry against itself should return True for 
>>> Equals *only*. It is ambiguous to be also contained and within.
>>> Todd
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel


   Paul Ramsey
   Refractions Research
   pramsey at refractions.net
   Phone: 250-383-3022
   Cell: 250-885-0632

More information about the geos-devel mailing list