<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 4:49 AM Darafei "Komяpa" Praliaskouski <<a href="mailto:me@komzpa.net">me@komzpa.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 12:05 AM Martin Davis <<a href="mailto:mtnclimb@gmail.com" target="_blank">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br></div></blockquote><div><br></div><div>Can you share one?</div></div></div></blockquote><div> </div><div>There's one in GeoTools: <a href="https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/geometry/jts/GeometryClipper.java">https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/geometry/jts/GeometryClipper.java</a> </div><div>But I see comments that indicate it may not produce valid geometry either, just something good enough for rendering.  But the basic approach (Cohen-Sutherland / Liang-Barsky) might be possible to make valid.  <br></div><div>There's a JTS-adapted port here, so you can try it in TestBuilder:  <a href="https://github.com/dr-jts/jts-ports">https://github.com/dr-jts/jts-ports</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>May it happen that snap-rounding for axis aligned overlaps is more trivial than one for generic overlap?</div></div></div></blockquote><div><br></div><div>Maybe... although snap-rounding in theory is a global operation that needs to be applied to the entire line arrangement, to ensure that no lines result in further intersections after adjustment.  But as per previous comment, maybe it's possible to restrict it to just the rectangle area. That won't make it more "trivial", however, since a geometry can be highly complex inside the rectangle.  It should be faster though.</div><div> </div></div></div></div>