Geometry buffer algorithm: complete or not?
I was looking here: http://www.boost.org/doc/libs/1_52_0/libs/geometry/doc/html/geometry/referen... And saw this: "The current implemetation only enlarges a box, which is not defined by OGC. A next version of the library will contain a more complete implementation" It looks like Boost::Geometry is incapable of buffering an arbitrary polygon. But various forum discussions refer to the buffer() algorithm like it actually works for the general case. Which is correct? John Lilley
Hi John, On 29-1-2013 16:35, John Lilley wrote:
I was looking here: http://www.boost.org/doc/libs/1_52_0/libs/geometry/doc/html/geometry/referen... And saw this: "The current implemetation only enlarges a box, which is not defined by OGC. A next version of the library will contain a more complete implementation"
It looks like Boost::Geometry is incapable of buffering an arbitrary polygon. But various forum discussions refer to the buffer() algorithm like it actually works for the general case. Which is correct?
The buffer() algorithm for the general case is in development, and can be used from the development version (Trunk). It generally works but not in all circumstances, and for all geometry types. Regards, Barend
Hi John, On 29-1-2013 16:35, John Lilley wrote:
I was looking here: http://www.boost.org/doc/libs/1_52_0/libs/geometry/doc/html/geometry/r eference/algorithms/buffer/buffer.html And saw this: "The current implemetation only enlarges a box, which is not defined by OGC. A next version of the library will contain a more complete implementation"
It looks like Boost::Geometry is incapable of buffering an arbitrary polygon. But various forum discussions refer to the buffer() algorithm like it actually works for the general case. Which is correct? The buffer() algorithm for the general case is in development, and can be used from the development version (Trunk). It generally works but not in all circumstances, and for all geometry types. Regards, Barend
Any idea when the trunk will go GA? Alternatively, can I combine buffer() from the trunk with the remainder of the stable Boost release and live to tell about it ? John
On 29-1-2013 23:48, John Lilley wrote:
Hi John, On 29-1-2013 16:35, John Lilley wrote:
I was looking here: http://www.boost.org/doc/libs/1_52_0/libs/geometry/doc/html/geometry/r eference/algorithms/buffer/buffer.html And saw this: "The current implemetation only enlarges a box, which is not defined by OGC. A next version of the library will contain a more complete implementation"
It looks like Boost::Geometry is incapable of buffering an arbitrary polygon. But various forum discussions refer to the buffer() algorithm like it actually works for the general case. Which is correct? The buffer() algorithm for the general case is in development, and can be used from the development version (Trunk). It generally works but not in all circumstances, and for all geometry types. Regards, Barend
Any idea when the trunk will go GA?
The Trunk always goes GA, however the extensions do not... About this extension: no, it is not yet targetted to a specific version.
Alternatively, can I combine buffer() from the trunk with the remainder of the stable Boost release and live to tell about it ?
Yes, you can just add the whole folder "boost/geometry/extensions" to the released version. It has no other dependencies. Regards, Barend
Barend, Thanks so much for the advice. Do I need to do anything to get the extensions built or installed with the regular geometry library? --john -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Barend Gehrels Sent: Wednesday, January 30, 2013 10:53 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Geometry buffer algorithm: complete or not? On 29-1-2013 23:48, John Lilley wrote:
Hi John, On 29-1-2013 16:35, John Lilley wrote:
I was looking here: http://www.boost.org/doc/libs/1_52_0/libs/geometry/doc/html/geometry/ r eference/algorithms/buffer/buffer.html And saw this: "The current implemetation only enlarges a box, which is not defined by OGC. A next version of the library will contain a more complete implementation"
It looks like Boost::Geometry is incapable of buffering an arbitrary polygon. But various forum discussions refer to the buffer() algorithm like it actually works for the general case. Which is correct? The buffer() algorithm for the general case is in development, and can be used from the development version (Trunk). It generally works but not in all circumstances, and for all geometry types. Regards, Barend
Any idea when the trunk will go GA?
The Trunk always goes GA, however the extensions do not... About this extension: no, it is not yet targetted to a specific version.
Alternatively, can I combine buffer() from the trunk with the remainder of the stable Boost release and live to tell about it ?
Yes, you can just add the whole folder "boost/geometry/extensions" to the released version. It has no other dependencies. Regards, Barend _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 30-1-2013 18:57, John Lilley wrote:
Barend, Thanks so much for the advice. Do I need to do anything to get the extensions built or installed with the regular geometry library? --john
No, the extensions are header-only, just like the rest of the library. No building or installing necessary. Barend
Do you know, where can I find which types are currently supported for the buffer() operation? Does it works with collections of points? Polylines? Would I be better off pulling this from Boost.Polygon and doing the float/integer conversion myself? Thanks john -----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Barend Gehrels Sent: Wednesday, January 30, 2013 10:53 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Geometry buffer algorithm: complete or not?
The buffer() algorithm for the general case is in development, and can be used from the development version (Trunk). It generally works but not in all circumstances, and for all geometry types. Regards, Barend
Hi John, On 20-2-2013 19:19, John Lilley wrote:
Do you know, where can I find which types are currently supported for the buffer() operation? Does it works with collections of points? Polylines?
No resp. yes.
Would I be better off pulling this from Boost.Polygon and doing the float/integer conversion myself?
You can try that. I don't know the state of the algorithm there. Well, I know Boost.Polygon supports polygons, and (afaik) not collection of points or polylines, so in that case the answer is no. Regards, Barend p.s. please don't top-post, because as you can see the order of the mail/answer/mail is lost now...
Thanks john
-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Barend Gehrels Sent: Wednesday, January 30, 2013 10:53 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Geometry buffer algorithm: complete or not?
The buffer() algorithm for the general case is in development, and can be used from the development version (Trunk). It generally works but not in all circumstances, and for all geometry types. Regards, Barend
On 20-2-2013 19:19, John Lilley wrote:
Do you know, where can I find which types are currently supported for the buffer() operation? Does it works with collections of points? Polylines?
No resp. yes.
Would I be better off pulling this from Boost.Polygon and doing the float/integer conversion myself?
You can try that. I don't know the state of the algorithm there. Well, I know Boost.Polygon supports polygons, and (afaik) not collection of points or polylines, so in that case the answer is no. Regards, Barend p.s. please don't top-post, because as you can see the order of the mail/answer/mail is lost now...
Regarding the use of the buffer algorithm in the geometry extensions, I am trying to figure out how to do this. Like, what headers to include to get the extensions buffer() algorithm? Thanks John
participants (2)
-
Barend Gehrels -
John Lilley