<div dir="ltr">Right, I remember you reporting out on that experiment. <div><br></div><div>At the moment I can't think of a *simple* way to convert the "box-clamped" geometry to a valid geometry for use in Overlay.   But there might be a clever way to do this - it's an interesting question.  (One issue as you probably realize is that the clamped geometry can have a LOT of "collapsed" edges, including one which may wrap multiple times around the box, in the worst case...)  But maybe it's better just to implement a robust clipping algorithm - there's a few implementations around to use as inspiration.</div><div><br></div><div>Collapsed linework causes problems in the topology-building phase of overlay - the noding doesn't care.   I've been wrestling with this a bit recently, to try and get snap-rounding to work.  Unfortunately it's not easy.  One issue is that the GeometryGraph code is quite complex and supports both overlay and relate computation.  I think these are probably going to have to split apart, and then both can be optimized for their different usages.  </div><div><br></div><div>I'm still optimistic that limiting noding to the overlap area (i.e. the rectangle in the case of clipping) might work and be faster.  But I might be missing something key that will make this a non-starter.  </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 29, 2018 at 12:20 PM Darafei "Komяpa" Praliaskouski <<a href="mailto:me@komzpa.net">me@komzpa.net</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_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Other ideas about performance improvements are welcome.  For instance, I have had some ideas about only noding geometry in the region of actual overlap in the case of an intersection computation.  That probably has implications for robustness, however.  Needs some research...</div></div></blockquote><div><br><br>I tried to implement this speed up in PostGIS via box clipping.</div><div>Current GEOS recangle clipping is unfortunately not robust, but helps quite a lot when not crashing.<br><br>I tried redoing clipping by doing just O(N) clamping to the box. Result retains many required properties (ie, raycasting will give correct inside/outside result for it, area is okay) but has holes touching edges and edges touching themselves. GEOSIntersection can't handle that. <br><br>Is there a simple way to recover the boundary for such geometry to feed further to GEOSIntersection? Buffer(,0) does not help in many cases, ST_MakeValid too.<br><br>Can we make GEOSIntersection handle such invalid input, or is it completely incompatible with monotone chain conception?</div></div></div>-- <br><div dir="ltr" class="m_-7938485018423082135gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a></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>