Thanks for pointing the errors in DefaultEllipsoid.orthodromicDistance
too. I filled another JIRA task for this one:
https://issues.apache.org/jira/browse/SIS-386
In both cases (DistanceUtils and DefaultEllipsoid.orthodromicDistance),
the action could be to deprecate them and replace them by some
GeodeticCalculator (or whatever name is best suited) class.
Martin
Le 14/01/2018 à 23:14, Charles Karney a écrit :
> The file
>
> core/sis-referencing/src/main/java/org/apache/sis/referencing/datum/DefaultEllipsoid.java
>
> contains a routine orthodromicDistance. A more standard (and more
> euphonious) name would be geodesicDistance. In addition the statement
> "The orthodromic path is always on a great circle" is wrong, since, in
> general, there are no great circles on an ellipsoid.
>
> orthodromicDistance (or geodesicDistance) uses Vincenty's algorithm
> which is known to fail for nearly antipodal points. My package
> net.sf.geographiclib.GeographicLib-Java includes an algorithm which is
> more accurate than Vincenty's and (more importantly) always converges.
>
> In the case where algorithm hasn't converged, the routine attempts a
> lame patch-up in the case where the two points lie on the equator. This
> computes the distance as
>
> abs(lon1-lon2) * getSemiMajorAxis();
>
> This is doubly wrong:
>
> (a) lon1-lon2 needs to be reduced to the range [-pi,pi]. The tests in
> DefaultEllipsoidTest.java don't catch this blunder.
>
> (b) the formula assumes that the geodesic runs along the equator;
> however this only holds if the longitude difference is less than or
> equal to (1-f) * pi. The tests in DefaultEllipsoidTest.java bake in
> this incorrect assumption.
>
> --Charles
