Geometry Boost List: [ggl] combine

Subject: [ggl] combine
From: Barend Gehrels (barend)
Date: 2011-02-26 14:06:37

Hi,

One of the things remarked during the review was the order of 
parameters, not always being consistent.

Nearly all functions conform to the std:: library. std:: library defines 
first input iterators, then output iterators, then other values.
e.g. http://bit.ly/aPh6Bv

Boost.Range does the same thing, http://bit.ly/hqNEs5

And so does Boost.Geometry, first input, const geometries, then output, 
mutable geometries, then other parameters.

For example:

boost::geometry::intersection(a, b, output);
where output is an output collection or multi-polygon.

and:
boost::geometry::intersection_inserter(a, b, output_inserter);
or:
boost::geometry::intersection_inserter(Geometry1 const & geometry1, 
Geometry2 const & geometry2, OutputIterator out, Strategy const & strategy)

So most of our functions agree to this scheme.

However, combine does not. combine is not an OGC function, and adds a 
geometry to a bounding box. It has this signature:
http://bit.ly/gFlbQp

I think it should be consistent with the other functions, so having:
void combine(Geometry const & geometry, Box & box)
though it feels less natural.

At the same time maybe the name might be enhanced, which also would 
solve the issue of backwards compatibility.

Postgis does use ST_Extent for a similar, but slightly different 
function: http://bit.ly/fbUA2V, calculating the bounding box of several 
geometries, which is also the intent of combine (doing it per geometry).

So "extent" or, as a verb, "extend" might be a convenient name. 
"add_to_box" or even "union" might be alternatives (though union would 
here mean not a spatial set union but a united box)

Any thoughts?

Regards, Barend

-- 
Barend Gehrels
http://about.me/barendgehrels