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

Subject: Re: [Boost-users] [boost.geometry] buffer distance strategies
From: Barend Gehrels (barend_at_[hidden])
Date: 2014-11-13 16:12:30

Hi Grzegorz,

gchlebus wrote On 13-11-2014 18:39:
> Hi Barend,
>
> 2014-11-12 22:21 GMT+01:00 Grzegorz Chlebus <[hidden email] 
> </user/SendEmail.jtp?type=node&node=4669068&i=0>>:
>
>
>
>     2014-11-12 22:07 GMT+01:00 Barend Gehrels [via Boost] <[hidden
>     email] </user/SendEmail.jtp?type=node&node=4669068&i=1>>:
>
>         Hi Grzegorz,
>
>
>         gchlebus wrote On 12-11-2014 21:52:
>>         2014-11-08 11:53 GMT+01:00 Barend Gehrels [via Boost]
>>         <[hidden email]
>>         <http://user/SendEmail.jtp?type=node&node=4669040&i=0>>:
>>
>>             Gu Grzegorz,
>>
>>             gchlebus wrote On 8-11-2014 2:33:
>>>
>>>             2014-11-07 19:30 GMT+01:00 Barend Gehrels [via Boost]
>>>             <[hidden email]
>>>             <http://user/SendEmail.jtp?type=node&node=4668825&i=0>>:
>>>
>>>                 Hi Grzegorz,
>>>
>>>                 gchlebus wrote On 6-11-2014 19:08:
>>>>
>>>>
>>>>                 2014-11-04 17:23 GMT+01:00 Barend Gehrels [via
>>>>                 Boost] <[hidden email]
>>>>                 <http://user/SendEmail.jtp?type=node&node=4668774&i=0>>:
>>>>
>>>>
>>>>                     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.
>>>>
>>>
>>>
>>>                 That is most probably caused by an error in some of
>>>                 your calculations:
>>>
>>>                 The line y = sqrt(yPos2 * (1 - pow(x, 2) / xNeg2));
>>>                 causes a NAN for this input:
>>>
>>>                 alpha about PI
>>>                 then xNeg2 = 0.010000000000000002
>>>                 and x = -0.10000000000000002
>>>                 and yPos2 = 0.010000000000000002
>>>
>>>                 This adds a weird line containing NAN to the join,
>>>                 causing the buffer process fail.
>>>                 I got this using these parameters:
>>>                 double xPos = 1.0, xNeg = 0.1, yPos = 0.1, yNeg = 0.1;
>>>
>>>                 and not the parameters you have (that was fine for me).
>>>
>>>                 I think you should make the calculations full-proof
>>>                 first...
>>>
>>>                 For example add a line in the join-strategy:
>>>                         std::cout << i << " "<< angle1 << " " <<
>>>                 angle2 << " " << v.first << " " << v.second <<
>>>                 std::endl;
>>>
>>>
>>>                 Regards, Barend
>>>
>>>
>>>             Thanks, I'll try to improve my calculations.
>>>             By the way, I was playing with different strategies
>>>             combinations and I found out that when using only boost
>>>             buffer strategies:
>>>             double points_per_circle = 36;
>>>             double distance = 130;
>>>             bg::strategy::buffer::distance_symmetric<double>
>>>             distance_strategy(distance);
>>>             bg::strategy::buffer::end_flat end_strategy;
>>>             bg::strategy::buffer::point_circle
>>>             point_strat(points_per_circle);
>>>             bg::strategy::buffer::side_straight sideStrat;
>>>             bg::strategy::buffer::join_round
>>>             joinStrat(points_per_circle);
>>>
>>>             the buffer function can still fail (produce no output)
>>>             when the distance is higher than 128 (e.g, 128, 130,
>>>             150, 300, 400). But this happens up to a certain value,
>>>             where the buffer function starts producing a correct
>>>             output (e.g., distances 900, 1000).
>>>
>>
>>             Hmm, I see (starting at different values, but I can
>>             reproduce).
>>
>>             I created a ticket, will be looked at. Thanks for reporting.
>>             https://svn.boost.org/trac/boost/ticket/10770
>>
>>             Barend
>>
>>
>>         Hi Barend,
>>
>>         I'm glad that I could help.
>>         Anyway, I fixed the bug with NAN, but still when using (e.g.
>>         xNeg = 1, other 0) the buffer produces no output. I am really
>>         wondering, how it could work on your machine.
>>         I printed the values used by join and side strategies and
>>         they seem to be fine (no NANs or other strange values) - see
>>         attached log.txt and updated main.cpp used to produce the log
>>         file.
>>
>>         I've compiled my code using msvc 12.0 and gcc 4.8.
>
>         Which branch or version of Boost do you use?
>
>         In the meantime, I managed to fix the bug you reported, and it
>         is committed today.
>
>         Sorry for my question, but could you try it again with the
>         latest branch "develop" from github ?
>
>         Regards, Barend
>
>
>
>     Hi Barend,
>
>     sure, I downloaded the geometry lib from the develop branch, but
>     still buffer returns an empty geometry (using xNeg = 1, others 0).
>     I've ran my code also for big distances, and it works perfectly.
>     Good job!
>
>     Best,
>     Grzegorz
>
>
> I made today an interesting observation. It seems that the buffer 
> function has a problem when the extents (xNeg, xPos, yNeg, yPos) are 
> zero. Taking my last example, setting xNeg to 1 and others to 1e-3 
> makes the buffer work.

Sure - thanks for sending me, that saves me time to find it out. 
Buffer-distance 0 is not supported (yet). Some GIS packages use that to 
clean a polygon, but we have designed dissolve for that. We might 
support it later but currently, indeed, as you found out, it will not 
work. I hope small distances are OK for your application, for now.

Negative distances should work if used in the distance-policy, making 
the polygon smaller, but I don't think that it will work currently out 
of the box if you mix negative and positive distances in one 
join-strategy...

Regards, Barend