
Geometry : 
Subject: Re: [geometry] Breaking change on distance strategies
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 20130716 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
Geometry list run by mateusz at loskot.net