Boost logo

Geometry :

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


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.

Boost.Range does the same thing,

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.

boost::geometry::intersection_inserter(a, b, output_inserter);
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:

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:, 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

Geometry list run by mateusz at