Hi Menelaos, Samuel,

Menelaos Karavelas wrote On 14-5-2014 9:18:
Hi all.

On 12/05/2014 10:31 μμ, Barend Gehrels wrote:

We received a merge request from Samuel Debionne for support of variants for the distance algorithm. Thanks very much for this.

Menelaos, how can that be combined with your work for distance algorithm? Can it be merged, and which should go first?

It is orthogonal with respect to what I am doing on distances, as it simply adds one layer of dispatch between the free distance function and the actual dispatching in the boost::geometry::dispatch namespace.

With respect to which one goes first, I tried either way in my local repository and it ends up in a conflict. So it really does not matter. We just need to decide.

So far there are no tests for the proposed code, so I would prefer to have this before going for a merge.

My biggest concern is with respect to support for strategies. It is not at all obvious to me how this is to be done, given the fact that different geometry pairs are associated with different distance strategies.

Having said that, this is not an issue for the free distance function that does not take a strategy as argument, and variant support should be easy to implement (you first resolve variants, and then use the default distance strategy for the geometry pair we have).
My suggestion would be to start from this: support variants for distance(g1, g2) (no strategies), have tests for this variant support, and think more about how to do things with strategies.

OK, so we can merge in either order, and I agree, default strategy should be retrieved after resolving the variant.

Regards, Barend

Bruno, can you take a look at the contribution? (Others are of course welcome too).

This is the info:

Or view, comment on, or merge it at:


Commit Summary

File Changes

Patch Links: