
Geometry : 
Subject: Re: [geometry] Fwd: Some updates [union of multi_polygon]
From: Carl Wellington (carlw_at_[hidden])
Date: 20140805 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
>> multipolygon has multiple parts and keeps the first polygon in addition
>> to
>> the union. Therefore it selfintersects 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 reread
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://boostgeometry.203548.n3.nabble.com/FwdSomeupdatestp4026145p4026151.html Sent from the Boost Geometry mailing list archive at Nabble.com.
Geometry list run by mateusz at loskot.net