Open ebocher opened 7 months ago
Thanks for this. The good news is that the upcoming RelateNG algorithm handles this correctly. I'll add it to the list of robustness issues to fix.
Here another example that returns a side conflict location. Tested with the current 1.20-SNAPSHOT
Geometry gc0 = reader.read(
"POLYGON ((474007.37387468846 5286568.023144805, 474027.7175788997 5286573.266943434, 474028.8194209462 5286568.149451445, 474027.0178892645 5286567.712940417, 474027.8267687816 5286564.1527563, 474029.55282332335 5286564.478462566, 474030.58366500423 5286560.250429942, 474021.5764896469 5286558.179018065, 474020.5456541259 5286562.4070523, 474021.74684248475 5286562.7351050675, 474020.4930542351 5286567.408707694, 474016.51508399716 5286566.537369314, 474016.1461484541 5286567.872732597, 474014.1946537856 5286567.436896746, 474014.1166879452 5286566.770389721, 474009.1619732661 5286565.458857827, 474007.37387468846 5286568.023144805))");
Geometry gc1 = reader.read(
"POLYGON ((473936.1801007541 5286478.294544354, 473993.2799454166 5286568.641978126, 474007.3738746885 5286568.023144805, 473936.1801007541 5286478.294544354))");
assertTrue(gc0.intersects(gc1));
Here another example that returns a side conflict location. Tested with the current 1.20-SNAPSHOT
Works with RelateNG (up to a point - there is still a robustness issue, but it's not a failure. Thinking about what to do about this).
Note that RelateNG is not wired in to replace the old Relate code yet - that will happen in the next release.
JTS 1.20 is out. Thanks a lot !
Do we need to replace
assertTrue(gc0.intersects(gc1));
by
assertTrue(RelateNG.relate(gc0, gc1, RelatePredicate.intersects()))
You can do that. Or you can set the -Djts.relate=ng
system property, which will use RelateNG for the Geometry
topological predicates.
Dear Dr, the following test case returns a side location conflict
Reported on https://github.com/orbisgis/geoclimate/issues/947
Best regards