Geometry Boost List: [ggl] box/box clipping

Subject: [ggl] box/box clipping
From: feverzsj
Date: 2010-12-28 09:14:42

barend wrote:
> 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

Yes, keeping everything in a general form is not an easy job, so 
sometimes I am more likely to program in C style, just introduce another 
name, which is simple and plain.
What if we just use another function(e.g. intersection_1()) for those 
combination which only generate single result?

>
>  
>
>     -----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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>