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

Subject: Re: [geometry] [Boost-users] [boost.geometry] buffer distance strategies
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-11-04 11:27:33

Hi Grzegorz,

>
> 2014-10-29 23:18 GMT+01:00 Barend Gehrels [via Boost] <[hidden email] 
> </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