
Geometry : 
Subject: [ggl] combine
From: Barend Gehrels (barend)
Date: 20110226 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 multipolygon.
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
Geometry list run by mateusz at loskot.net