Boost logo

Geometry :

Subject: Re: [geometry] Difference problem using boost geometry in 1.47 (Daniel Macumber)
From: Macumber, Daniel (Daniel.Macumber_at_[hidden])
Date: 2013-10-28 12:27:37


Thanks Barend, sorry for cross posting to boost list on my first question, I'll stick to here now. I've looked into my problem a bit more and found that the ggl difference method was correctly making a polygon with inner loops, I was adding the extra geometry myself. However, this brings me to a few questions I don't know how to address on my own. I wanted to ask if you have any general advice on how to deal with these issues.

1) I am working in 3D and applying transformations to make my geometry 2D for polygon work. These transformations result in precision errors. One edge of the inner loop in my difference should actually have been on the edge of the outer polygon, which is why I was expecting a single outer loop polygon with a cut out. The inner loop only occurred because of precision issues. Does GGL include any functionality to edge align polygons to help with these issues?

2) In the case that a polygon really does have inner loops I need to convert it into one or more polygons that do not have inner loops. Right now I am using the reverse winding to remove all inner loops from my polygon. However, I would prefer to end up with multiple, simple polygons. Does GGL have any methods to convert a polygon with inner loops into several "nice" polygons with no inner loops?

Thanks a lot,
Dan

-----Original Message-----
From: Geometry [mailto:geometry-bounces_at_[hidden]] On Behalf Of geometry-request_at_[hidden]
Sent: Saturday, October 26, 2013 10:00 AM
To: geometry_at_[hidden]
Subject: Geometry Digest, Vol 22, Issue 21

Send Geometry mailing list submissions to
        geometry_at_[hidden]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.boost.org/mailman/listinfo.cgi/geometry
or, via email, send a message with subject or body 'help' to
        geometry-request_at_[hidden]

You can reach the person managing the list at
        geometry-owner_at_[hidden]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Geometry digest..."

Today's Topics:

   1. Re: Run-Time specified geometries (Mateusz Loskot)
   2. Re: Register CCW Polygon (Andrew Hundt)
   3. Re: Difference problem using boost geometry in 1.47
      (Barend Gehrels)
   4. Re: Finding a boost::equal simplified polygon - remove_spikes
      added to trunk (Barend Gehrels)
   5. Re: [r86420] Added top-level Jamfile.v2 (Barend Gehrels)

----------------------------------------------------------------------

Message: 1
Date: Sat, 26 Oct 2013 00:14:15 +0100
From: Mateusz Loskot <mateusz_at_[hidden]>
To: "Boost.Geometry library mailing list" <geometry_at_[hidden]>
Subject: Re: [geometry] Run-Time specified geometries
Message-ID:
        <CABUeae8uc9G_SB-p=VVifhk2AykBTvvSoq2QRay9zbnN_rddnQ_at_[hidden]>
Content-Type: text/plain; charset=UTF-8

On 25 October 2013 17:53, Bruno Lalande <bruno.lalande_at_[hidden]> wrote:
>>
>> That raise the question how to report runtime errors ?
>> Exception ?
>
>
> It's not a runtime error, as variant types are a compile time information.
> Applying the multi stage resolution as described above will
> automatically reject any variant that could possibly result in trying
> to compute the distance between a 2D and a 3G geometry - e.g. passing
> instances of variant<point<double, 2>, point<double, 3> > in
> parameters for distance will result in a compile time error. One might
> argue it's too conservative, as at run-time we won't necessarily end
> up asking for the fatal combination. But I want to leverage variants type safety as much as possible.

I suppose, users may define views to adapt the 3d geometry as 2d and pass to 2d-aware algorithms in unified form.

Best regards,

--
Mateusz  Loskot, http://mateusz.loskot.net
------------------------------
Message: 2
Date: Fri, 25 Oct 2013 23:31:26 -0400
From: Andrew Hundt <athundt_at_[hidden]>
To: "Boost.Geometry library mailing list" <geometry_at_[hidden]>
Subject: Re: [geometry] Register CCW Polygon
Message-ID:
	<CAMCxpGsoxAKt=V_X8hwy+5PSi2e2Zj_7BKJaFrSg_YYYEr5aCg_at_[hidden]>
Content-Type: text/plain; charset="iso-8859-1"
On Fri, Oct 25, 2013 at 6:10 PM, Mateusz Loskot <mateusz_at_[hidden]> wrote:
>
>
> I'm afraid, that get up and run quickly in case of C++ library heavily
> based on metaprogramming requires quite a bit of knowledge
> of idioms far beyond the C++ OOP.
>
I believe there may be a sufficient number of people in between
"intermediate C++ developer" and "metaprogramming library author" that are
fully capable of using the functionality demonstrated on the quick start
guide but may have no idea that tag dispatching exists, much less how to
use it.
I also think it may be reasonable for such a person to want to make
Boost.Geometry work with their own user defined type when the macros don't
work, since it only requires a very basic understanding of what is going
on. I think that with a little additional guidance it would be easier to
create the specialization and get it to work with their types.
> Therefore, I feel like a bit of
> > explanation of what is being done and why in the documentation of the
> > examples would make them a lot more helpful.
> >
> > Does that make sense?
>
> Yes, it does, but I personally think Boost.Geometry documentation is not
> the
> right place to explain general C++ techniques and idioms. It tries to
> mention
> names of well-known techniques and users are supposed to seek help
> on C++ discussion groups, books, etc.
>
> However, if you think there are BG specifics missing in the docs,
> please point it out and suggest what needs to be clarified.
> Certainly, there is lots of room for improvements in the documentation.
I think adding a few things in slightly more detail to the geometry
adaptation examples<http://www.boost.org/doc/libs/1_54_0/libs/geometry/doc/html/geometry/examples.html>may
help people to integrate without fully comprehending, but still avoid
writing a fundamentals book in the boost docs.
Perhaps something like the following, but with a little more detail and
accuracy, could help?
   - Inline the code and the registration examples explanation like in the
   "quick start"
   - Explain that each of these definitions is a specialization of existing
   utilities in Boost.Geometry
   - Each specialization "explains" to Boost.Geometry with the way to use
   each type
   - A specialization must be provided for each possible interaction type
