
Geometry : 
Subject: Re: [geometry] Bug in boost geometry 1.48: union of 2 polygons is wrong.
From: Barend Gehrels (barend_at_[hidden])
Date: 20120128 14:04:10
Hi Zachary,
On 1612012 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 arearesulttype is a double (even for integer coordinates),
and was assigned to a double, but coordinates were not casted. This is
now corrected using the crossproduct which at one place verifies this
 (side: was already promoted, but uses crossproduct now)
 centroid, same
 segmentintersection (three sources), now also using crossproduct
 correct, which is using area, but the internal predicate was not using
arearesulttype 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
Geometry list run by mateusz at loskot.net