Skip to content

Conversation

@arriopolis
Copy link
Contributor

This PR adds a spatial filter to the polygonbuilder that is part of overlayng. This was already suggested in a comment present in the previous version.

I did some performance measurements too, to see how much time it saves. For the tests, I computed the difference between two MultiPolygons, one being a region and the other being lakes and rivers inside that region, both taken from OpenStreetMaps. Here are the performance results:

Region Old time (ms) New time (ms) Data set
Zuid-Holland 194 189 zuid-holland.zip
Netherlands 902 903 netherlands.zip
Spain 1286 1168 spain.zip
Germany 2774 2163 germany.zip
France 4489 3322 *

*The data set for France is too big to upload, it's available upon request.

For the measurements, I took the average of five runs. I also checked that the areas of the resulting shapes match exactly in both runs.

Signed-off-by: arriopolis <arjan_rekenmachine@hotmail.com>
@dr-jts dr-jts changed the title Added a spatial index to the overlayng polygon builder. Added spatial index to the OverlayNG PolygonBuilder Jan 12, 2026
@dr-jts dr-jts changed the title Added spatial index to the OverlayNG PolygonBuilder Added spatial index to OverlayNG PolygonBuilder.placeFreeHoles Jan 12, 2026
@dr-jts
Copy link
Contributor

dr-jts commented Jan 12, 2026

Looks like a good improvement. Is there a particular reason you chose to use HPRTree - e.g. performance or memory usage? (It does seem like a good choice - just curious if you compared it to say STRtree).

@arriopolis
Copy link
Contributor Author

arriopolis commented Jan 13, 2026

Thanks!

I did think a bit about which one to use, and I found that there was not much of a difference timing-wise.
My hunch is that with this improvement, this part of the computation becomes only a very small fraction of the total runtime of the multipolygon difference operation that I was testing it on, so it makes sense I couldn't tell them apart from the timing results.
Then I found these two lines in the HPRtree.java which eventually made me decide to go with HPRtree:

* NOTE: Based on performance testing, 
* the HPRtree is somewhat faster than the STRtree.

I have no further experience with either, so I guess from my perspective I have no logical argument to favor the one over the other.

@dr-jts
Copy link
Contributor

dr-jts commented Jan 16, 2026

Yes, I'm pretty sure HPRtree is more space efficient than STRtree, and has comparable performance. It should also be a good choice for very small index sizes (in this case it skips the sort step, and uses simple linear search).

@dr-jts dr-jts merged commit c874270 into locationtech:master Jan 16, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants