Merging into one index *might* produce better performance - you'd have
to try it and see.
Using userData to store ancillary data (like cost) is a reasonable
approach. Alternatively, the objects that are entered into the spatial
index don't have to be Geometries - they can be any Object as long as it
can provide an Envelope for its extent. So you could store custom
Feature objects which contain a Geometry and some ancillary data.
I"m a bit surprised that PreparedGeometry isn't making any performance
difference - but it's possible that the difference is not enough to be
worth bothering about. If only a few points are being compared against
any individual polygon, the overhead of building the PreparedGeometry
would swamp any gain from caching.
Another option - don't use Geometry.intersects() for your predicate, but
use SimplePointInAreaLocator. Or, you could use
IndexedPointInAreaLocator, but this would only be worth doing if you
cached the index object (saving it either in the custom object you are
storing in the spatial index, or in an external map)
Dorrington, Albert wrote:
I needed to upgrade our jts.jar from the 1.8 version to 1.10.
I tried using the PreparedGeometry/PreparePolygon classes to see if
there was any noticable change in performance, but the numbers looked
about the same for each run.
The problem I think I'm starting to run into tho, is I am not
encountering more overhead from the profiling tool, than I am gaining
from the code optimizations, so I'm no longer getting completely
accurate timing results. For instance it takes about 45 seconds for the
routine to run while being profiles, and about 2 seconds to run
normally.
I think we may need to alter our design approach in order to gain some
more performance. From what I've been reading about the Geometry class,
I'm thinking instead of maintaining four different layers, that we could
use the Geometry's setUserData() method to store our 'cost' values for
the layer and merge all polygon's as geometry objects, into one index.
Maybe the prepared geometry approach would work better with that?
Not sure, very new to JTS at this point :)
-----Original Message-----
As you have now experienced, the biggest speedup you will find comes
from using spatial indexes.
You may also find that using PreparedGeometry helps to reduce the time
even further, since it avoids recomputing topology for the input
polygons. To do this, store a PreparedGeometry in the spatial index,
rather than the original Polygons.
Please let the list know how this works out if you try it - this is
potentially of interest to lots of people.
Martin
_______________________________________________
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
