optimize line string

[carrino]

Elastic search uses this method to compute it's indexes. For line strings that are very long, this method will be called once for each 50m that the line string covers (50m is the default, but basically one call to relate() for each lowest bucket level distance).

In my profiling I have identified that 100% of the time is spent in the covers case. However, a line will never cover a rectangle.

It isn't needed to accept this patch as is because I'm sure there is a better way to accomplish this perf optimization.

[codecov-io]

Current coverage is 75.43% (diff: 50.00%)

No coverage report found for master at f1683da.

Powered by Codecov. Last update f1683da...a070742

[dsmiley]

Perhaps this belong upstream in JTS? I noticed this patch referenced PreparedLineString which is a JTS thing. Curious is using Spatial4j's BufferedLineString an option?

[carrino]

Could be any line string 1-d geometry can't contain non empty 2d geometry.
I used that one because it was the most specific type.

On Nov 11, 2016 6:47 PM, "David Smiley" notifications@github.com wrote:

Perhaps this belong upstream in JTS? I noticed this patch referenced
PreparedLineString which is a JTS thing. Curious is using Spatial4j's
BufferedLineString an option?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#144 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7s23j9HQq4T-j7DEPU0_rpZjXzfQHrks5q9SiDgaJpZM4KwR5G
.

[dsmiley]

I'm closing as it was upstreamed successfully and should now be in JTS 1.15.0