Geometry Boost List: Re: [geometry] Fwd: Some updates [union of multi_polygon]

Subject: Re: [geometry] Fwd: Some updates [union of multi_polygon]
From: Carl Wellington (carlw_at_[hidden])
Date: 2014-08-05 22:17:44

Menelaos Karavelas wrote
>>
>> It appears that when I repeatedly union the polygons in one at a time,
>> then
>> it does not do what I expect. I would expect the above two cases to be
>> equivalent, but when I add polygons one at a time, then the resulting
>> multi-polygon has multiple parts and keeps the first polygon in addition
>> to
>> the union. Therefore it self-intersects and cannot be used for further
>> calls.
> 
> Here is what is happening: the third parameter of the the union_ 
> function should better be thought of /*not*/ as a multipolygon, but 
> rather as a container of polygons. What union_ does is that it computes 
> the union of the two geometries that you pass as the first two 
> arguments, and then outputs (appends to be exact) the resulting 
> polygon(s) in the polygon container. So the keyword here is 
> /*outputs/*//*appends*/. The contents of the third argument to union_are 
> */not/*/*cleared*/, which means that when you write:
>      bg::union_(output2, blue, output2)
> the output2 and blue polygons are unioned, and then the resulting 
> polygon(s) (only one in this case) is appended to output2. This is why 
> you see the green polygon in output2 after this union operation. See 
> also my attached program that uses yet another multipolygon for the 
> union of output2 and blue.
> 
>> So, is this behavior expected? If so, is there an alternative formulation
>> I
> 
> Yes it is expected in the sense that the contents of the third argument 
> to union are not cleared.

Thank you for the clear explanation and quick response. This solved my
problem. After reading your explanation, I went back to the docs and re-read
them with this in mind, and it made sense. However, I think it would be
really helpful to add some of this commentary to the documentation to
union_, intersection, etc, specifically noting that it appends. I think this
is especially true in this case since the boost function does not behave
like the mathematical set functions with the same names. By that I mean
that:
A = empty
A = union(A,B)
A = union(A,C)
is not equivalent to:
A = union(B,C)
and in fact the first way does not even produce a valid set.

Again, with your description in mind and thinking of the third argument not
as an output but as something like a back_inserter, then it makes sense, but
before your description, even seeing in my sample program what it was doing,
I was convinced that it was incorrect. I even read through the OGC Simple
Feature Specification referenced in the "Conformance" section of the union_
docs and decided that this boost function did not conform to that standard
because it does not "Return a geometric object that represents the Point set
union of this geometric object with another Geometry" as specified in that
document. As you said, *Append* is the key word here and then it all makes
sense.

Maybe replacing the existing description:
"The free function union calculates the spatial set theoretic union of two
geometries"
with something like the following:
"The free function union calculates the spatial set theoretic union of two
geometries and appends the result to an output collection"

I expect you can think of a more clear way to say it, but if something like
the above text had been there (with append specified) then I think I would
have written things correctly the first time and never gotten confused.
Similar comments for the related functions like intersection. And if you are
making a change here, there is also a small typo in the brief description of
union: "Combines two geometries which each other." (should be 'with', not
'which')

Once again, thanks for your help and quick reply,
Carl

--
View this message in context: http://boost-geometry.203548.n3.nabble.com/Fwd-Some-updates-tp4026145p4026151.html
Sent from the Boost Geometry mailing list archive at Nabble.com.