A intersection between a very narrow polygon and bigger one seems to give wrong result with OverlayNGRobust

[larsop]

We startet to test more on OverlayNGRobust, but then we got this case .

Input is two geometries where one is very narrow at the border of the big polygon

The other is big a polygon

The intersection between this should have been close to the narrow polygon like this

But with latest master i get this which is way to big.

Before testing on OverlayNGRobust used our own code together with snapcode that I got you some years a go and home made code handled this case correctly.

The difference between OverlayNGRobust master and my old code is that I try resolve MultiPolygon before I start to do the intersection, then I don't get any TopoError and do not need to do any snaping.

So I added a test OverlayMiscTest#test_7_Intersection_loop where used code like this and that seems to work

     for (int i = 0; i < g2.getNumGeometries(); i++) {
          Geometry g2GeoN = g2.getGeometryN(i);
          for (int y = 0; y < g1.getNumGeometries(); y++) {
              Geometry g1GeoN = g1.getGeometryN(y);
              Geometry cleanIntersection = g1GeoN.intersection(g2GeoN);
              cleanIntersection.getGeometryType();
              newGeoList.add(cleanIntersection);
          }
      }

But the OverlayMiscTest#test_7_Intersection_OverlayNGRobust failed

With this commit the OverlayMiscTest#test_7_Intersection_OverlayNGRobust runs through.

[dr-jts]

I suspect this is a similar issue to #798. I have a fix to that issue, which consists of an additional heuristic check on the result area compared to the inputs. That will be implemented very soon.

However, in your second case this returns a result of POLYGON EMPTY, due to the triggering of more aggressive snapping. How important is having a non-empty result for you? The narrow input polygon is very small, so it seems that perhaps it's just an artifact, and doesn't matter if it's essentially discarded?

As you point out, this can be improved by intersecting each polygon element separately. But at the moment I don't want to build that in, due to complexity and performance reasons. Also it is theoretically possible that evaluating MultiPolygon elements separately produces a MultiPolygon result which is invalid (i.e. the computed polygons may actually overlap in certain rare situations). You could always build this yourself (as you have done).

[dr-jts]

@larsop is this fixed by #812?

[dr-jts]

Should be fixed. Closing.

[larsop]

Thanks , yes I tested with master now and it works perfect, sorry for the late replay.