[geos-devel] Possible speed improvement for overlay operations

[Paul van der Linden]

Well for the union I meant the unary union. didn't do a deep research on
possible improvements in that part.
Currently I'm investigating the intersection of some nasty (over 4000
holes) polygon (forest) with a polygon consisting of the world and a very
large (area and nr of points) hole in it (selection).
For reference: the forest is fully inside the selection

The selection is going through the computeIntersections really fast,
for the forest polygon the skipped (due to the edgeset being equal)
iterations in the processoverlap is about 10% of the total iterations (so
not much to gain there i guess),
but for the computeIntersections of the combination of those polygons the
skipped iterations are roughly equal to the total (24200775 out of
24574097), so there's room for improvement.
Don't know yet on how big of a part the computeIntersections contributes to
the total intersection-time is going to be, so that improvement could be
small after all.

I also noticed that in
https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/algorithm/locate/SimplePointInAreaLocator.cpp#L49
and/or
https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/algorithm/locate/SimplePointInAreaLocator.cpp#L72
there's no envelope-check done

Another thing: as that pointinpolygon is going to be called from
https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/geomgraph/EdgeEndStar.cpp#L165
and findEdgeRingContaining quite a number of times, perhaps its possible to
prepare the lot and use a IndexedPointInAreaLocator?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20181202/18901cfa/attachment.html>