Geometry Boost List: Re: [geometry] "Overlay invalid input exception" (fixed)

Subject: Re: [geometry] "Overlay invalid input exception" (fixed)
From: Barend Gehrels (barend_at_[hidden])
Date: 2012-07-17 14:21:39

Hi Volker,

On 17-7-2012 16:17, Volker Schöch wrote:
>
> 1. I tried working around the issue in 1.48.0 by converting int-based 
> polygons to double-based polygons, calling 
> boost::geometry::difference, and converting the result back to int. 
> The "Overlay invalid input exception" was still thrown even for 
> double-based polygons. The cause might have been in the rounding that 
> was required to convert double-polygons to int-polygons, but whatever 
> it was, I'm afraid there is no workaround that "just works" for all 
> cases. I agree that 1.48.0 is obsolete anyway, but we'll have to make 
> it work somehow because we cannot currently upgrade to 1.50.0 (for 
> reasons outside geometry).
>

Yes, rounding might indeed cause invalid input. Depending on the 
configuration of course. If your integer input intersects somewhere in 
the non-integer grid, the intersection point will (of course) be rounded 
in some of the 4 cornering points (in fact it will be truncated, so 
select lowerleft). If that (often) occurs, invalid output will not 
really surprise me.

Having said that, this might also cause errors without going to double 
and back. During the process coordinates are rounded too.

> 2. I tried 1.50.0 and applied your patch. The step where it previously 
> failed in 1.50.0 did work after the patch was applied, but the step 
> that originally failed in 1.48.0 still fails in 1.50.0 with your 
> patch. Please find three reproductions below that all fail with 
> "Overlay invalid input exception" in the last step, with 1.50.0, with 
> your patch applied. The definitions of the operators can be found 
> below the reproductions.
>

OK that is surprising. I used your (previous) input and it did not fail, 
both for 1.50 and for 1.51. Just re-checked this. But of course I 
believe your observations. I will check your other reproductions too.

> As always, my polygon type is oriented *counter-clockwise* and *not 
> closed*, my point type is based on *int*.
>

That is what I'm using in my test-program for your tickets...

Regards, Barend