Hi,
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 > Thanks for your question ahd the link to the paper. Very interesting. I had various scenarios in mind but not yet this one. It should be possible, the input for the distance strategy is the point which is buffered at that moment. But I have to check. I'll come back to this. Regards, Barend _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
Hi Grzegorz,
gchlebus wrote On 28-10-2014 17:24: > Hi, > > any ideas how one could implement this anisotropic distance strategy? I gave > a bit thought to this and I think, that to make this anisotropic approach > working as described in the paper one would have also to implement a new > EndStrategy, namely, an elliptic one. Sure! You asked this 4 days before and I answered you: > Thanks for your question ahd the link to the paper. Very interesting. > I had various scenarios in mind but not yet this one. It should be > possible, the input for the distance strategy is the point which is > buffered at that moment. But I have to check. I'll come back to this. So I'll come back to this ;-) It is possible. I was writing example-code for this question, you will get the answer tomorrow. Yes, you will need indeed other strategies than distance too. Regards, Barend _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
In reply to this post by Barend
Hi Grzegorz,
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. 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. Regards, Barend _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry buffer_point_circle.cpp (6K) Download Attachment bufferpol.svg (10K) Download Attachment buffer.svg (16K) Download Attachment |
Hi Grzegorz,
gchlebus wrote On 31-10-2014 18:13:
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 _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
Hi Grzegorz,
gchlebus wrote On 6-11-2014 19:08:
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 _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
Gu Grzegorz,
gchlebus wrote On 8-11-2014 2:33:
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 _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
Hi Grzegorz,
gchlebus wrote On 12-11-2014 21:52:
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 _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
Hi Grzegorz,
gchlebus wrote On 13-11-2014 18:39:
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 _______________________________________________ Geometry mailing list [hidden email] http://lists.boost.org/mailman/listinfo.cgi/geometry |
Free forum by Nabble | Edit this page |