Boost logo

Geometry :

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
>


Geometry list run by mateusz at loskot.net