David, Michael:
One thing to know about the current implementation of spatial predicates
in JTS is that in the general case they all take about the same time to
run. This is because "under the covers" they all use relate, which
performs a full topological evaluation of the input geometries. So
although it might seem that different predicates would run faster that
others, this isn't in fact the case.
This is one of the reasons that JTS 1.9 is providing PreparedGeometry,
along with some optimized predicates. This new implementation is much
more careful about doing the minimal amount of work required to evaluate
predicates.
Martin Davis wrote:
b, c, and d should all have the same performance. a will probably be
twice as slow (due to two calls to predicates)
Be careful about the precise semantics of the predicates. (c) is not
equivalent to (d) (for instance, a polygon which is wholely contained
in another will have c = false but d = true
Jody Garnett wrote:
Here is a skill testing question for the jts-devel list. I think all
of the following alternatives perform the same test .. what do you
think would perform faster?
a) return geometry.disjoint( geometry2 ) || geometry.touches(
geometry2 )
b) IntersectionMatrix matrix = geometry.relate( geometry2 );
return matrix.isDisjoint() || matrix.isTouches();
c) return geometry.relate( geometry2, "F********" )
d) return !geometry.overlaps( geometry2 )
I will write a test harness for this; but the discussion may be
interesting.
Jody
_______________________________________________
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022
_______________________________________________
jts-devel mailing list
jts-devel@lists.jump-project.org
http://lists.refractions.net/mailman/listinfo/jts-devel
