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 lon
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
encoun
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 spatia
Tuure Laurinolli wrote:
>
>Dorrington, Albert wrote:
>
>> Initially our code was rather inefficient, considering that once the
>> list of polygons is defined, it does not change for the duration of
>> our search.
>
>You might want to construct a geometry index that can be used to speed
up poin
Dorrington, Albert wrote:
Initially our code was rather inefficient, considering that once the
list of polygons is defined, it does not change for the duration
of our search.
You might want to construct a geometry index that can be used to speed
up point-in-polygon tests. JTS has R-trees and
Hello everyone,
I am involved with a project that is using the JTS package (currently
1.8) to implement some path finding algorithms.
As currently implemented, we have several layers, each of which contains
a List of Polygon objects. Our search algorithm
looks to see if our current location (a
