Re: [Boost-users] [boost.geometry] buffer distance strategies

Subject: Re: [Boost-users] [boost.geometry] buffer distance strategies
From: gchlebus (gchlebus_at_[hidden])
Date: 2014-11-06 13:08:37

2014-11-04 17:23 GMT+01:00 Barend Gehrels [via Boost] <
ml-node+s2283326n4668721h78_at_[hidden]>:

> Hi Grzegorz,
>
>
>
> 2014-10-29 23:18 GMT+01:00 Barend Gehrels [via Boost] <[hidden email]
> <http://user/SendEmail.jtp?type=node&node=4668617&i=0>>:
>
>>
>>
>> gchlebus wrote On 24-10-2014 16:44:
>>
>> > Hi,
>> >
>> > I am wondering whether it would be possible to achieve anisotropic
>> buffering
>> > (distances in neg x, pos x, neg y, pos y can have different values) of
>> a
>> > polygon using the buffer function with custom-implemented distance
>> strategy.
>> > What I want to achieve is presented on the figure 2-b in the following
>> > paper:
>> >
>> http://itcnt05.itc.nl/agile_old/Conference/mallorca2002/proceedings/posters/p_molina.pdf
>> >
>> > I would be grateful to hear from you whether it is doable, and if
>> positive,
>> > how one could implement such a custom distance strategy.
>>  The current distance strategy has (currently) no means to get the angle,
>> or a vector of the new point to be buffered. We can consider adding that.
>>
>> However, by writing custom strategies for join, side, point (for
>> point-buffers) and possibly end (for line-buffers) you should be able to
>> create this, because these have this information.
>>
>> Attached a program doing similar things with polygons and points (I vary
>> the distance based on angle - you will have to do something with your
>> anistropic model).
>>
>> The output is also attached.
>>
>> The program defines three custom strategies, all based on the same
>> mechanism, to create interesting output.
>> I did not do the end-strategy but that would look similar, you can look
>> at the provided end-strategy (round) and apply the same function.
>>
>
>
> gchlebus wrote On 31-10-2014 18:13:
>
> I really appreciate your example code, it helped me a lot. Attached you
> can find my source code.
> In my implementation of the anisotropic buffering I didn't know how to
> make use of the distance strategy, as it was possible to make it work using
> only side and join strategies.
> I encountered strange behavior when changing number of points describing a
> full circle. Using 360 points produced a good output, whereas 90 points
> caused only the second polygon to be buffered (see attached figures). I
> would be thankful if you could help me to resolve this issue as well as for
> any remarks to my code.
>
>
> I could reproduce this. Basically the join-strategy should always include
> points perp1 and perp2 (these are the two points perpendicular to the two
> sides which the join-strategy joints). Either they are re-calculated, or
> they can be just added to begin and end. So I did the last option, and that
> piece of code now looks like:
>
>       double const angle_increment = 2.0 * M_PI / double(point_count);
>       double alpha = angle1 - angle_increment;
> *      range_out.push_back(perp1);*
> * // added *      for (int i = 0; alpha >= angle2 && i < point_count;
> i++, alpha -= angle_increment)
>       {
>         pdd v = getPointOnEllipse(alpha);
>         Point p;
>         bg::set<0>(p, bg::get<0>(vertex) + v.first);
>         bg::set<1>(p, bg::get<1>(vertex) + v.second);
>         range_out.push_back(p);
>       }
> *      range_out.push_back(perp2);** // added*
>
> My sample code of course also suffered from that, so I added it there too
> if I use it in the future.
>
> I tested your algorithm with various points and distances and it now seems
> always OK.
>
> You ask for remarks on your code: it looks good ;-) one thing, many terms
> are recalculated such as pow(xPos*tan(alpha), 2)); or just tan(alpha), I
> usually store these into variables, to avoid expensive recalculations of
> the same terms, though maybe they are optimized by the compiler.
>
> Regards, Barend
>
>
> P.S. this list discourages top-postings
>
>
Hallo Barend,

I corrected the join strategy, but still the buffering doesn't work in all
cases as expected. When using xPos = 1, and other values equal 0, the
buffered polygon contains a hole (see xPos1.svg), whereas setting xPos to 2
produces a correct result (xPos2.svg). Do you know how to fix it? I
attached also main.cpp, as I changed the code a bit and it contains the
polygon for which causes the strange behavior.

Regards,
Grzegorz

main.cpp (13K) <http://boost.2283326.n4.nabble.com/attachment/4668774/0/main.cpp>
xPos1.svg (1K) <http://boost.2283326.n4.nabble.com/attachment/4668774/1/xPos1.svg>
xPos2.svg (1K) <http://boost.2283326.n4.nabble.com/attachment/4668774/2/xPos2.svg>

--
View this message in context: http://boost.2283326.n4.nabble.com/boost-geometry-buffer-distance-strategies-tp4668469p4668774.html
Sent from the Boost - Users mailing list archive at Nabble.com.