Geometry Boost List: Re: [geometry] Bug in boost geometry 1.48: union of 2 polygons is wrong.

Subject: Re: [geometry] Bug in boost geometry 1.48: union of 2 polygons is wrong.
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-01-28 14:04:10

Hi Zachary,

On 16-1-2012 0:55, Zachary Deretsky wrote:
> Since at Aditazz we chose to utilize boost geometry it will be very 
> useful for us to know, which operations are guaranteed to be safe for 
> which objects with integer coordinates with abs values less than 2^30.

The sample you sent on this list calculating a union based on polygons 
with large integer coordinates is running correctly now.

This is the result of my action to inventarize unsafe (w.r.t. large 
integers) actions. I've updated:
- area, the area-result-type is a double (even for integer coordinates), 
and was assigned to a double, but coordinates were not casted. This is 
now corrected using the cross-product which at one place verifies this
- (side: was already promoted, but uses cross-product now)
- centroid, same
- segment-intersection (three sources), now also using cross-product
- correct, which is using area, but the internal predicate was not using 
area-result-type but coordinate_type. This took me a while. But fixed 
now (correct was not in your sample but I usually add it for my own tests).

This makes the sample run. I've added large_integer tests to 
area/centroid (committed) and within (still to commit).

The plan was to integrate cross_product (was in extensions) anyway, so 
this was a good moment to do this. I realize that it is not only 
inventarizing but also correcting, but this was the easiest way. It is 
sometimes not clear why it is not running (as in the case for "correct" 
above), so if there is a solution, I apply it.

This makes most algorithms run for large integers, but I've still to 
check several.

So this is a great enhancement, thanks again for your report.

Note that it is not yet in 1.49, too late. Boost's trunk contains the 
new code.

Regards, Barend