Geometry Boost List: Re: [geometry] Expectation for robustness and rescale policy

Subject: Re: [geometry] Expectation for robustness and rescale policy
From: Barend Gehrels (barend_at_[hidden])
Date: 2016-08-10 05:13:01

Hi Max,

Op 2-8-2016 om 20:34 schreef Martinez, Max:
>
> 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)?
>

Sorry for the delayed reaction. The rescaling was introduced to solve 
several overlay cases which were failing because of robustness issues. 
During that, several refactorings have been applied. Besides rescaling, 
the overall robustness issues also reduced.

Currently we have the rescaling still enabled, and now on its turn this 
gives some failures which are hard to fix. Therefore we are working to 
remove this again and fix the remaining issues in a different way.

So you can indeed set the BOOST_GEOMETRY_NO_ROBUSTNESS define to run the 
algorithms without rescaling, and in a future version (but it will not 
be 1.62) the need of the flag is gone.

Thanks also for the testcase.

Regards, Barend