Geometry Boost List: Re: [geometry] Breaking change on distance strategies

Subject: Re: [geometry] Breaking change on distance strategies
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-07-16 09:53:16

Hi Bruno,

Bruno Lalande wrote:
> Hi,
>
> FYI, I have just submitted a change (85040) that breaks the interface of
> the distance strategies. Generally speaking, the change is that those
> strategies no longer need to be templated with the point type - a
> strategy can work on any point type once instantiated. More specifically:
> - pythagoras<Point1, Point2, CalculationType> becomes
> pythagoras<CalculationType>
> - haversine<Point1, Point2, CalculationType> becomes
> haversine<RadiusType, CalculationType> - the RadiusType parameter will
> typically be the points' coordinate type, but you might choose something
> else e.g. for performance reasons
> - projected_point<Point, PointOfSegment, CalculationType, Strategy>
> becomes projected_point<CalculationType, Strategy>
> - cross_track<Point, PointOfSegment, CalculationType, Strategy> becomes
> cross_track<CalculationType, Strategy>
>
> Of course this doesn't impact you if you never explicitly specify a
> strategy to use for distance calculations (i.e. if you rely on the
> default ones).
>
> If you write your own strategies, the impact might be more important.
> The most noticeable internal change is that similar_type/get_similar
> disappear, as this change makes them irrelevant.
>
> The plan is to give the same treatment to the other strategies of the
> library.
>

This are great news.

I've noticed slightly different behavior of distance_pythagoras. The 
result type in the previous version was double for integral corrdinates. 
Now CalculationType is also integral type (probably the same as 
coordinate_type) and this causes ambiguous call to sqrt() in line 158. I 
didn't dive into it but is default_distance_result also an integral 
type? Is it intentional?

Regards,
Adam