
Boost : 
From: Barend Gehrels (barend_at_[hidden])
Date: 20080205 07:44:18
Phil,
I have thought about the output iterator.
The output iterator would indeed be convenient for the Geometry Library.
If the intersection algorithm(s) output their intersections with an
output iterator, this eliminates the need of having the multi_polygon
and multi_linestring as the output. This was one of the reasons to have
the multi_polygon / multi_linestring. Other reasons are the OGC model,
and that it is a standard GIS concept. These are still valid. However,
many users of a Geometry Library might not be very interested in either
ogc or gis. So it might be good to omit them as output result and use an
output iterator instead. Outputting to a multi_polygon is then possible
by using an appending outputiterator.
So I will change this in the library.
Then I thought, where do we then still need the multi versions of the
geometries. There are still places where multi_polygon produce different
results as single geometries. One of these places is the "union"
algorithm. A union of a multi_polygon with a polygon might result in one
polygon. So this is a valid reason for the existance of a multi_polygon.
However, I've used, years ago, the union in one or more projects, but at
that time I needed a combination of many (multi)polygons, so not one
multi_polygon. Spatial aggregations work like that. So building the
union algorithm with two iterators on a polygon container as their
input, would in fact be more convenient than a union processing two
multipolygons. So in the union case we can also do without
multi_polygons. The Weiler Atherton algorithm works using two polygons,
but will work as well using three or more at the same time (didn't work
this out but I think that this must be the case).
Another place is the "buffer" algorithm. A buffer of a multi_polygon
with two polygons is different (an might be one polygon) from a buffer
of two (the same) polygons. However, we could of course also model the
buffer algorithm using begin/end iterators, which gives more
flexibility. (By the way, it is not yet implemented).
If we implement our library without the algorithm versions using multi
geometries, the combination of versions per algorithm taking two
geometries will by 9 instead of 36, which saves us work. The multi
geometries will probably still be there because they are really a
separate GIS entity, but the need to have them implemented in all
algorithms is then not there. In my previous answer I said that there
would be more combinations using the output iterator, now I think that
number of the combinations will be less. Thanks.
> Yes, polygons with holes are more complicated; I've never had to deal
> with them. I think it's worth defining separate concepts for solid and
> holey polygons so that algorithms can specify which they work with.
>
There are: a "solid polygon" is a "linear ring", a "polygon" can have
holes. Many algorithms on polygon use the corresponding algorithms on rings.
Barend
  Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands, www.geodan.nl
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk