Subject: Re: [geometry] Breaking change on distance strategies
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-07-16 09:53:16
Bruno Lalande wrote:
> 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
> - 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
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?
Geometry list run by mateusz at loskot.net