Re: [boost] preview of a template geometry library

From: Barend Gehrels (barend_at_[hidden])
Date: 2008-02-05 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