Geometry :

Daniel.Macumber_at_[hidden]

--
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
****************************************