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@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel@geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
