Boost logo

Geometry :

Subject: [ggl] combine
From: Adam Wulkiewicz (adam.wulkiewicz)
Date: 2011-02-27 07:17:03

Barend Gehrels wrote:
> Nearly all functions conform to the std:: library. std:: library defines
> first input iterators, then output iterators, then other values.
> e.g.

Isn't scheme used only in relation to iterators? For objects that are
references/pointers to some object in the collection.

E.g. streams are allways the first parameter.

out& operator<<(out, data)
in& operator>>(in, data)
boost::asio::read(socket, data)
boost::asio::write(socket, data)

Probably because they're stand-alone objects, different from data and
the order is simply taken from method call syntax.


In addition to his, we could write:

stream << data1 << data2 << ...
stream.do_something(data1).do_something(data2) ...

So it's natural that streams are the first parameter.

> 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)

Considering the function name. If we have functions combine, connect,
join the order, there should be some similarity between the parameters.
The order doesn't matter because take similar objects and return
something connected/combined/joined. The next thing is that our function
may have the name combine or combined.

Our syntax would look like this:

Box combined(Geometry const & geometry, Box const& box)
Geometry3 combined(Geometry1 const & geometry, Geometry2 const& box)


void combine(Geometry const & geometry, Box const& box, Box &expanded_box)
void combine(Box const& box, Geometry const & geometry, Box &expanded_box)
it doesn't matter if the box is first or second because the result is in
the third parameter, something combined.

But if we have the name corresponding to one of the objects, e.g.
expand, IMO it should be on the first place because the name corresponds
to it.

expand(box, something);

or maby

box << something1 << something2 ... // this looks a little odd

on the other hand

Box Box::expanded(Geometry const& something) const
Box expanded(Box const& box, Geometry const& something);

But, it all depends on how we think of the box.

In the computer graphics and game programming areas this operation is
named expanding and the box is referred as aabb (axis alligned bounding


Geometry list run by mateusz at