<div dir="ltr">I've also had some thoughts about being able to "prepare" geometries for overlay.  At least for intersection and difference - it's less clear that there is much of a use case for union and symdifference.<div><br></div><div>At the theoretical level certainly the self-noding could be cached, and probably a reduction to a set of edges (Monotone Chains) as well. </div><div><br></div><div>This will require fairly major surgery to the codebase, however.   Ideally the relate code can be split out (and hopefully reworked entirely), to reduce the complexity.  There's also snap-rounding lurking in the background...  </div><div>   </div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 1, 2018 at 8:15 AM Paul van der Linden <<a href="mailto:paul.doskabouter@gmail.com">paul.doskabouter@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">Ok, you're right. This was just a random example I used to see if I can spot some improvements and get a bit of a feel about the algorithms used.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Ultimately I'm trying to figure out if the overlay-ops (especially intersection and union) can be reworked to use prepared geometries, but will make sure any tests I do involve real-world polygons<br></div></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a></blockquote></div>