Geometry Boost List: [ggl] box/box clipping

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

Hi,

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 
collection.
 
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:
http://lists.boost.org/Archives/boost/2008/10/142979.php
 
and this 
http://lists.boost.org/boost-users/2008/06/37265.php
 
 
 
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

Hi,

> 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 
found,
> returns inverse infinite box.

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

Regards, Barend

_______________________________________________
ggl mailing list
ggl_at_[hidden]
http://lists.osgeo.org/mailman/listinfo/ggl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20101228/701d848e/attachment.html