<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 16, 2020 at 11:59 AM Roger Bivand <<a href="mailto:Roger.Bivand@nhh.no">Roger.Bivand@nhh.no</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cases 794 and 936 are all-by-all intersections, and as noted in the latter <br>
issue, the problems occurring differ by input order.<br></blockquote><div><br></div><div>Well, that's disappointing that 794 and 936 still have failures.  Especially because 794 was also reported as JTS 300:</div><div><br></div><div><a href="https://github.com/locationtech/jts/issues/300">https://github.com/locationtech/jts/issues/300</a><br></div><div><br></div><div>and the test data there is incoporated in the robustness test suilte in both JTS [1] and GEOS [2] , where it passes using OverlayNG.</div><div><br></div><div>Is there any way to get a dump of the actual input geometries to GEOS which are causing these errors? </div><div><br></div><div>[1] <a href="https://github.com/locationtech/jts/blob/master/modules/tests/src/test/resources/testxml/robust/overlay/TestOverlay-jts-300.xml">https://github.com/locationtech/jts/blob/master/modules/tests/src/test/resources/testxml/robust/overlay/TestOverlay-jts-300.xml</a></div><div>[2] <a href="https://git.osgeo.org/gitea/geos/geos/src/branch/master/tests/xmltester/tests/robust/overlay/TestOverlay-jts-300.xml">https://git.osgeo.org/gitea/geos/geos/src/branch/master/tests/xmltester/tests/robust/overlay/TestOverlay-jts-300.xml</a>  </div></div></div>