Solid self intersection false positives

Summary

Some geometries cause the solid self-intersection check to falsely detect an error, even though the geometries do not actually contain any self-intersections.

Steps to reproduce

General steps to cause this are not available, since it is more or less random for which geometries this bug occurs.

However, geometries affected by this bug reliably reproduce it every time they are checked by the solid self-intersection check, and thus can be used for testing/debugging.

The occurence of this bug is currently suppressed by a result filter in the solid self-intersection check, which removes intersections of almost 0 length, with the exception of lines starting and ending on the exact same Coordinate3d object.
This is a stopgap. To test/debug either remove the filter, or call the intersectPolygons(...) method of IntersectPlanarPolygons (CityDoctorEdge) directly.

Testcases with examples of this bug are included in SolidSelfIntCheckTest.java and SolidSelfIntCheckFalsePositiveBigMeshTest.java found in the checks.geometry package of the CityDoctorValidation test directory.

What is the current bug behavior?

The solid self-intersection check detects self-intersection(s) in a geometry. The geometry does not actually contain any self-intersection. The PolyLine of this false positive self-intersection always has a total length of almost 0.

What is the expected correct behavior?

The solid self-intersection check should not detect any errors in these geometries.

Relevant logs and/or screenshots

N/A

Possible cause

Runtime analysis of the know examples reveal that this bug is caused by the intersectPolygons(...) method in edge.IntersectPlanarPolygons.
Specifically, the calculation of the projected intersection intervals returns intervals with an overlap width of almost 0 for the two polygons that are detected as falsely intersecting.

To summarize, it has been observed that:

• The bug is seemingly randomly occuring, yet reliably reproducable.
• The method otherwise seems to work reliably as expected.
• The bug appears to be caused by a calculation returning a minisculy wrong result.
• Some of the failing testcases in CityDoctorEdge showing similiar causes during runtime analysis.
• All values found to be slightly wrong are of the double type

These observations very strongly point towards floating point errors being the true cause of the bug.