I'm just thinking back to my own experience from a couple years ago of
learning how to integrate, and my additional experiences afterwards
explaining what was going on to my coworkers.
> Regarding the tag dispatching, Barend Gehrels gives a very good overview
> of those C++ techniques on his blog:
>
> http://barendgehrels.blogspot.co.uk/search/label/tag%20dispatching
I've actually personally commented here before on how good that article is.
:-)
Cheers!
Andrew Hundt
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 3
Date: Sat, 26 Oct 2013 11:54:13 +0200
From: Barend Gehrels <barend_at_[hidden]>
To: "Boost.Geometry library mailing list" <geometry_at_[hidden]>
Subject: Re: [geometry] Difference problem using boost geometry in
	1.47
Message-ID: <526B9145.3090506_at_[hidden]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Hi Dan,
Macumber, Daniel wrote On 25-10-2013 23:50:
>
> I am using boost geometry in 1.47 and am pretty happy with it.  
> However, I am having a problem performing an intersection that I can't 
> figure out how to solve.  When I difference two geometries, I am 
> sometimes left with a result that uses reverse winding to subtract a 
> piece of the result rather than providing a "clean" polygon with 
> winding in one direction only.  I've posted an image here that 
> demonstrates this:
>
> http://oi42.tinypic.com/2elfp0o.jpg
>
> I get the feeling that if I were to use the right models this might 
> somehow be fixed?  If not is there an algorithm that can clean up the 
> result?  Here is the code I am using:
>
> typedef boost::geometry::model::d2::point_xy<double> BoostPoint;
>
> typedef boost::geometry::model::polygon<BoostPoint> BoostPolygon;
>
> typedef boost::geometry::model::ring<BoostPoint> BoostRing;
>
> BoostRing facePolygon;
>
> BoostRing otherFacePolygon;
>
> std::vector<BoostPolygon> faceDifferenceResult;
>
> ....
>
> boost::geometry::difference(facePolygon, otherFacePolygon, 
> faceDifferenceResult);
>
>
This should be handled correctly. The usage seems good. Do you have them 
clockwise ordered? You might call boost::geometry::correct first.
Do you have the coordinates  (preferably WKT) of your input polygons? I 
can then better check the case.
Thanks, Barend
-------------- next part --------------
HTML attachment scrubbed and removed
------------------------------
Message: 4
Date: Sat, 26 Oct 2013 15:28:33 +0200
From: Barend Gehrels <barend_at_[hidden]>
To: "Boost.Geometry library mailing list" <geometry_at_[hidden]>
Subject: Re: [geometry] Finding a boost::equal simplified polygon -
	remove_spikes added to trunk
Message-ID: <526BC381.2050702_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
Claus Christmann wrote On 23-10-2013 17:37:
> Hi Barend
>
> On Wednesday, October 23, 2013 17:16:34 Barend Gehrels wrote:
> [...]
>> There is a "remove_spikes" in the extensions which did not always work.
>> By chance I recently created a new version, intended for the main trunk
>> (so not an extension). But it still has to be committed, I will do that
>> this week.
> Wow, that is what I call "luck" :) Looking forward to the commit.
>
The remove_spike algorithm is committed (in Trunk, commits 86450 .. 86452)
There are not yet docs, but it is quite straightforward, calling 
boost::geometry::remove_spikes(polygon) will change polygon and remove 
the spikes. Unit tests are available.
Regards, Barend
------------------------------
Message: 5
Date: Sat, 26 Oct 2013 15:31:48 +0200
From: Barend Gehrels <barend_at_[hidden]>
To: "Boost.Geometry library mailing list" <geometry_at_[hidden]>
Subject: Re: [geometry] [r86420] Added top-level Jamfile.v2
Message-ID: <526BC444.9050907_at_[hidden]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Mateusz,
Mateusz Loskot wrote On 24-10-2013 20:38:
> Folks,
>
> FYI, I've added the library top-level Jamfile.v2 in
> libs/geometry/Jamfile.v2 and
> similarly added top Jamfiles for extensions and index.
>
> This is just a little utility that allows to build all tests and examples
> for all components with single command, for example:
>
> cd ${BOOST}/libs/geometry
> b2 toolset=clang
>
Thanks for this!
Can you also include doc/src/examples ? Those are the examples used 
inside the QB docs.
Regards, Barend
------------------------------
Subject: Digest Footer
_______________________________________________
Geometry mailing list
Geometry_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/geometry
------------------------------
End of Geometry Digest, Vol 22, Issue 21
****************************************

Geometry list run by mateusz at loskot.net