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