Re: [boost] [gsoc18] Mentor Search for Boost.Geometry idea

Subject: Re: [boost] [gsoc18] Mentor Search for Boost.Geometry idea
From: Tinko Bartels (tinkobartels_at_[hidden])
Date: 2018-03-16 18:53:54

First of all, thank you, to Adam and Vissarion for showing interest and
offering mentorship. I will start writing a proposal.

Boost - Dev mailing list wrote
> Out of curiosity could you give some example or is the behavior not 
> fully known yet?
> For instance what would be the results of the above functions if we had 
> 2 boxes overlapping each other with a small area near the vertex?
> E.g. BOX(0 0, 5 5) and BOX(4 4, 9 9).

That would depend on what is considered part of the box, i.e. whether BOX(0
0, 5 5) is [0,5]x[0,5] or [0,5)x[0,5). Because interest has been shown, I
have published a quick implementation of difference for (box, box,
container<box>) on GitHub (
https://github.com/tinko92/boost_geometry_difference_demo ).

I have chosen to consider boxes closed on all ends, and my result for your
example boxes is (assuming integer coordinates):

BOX(0 0, 5 5) minus BOX(4 4, 9 9) results in the two boxes: BOX(0 0, 3 5)
and BOX(4 0, 5 3).

For floating point, the convention of closed intervals is a little awkward,
since "-1" from integers doesn't translate directly to floats, so maybe
half-open intervals would make more sense there. 

For union I would expect the result to be three boxes, BOX(0 0, 3 5), BOX(4
0, 5 3) and BOX(4 4, 9 9) and for sym_difference, I would expect a list of
four boxes:  BOX(0 0, 3 5), BOX(4 0, 5 3), BOX(6 4, 9 9) and BOX(4 6, 5 9).

Another awkward case is BOX(0 0, 5 5) minus BOX( 1 1, 4 4)  which would
result in 4 thin slices of thickness 0, which makes them invalid with
respect to boost::geometry::is_valid, so I've added a parameter to the demo
that determines whether I want to allow this or not.

Of course, those solutions are not uniquely determined and assume that the
resulting list of boxes should be an exact cover of the result set and not
allow intersections in the result. It might be sensible to make this more
configurable to give a potential user of those methods more freedom to
express his preferences with regard to those edge cases.

--
Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html