Details
-
Bug
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
1.0
-
None
-
None
Description
The GeodesicOnEllipsoid class tries to implement the equations published in Charles F. F. Karney, 2013, Algorithms for geodesics (SRI International), completed by Karney 2011, Geodesics on an ellipsoid of revolution. Those algorithms were already implemented in GeographicLib, which we use as a reference implementation in our tests but not in the main code in order to keep the amount of Apache SIS dependencies low. We also want close integration with the rest of SIS framework (automatic conversion of input/output coordinates), keep some intermediate values for computing Bezier curves, etc. However our current implementation has the following limitations (maybe because of misunderstanding on our side). The GeographicLib source code may be examined for understanding what we are doing wrong, but the relationships between that source code and the formulas are not easy to establish.
Points at poles
In computeEndPoint(), calculation of ω2 and azimuth become indeterminate at the poles, where sin α₀ = cos σ = 0. Karney "ensures that ω (and hence λ) and α are consistent with their interpretation for a latitude very close to the pole (i.e., cos β is a small positive quantity) and that the direction of the geodesic in three-dimensional space is correct", but we have not identified how he does that exactly.
Nearly antipodal geodesics on equator
Apache SIS does not have a solution for geodesics on equator when the difference of longitude is ∆λ > (1 - f)⋅π (close to 180°). This issue is discussed in Karney (2013) below equation 44, but we have not yet understood what is the appropriate action. Even if equation 57 can be use for computing α₁ in such case, we still have equations 11 and 12, for example σ = atan2(sinβ, cosα⋅cosβ), producing 0 because sin β = 0, which result in a geodesic distance of 0. We surely do something wrong, but I haven't understood what yet. Current SIS implementation throws GeodesicException in such case.
Extra-terrestrial ellipsoid
Current implementation is tested on WGS84 ellipsoid. Prolate ellipsoids or ellipsoids with high eccentricities have not been tested. There is some special cases in GeographicLib source code for those kinds of ellipsoids, but not yet in SIS.
Possible optimizations
In createGeodesicPath2D, since we only need points which are approximately evenly spaced on the geodesic, we could replace ∆s distance by ∆σ arc length on the auxiliary sphere. It would avoid the conversion from τ to σ.
