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

[Chris Hodgson]

With all due respect I think you need to read the spec again. Below is a 
very nice example from a fairly reliable source that I believe clearly 
indicates that:

A.equals(B) -> A.contains(B), A.within(B)

Or simply that it is always the case that:

A.contains(A) and A.within(A)

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/opt/csbp4181.htm

Basically, neither within() nor contains() care about whether the 
boundaries of the geometries touch. Equals IS effectively redundant as 
you suggest, and that is perfectly reasonable as about half of the 
functions are "redundant" in the same way:

A.intersects(B) <=> !A.disjoint(B)
A.contains(B) <=> B.within(A)
etc.

I would imagine they are just there for completeness and clarity.

Regards,
Chris

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