Geometry Boost List: [ggl] cartesian distance

Subject: [ggl] cartesian distance
From: Barend Gehrels (barend.gehrels)
Date: 2010-05-18 10:19:45

Hi Bruno,

> Just to make sure I understand correctly, the plan now is thus to make
> the distance function return a real numeric type rather than a special
> comparable type, and have a comparable_distance function that returns
> the squared result explicitly?
>   
Yes
> If yes, will comparable_distance return the same (non-numeric) type as
> what distance used to return, or will that be a real numeric type the
> value of which is squared, and that can thus not be used for anything
> else than comparisons?
>   
The second, so a numeric type which is squared (for cartesian coordinate
systems) or not squared (for spherical coordinate systems). So yes, it
can be only used for comparisons.

For Cartesian this will be much more efficient (though sqrt is not as
hard as it used to be).

For spherical, just looked it up, Haversine is:

        double a = math::hav(lat2 - lat1) + cos(lat1) * cos(lat2) *
math::hav(lon2 - lon1);
        double c = 2.0 * asin(sqrt(a));
        return return_type(m_radius * c);

(it is usually written with atan2 but equivalent, see e.g.
http://blog.julien.cayzac.name/2008/10/arc-and-distance-between-two-points-on.html

so the 2* and the m_radius* can be saved. If I'm right we can go
further: asin is a monotonic function so could be saved as well, and
then also here sqrt can be saved, so it will be just:

     return math::hav(lat2 - lat1) + cos(lat1) * cos(lat2) *
math::hav(lon2 - lon1);

That optimization is currently not yet there (but will be simpler to
implement after the change). Didn't think about this earlier.

For geographic (at least Andoyer) there are some optimizations as well
(though only multiplication)

Regards, Barend