Re: [boost] Boost.Polygon : How to deal with per point attributes

Subject: Re: [boost] Boost.Polygon : How to deal with per point attributes
From: philippe.lamontagne.2_at_[hidden]
Date: 2010-02-26 10:21:48

Thanks for your quick and efficient reply ;)
Regards

________________________________

From: boost-bounces_at_[hidden] on behalf of Simonson, Lucanus J
Sent: Thu 2010-02-25 16:11
To: boost_at_[hidden]
Subject: Re: [boost] Boost.Polygon : How to deal with per point attributes

philippe.lamontagne.2_at_[hidden] wrote:
> Question 1:
> For my specific application the points inside the polygons need to
> contain attributes
> in addition to their x and y coordinates. This extra information is
> required in a
> per-point basis. I need to compute intersections and differences of
> polygons. The
> operations can be performed regardless on the attributes, but it's
> important that
> the attributes be present in the polygons resulting from the
> operations. Does BOOST
> provide a mechanism for keeping such per point attributes?
> I followed the example to make my own point and polygon classes work
> with BOOST, but
> for what I can see, the polygons operations are performed using GTL's
> own data types
> and transferred back to my types, loosing any attributes in the
> process. I am
> missing something here?

Any additional data your point type carries is lost when the library copies its coordinates to my internal data structures.  However, your issue is easy to work around.
You can create a std::map of point to attributes and lookup the attributes from the map for the output polygon points efficiently.

> Question 2:
> I noticed that if I have multiple points located on the same straight
> line only the
> initial and final points will be kept in the resulting polygon and
> that the intermediate
> points will be discarded. Whereas this behavior is probably
> preferable in the general
> case, it causes me a problem if I want to maintain point attributes
> because the
> attributes are not guaranteed to be the same all over the straight
> line. Is there
> a way to change this behavior?

Only the 45 degree and 90 degree algorithms elminate intermediate points.  For the general case I do keep colinear points in output edges because it is easier to remove them in post processing than recover them.  We have an internal application that requires this.  You can recover lost colinear points of manhattan edges by sorting the output vertical edges and input points in x major and then reinserting colinear points in your output polygons.  Repeat for horizontal with y major sorting.  For 45-degree it is a little trickier, but you can sort on y-intercept major and x-intercpet minor to achieve the same thing.  I can elaborate if needed.  A similar approach would work for associating input *edge* attributes to output edges, it you happen to need that also.

> I'm aware that polygon operations may create new points.  I can deal
> with a few empty attributes as long as original points keep their
> initial attributes. 
>
>   We hope there are some solutions or workarounds because I strongly
> appreciate the library.  Thanks for the excellent work.

I hope the solutions and workarounds I suggested work for you.

Thanks for giving my library a try and expressing your appreciation to the boost community for providing it.
Luke
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost