<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Well for the union I meant the unary union. didn't do a deep research on possible improvements in that part.</div><div class="gmail_default" style="font-size:small">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).</div><div class="gmail_default" style="font-size:small">For reference: the forest is fully inside the selection<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The selection is going through the computeIntersections really fast, <br></div><div class="gmail_default" style="font-size:small">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),</div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I also noticed that in <a href="https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/algorithm/locate/SimplePointInAreaLocator.cpp#L49">https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/algorithm/locate/SimplePointInAreaLocator.cpp#L49</a> and/or <a href="https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/algorithm/locate/SimplePointInAreaLocator.cpp#L72">https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/algorithm/locate/SimplePointInAreaLocator.cpp#L72</a> there's no envelope-check done</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Another thing: as that pointinpolygon is going to be called from <a href="https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/geomgraph/EdgeEndStar.cpp#L165">https://github.com/libgeos/geos/blob/8bc1ea0f8019bcb83c60126e7883ae428ea7c677/src/geomgraph/EdgeEndStar.cpp#L165</a> and findEdgeRingContaining quite a number of times, perhaps its possible to prepare the lot and use a IndexedPointInAreaLocator?<br></div><div class="gmail_default" style="font-size:small"><br></div></div></div></div></div></div></div></div></div></div>