Geometry Boost List: [ggl] combine

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. http://bit.ly/aPh6Bv

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.

stream.some_method(data);

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

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)

or

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);
box.expand(something);

or maby

box.expand(something1).expand(something2)
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 
box).

Regards,
Adam