Geometry Boost List: [ggl] Difference / xor for multi polygons

Subject: [ggl] Difference / xor for multi polygons
From: Javier Gonzalez (xaviergonz)
Date: 2011-03-06 22:23:55

Oh, before I forget, sometimes I'm getting a lot (and I mean a lot, like
313) polygons that are just single points (polygons like 123 123, 123 123)
in the result vs 7 real (3 or more points) polygons.
Right now I'm just filtering them out, is that normal?

It usually happens while making unions of "tiles", this is, rectangles of
40x40 (for example) units, like

rect from 0,0 to 40, 40 + rect from 40, 0 to 80, 40 + rect from 0,40 to
40,80 etc and the like (I'm not implying it happens for that particular case
however, didn't try)
Probably you might want to make an automated test for that...

On Mon, Mar 7, 2011 at 4:15 AM, Javier Gonzalez <xaviergonz_at_[hidden]>wrote:

> Nice! that change actually solved some artifacts I was getting (compared to
> the clipper and GPC versions).
>
> Unfortunately, here's another faulty case
>
> UNION of:
>
> POLYGON((-2 2, 1842 2, 1842 -2362, -2 -2362, -2 2), (0 0, 0 -2360, 1840
> -2360, 1840 0, 0 0))
>
> with:
>
> POLYGON((-0.01 -1960, 0 -1960, 0 -1880, 80.01 -1960, -0.01 -1960))
>
>
> gives
> POLYGON((-2 2, 1842 2, 1842 -2362, -2 -2362, -2 2))
>
>
> should give (at least using clipper)
> POLYGON((-1.999999 -2362, -1.999999 1.999999, 1842 1.999999, 1842 -2362,
> -1.999999 -2362), (0 -2360, 1840 -2360, 1840 0, 0 0, 0 -1880, 80.01 -1960, 0
> -1960, 0 -2360))
>
>
> On Sun, Mar 6, 2011 at 10:35 PM, Barend Gehrels <barend_at_[hidden]> wrote:
>
>> Hi Javier,
>>
>> OK, should be solved now. A little complex to explain, but it was a
>> robustness problem in coordinate intersection, by which a wrong intersection
>> point was generated. I didn't touch that file for a long time so I'm glad
>> this is solved now - I've to study it for possibly similar cases. Your case
>> is added to the testsuite to prevent happening again, thanks for it.
>>
>> So what I told earlier is wrong, for float it was OK because not exactly
>> triggered by the problem above, for ttmath these kind of things should not
>> occur, and for double this one is solved now.
>>
>> Hoping you can continue now, but in case of more problems, reports are
>> welcome, I appreciate your tests.
>>
>> Regards, Barend
>>
>>
>>
>>
>> On 6-3-2011 18:17, Barend Gehrels wrote:
>>
>>> Hi Javier,
>>>
>>> Right, now I get the same. The error occurs only for double. For float it
>>> is OK (but that is by chance), for ttmath it is also OK (that is as
>>> intended). The differences in coordinates are so small that for double they
>>> probably cannot be represented, but this is my preliminary conclusion. I
>>> will check if I can get extra information, and if there are even possible
>>> solutions. This can take me a while.
>>>
>>> For checking coordinates like this, I would advice to use ttmath.
>>>
>>> Interesting tests.
>>>
>>> Regards, Barend
>>>
>>>
>>>
>>
>> --
>> Barend Gehrels
>> http://about.me/barendgehrels
>>
>> _______________________________________________
>> ggl mailing list
>> ggl_at_[hidden]
>> http://lists.osgeo.org/mailman/listinfo/ggl
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20110307/05453467/attachment-0001.html