A recent upgrade from boost 1.55 to 1.61 resulted in a number of unit test failures in our development environment related to the robustness polices in boost geometry (specifically the rescale policy in the context of intersection) that seem to now be applied by default. The failures go away (previous behavior is restored) if we set BOOST_GEOMETRY_NO_ROBUSTNESS, but we were wondering what our expectations should be with respect to robustness (there doesn’t seem to be any documentation on it). I’m not a COGO expert so after googling around a bit my impression is that a robust algorithm is one that behaves correctly (and fast) even for “degenerate” cases.

 

The failures are related to floating point differences but one that was surprising to us was that intersections generated on horizontal (and vertical?) line segments did not result in points that had the exact y (x) value as the points representing the line segment intersected.

 

The example below illustrates this. It is a test that has been massaged a bit so that it can be examined outside our environment. It passes if the coordinate type is float, but not if it is double (which our adaptation is based upon). I understand that the results will be slightly different due to the scaling to integer and back to double, but is it expected that the horizontal line intersection, which can easily (and will) be inspected by the geospatial end user, might not have a y value that matches the horizontal line (value ends up as 3647747.9999977136)? Is this also possible if robustness is disabled (i.e., were/are we just getting lucky with this set of values)?