Subject: [ggl] union/intersection of multi-polygons
From: Barend Gehrels (Barend.Gehrels)
Date: 2010-03-10 09:11:15
> Sorry for the very late answer on this, this email got lost somehow.
No problem :-)
> I'm not knowledgeable at all on this kind of decision, but as a GIS
> newbie I would say it doesn't make sense to me as well to detect
> internal intersections of 2 self-intersecting multipolygons when
> trying to intersect them with each other. We're really trying to
> intersect to distinct entities, whatever happens *inside* them is not
Yep, I agree but I'm still not sure. Seen from set-theory, if we have to
sets A and B, the proper union is A unioned B without internal borders
of course... Furthermore we might get into internal troubles because we
might get internal intersections, disturbing the algorithm.
So I will come back to this.
> If the user really wants to do that, maybe we could provide a function
> that would split multipolygons back into several polygons.
Actually this function is implicit because a multipolygon is a std::
vector (or deque) of polygons.
> resulting concept could be called "polygon_group" or even "polygons",
> and its fundamental difference with a multipolygon would be that when
> a binary operation is called on 2 polygon groups, the operation would
> actually be applied on all the polygons listed. That is, if you
> intersect 2 polygon groups, one with 2 polygons and one with 3, you're
> actually asking to intersect 5 polygons in total.
Yep. That function is interesting indeed, today a collegue asked me if
Boost.Geometry could intersect two vectors of geometries. Which at this
moment it cannot.
Geometry list run by mateusz at loskot.net