Ticket #11917 (closed Bugs: fixed)

Opened 14 months ago

Last modified 14 months ago

geometry default geographic (andoyer) antipodal distance is zero

Reported by: Ken Barker <ken.barker@…> Owned by: barendgehrels
Milestone: Boost 1.61.0 Component: geometry
Version: Boost 1.60.0 Severity: Problem
Keywords: wgs84 distance andoyer Cc:


When calling the default (andoyer) boost::geometry::distance() function, with boost::geometry::cs::geographic points that are close to being antipodal (e.g. the North and South poles or points that are diametrically opposed around the equator), it returns reasonable results. However, when called with antipodal points it returns zero, e.g.:

Andoyer distance near poles:     20003917.164970
near opposite equatorial points: 20037508.151445
Andoyer distance at poles:  0.000000
opposite equatorial points: 0.000000

Here the code I used to obtain the results above:

    typedef boost::geometry::cs::geographic<boost::geometry::radian> Wgs84Coords;
    typedef boost::geometry::model::point<double, 2, Wgs84Coords> GeographicPoint;
    // Min value for delta. 0.000000014 causes Andoyer to fail.
    const double DELTA(0.000000015);
    // Note boost points are Long & Lat NOT Lat & Long
    GeographicPoint near_north_pole   (0.0,  M_PI_2 - DELTA);
    GeographicPoint near_south_pole   (0.0, -M_PI_2 + DELTA);
    double andoyer_minor(boost::geometry::distance(north_pole, south_pole));
    std::cout << "Andoyer distance near poles:     " << andoyer_minor << "\n";

    GeographicPoint near_equator_east ( M_PI_2 - DELTA, 0.0);
    GeographicPoint near_equator_west (-M_PI_2 + DELTA, 0.0);
    double andoyer_major(boost::geometry::distance(near_equator_east, near_equator_west));
    std::cout << "near opposite equatorial points: " << andoyer_major << "\n\n";

    GeographicPoint north_pole   (0.0,  M_PI_2);
    GeographicPoint south_pole   (0.0, -M_PI_2);
    andoyer_minor = boost::geometry::distance(north_pole, south_pole);
    std::cout << "Andoyer distance at poles:  " << andoyer_minor << "\n";

    GeographicPoint equator_east ( M_PI_2, 0.0);
    GeographicPoint equator_west (-M_PI_2, 0.0);
    andoyer_major = boost::geometry::distance(equator_east, equator_west);
    std::cout << "opposite equatorial points: " << andoyer_major << std::endl;

This is clearly a bug. The distance between the antipodal points should be slightly larger than the distance between the other points, and definitely NOT zero!


Change History

comment:1 Changed 14 months ago by Charles Karney <charles@…>

I recommend that boost::geometry include the algorithm for geodesic distance given in my paper,  Algorithms for geodesics. This returns an accurate result for the distance for arbitrary points on terrestrially relevant ellipsoids.  GeographicLib (version 1.25 and later) also includes the solution in terms of elliptic integrals which is accurate for ellipsoids of revolution with 1/100 < b/a < 100.

comment:2 Changed 14 months ago by Ken Barker <ken.barker@…>

I agree with Charles Karney's comment above.

I originally raised this issue after finding an issue with the Vincenty function, see:

On further investigation (and with a bit of help from Charles) I came to realise that both the Vincenty and Andoyer algorithms calculate incorrect distances for antipodal points on the equator. Whilst [GeographicLib?]( calculates the correct distance.

It should be included in boost geometry and replace Andoyer as the default algorithm.

BTW, please note that Charles's link to GeographicLib is incorrect, please use the one in this comment.

comment:3 Changed 14 months ago by Charles Karney <charles@…>

It might also be worth pointing out that "Algorithms for Geodesics" also provides a method for computing the area of a geodesic polygon (a polygon whose sides are geodesics) on an ellipsoid.

comment:4 Changed 14 months ago by barendgehrels

Thanks, both, and we welcome the papers and involvement of Charles Karney! We were already aware of your library and your papers, also with respect to area, this is very helpful.

comment:5 Changed 14 months ago by awulkiew

  • Status changed from new to closed
  • Version changed from Boost 1.61.0 to Boost 1.60.0
  • Resolution set to fixed
  • Milestone changed from To Be Determined to Boost 1.61.0

Add a comment

Modify Ticket

Change Properties
<Author field>
as closed
The resolution will be deleted. Next status will be 'reopened'

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.