On 12/05/2014 10:31 μμ, Barend Gehrels
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
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
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
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.
P.S.: There were some problems with the boost mail server, so I only
saw this message today, hence the late response.
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:
- [distance] Add variant support
Geometry mailing list