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