Boost logo

Geometry :

Subject: [ggl] box/box clipping
From: barend (barend.gehrels)
Date: 2010-12-28 08:55:08


Another message about this from my side. It is basically running (not yet
committed) now, taking the last option, so calling the back_inserter later,
for an output box it is skipped.

The only thing is that it makes the function even more generic and complex.

Until now we had:
intersection_inserter (geometry1, geometry2, output_iterator), outputting to
any collection
intersection(geometry1, geometry2, collection), also outputting to any
collection (e.g. a multi_polygon)

and now we have also:
intersection(geometry1, geometry2, geometry_out), this only in case of a
box, because the intersection of a box is either a box or nothing, but never
a collection. For union it is a little different (will be often a polygon,
but then: one polygon).

what if people expect to specify a polygon as geometry_out? It will
currently not compile, and in most cases it is better to not compile,
because the intersection might result in more polygons. But sometimes (e.g.
box-box), specifying one polygon makes sense.

Anyway, this is not just a matter of the name intersection, but more of the
whole library, combinations do not always make sense. So I think it is OK as
it is now, and a good enhancement.

Regards, Barend


-----Original Message-----
From: "barend" <barend.gehrels_at_[hidden]>
To: "Generic Geometry Library Discussion" <ggl_at_[hidden]>
Date: Tue, 28 Dec 2010 13:00:48 +0100
Subject: Re: [ggl] box/box clipping

Hi FeverZsh,
It is good that you mailed me about this. It was always planned that this
was (less cumbersome) within the intersection function.
That is probably still possible, but it forwards to the
intersection_inserter function, calling a std::back_inserter on its output
In most cases this is good behaviour, nearly all intersections (even of two
segments) give one, two or more intersections.
But in the case of boxes, it is indeed inconvenient. Either the user should
call the function with a std::vector of boxes. That is very inconvenient. Or
we probably might define a std::back inserter on a box, the first point
inserted being lowerleft, the second point upperright. That is artificial.
Or we might keep it as separate functions, calling the std::back_inserter in
a later phase in the dispatch process. That is probably the best option and
I will look at that. If so, the intersection function might return bool if
there are intersections found.
Actually a metafunction boost::is_range might help. Just googled and found
some mails about this:
and this
If this all is possible, with or without is_range (it probably is), the
function would look like
bool intersection(Box const& b1, Box const& b2, Box& clipped), so the
function you proposed but with the old name...
Thanks, Barend

-----Original Message-----
From: "barend" <barend.gehrels_at_[hidden]>
To: "Generic Geometry Library Discussion" <ggl_at_[hidden]>
Date: Tue, 28 Dec 2010 11:18:08 +0100
Subject: Re: [ggl] box/box clipping


> box/box clipping is often used in lots of scene, while in ggl, using
> intersection is just too cumbersome for such simple job.
> Is it possible to add a dedicated function for such case?
> For example:
> bool clip_box(Box const& b1, Box const& b2, Box& clipped); // while no
> intersection found, returns false.
> or
> Box clip_box(Box const& b1, Box const& b2); // while no intersection
> returns inverse infinite box.

OK, might be good idea. I will think about it.

Regards, Barend

ggl mailing list
-------------- next part --------------
An HTML attachment was scrubbed...

Geometry list run by mateusz at