Handling ambiguity/sanity check constant in EllipsoidGeodesic

EllipsoidGeodesic has a "uniqueness" developer sanity check in its code:

Check.typeOf.number.greaterThanOrEquals('value', Math.abs(Math.abs(Cartesian3.angleBetween(firstCartesian, lastCartesian)) - Math.PI), 0.0125);

This check includes a constant (effectively 0.0125 shy of Math.PI) at its heart.

First, I wonder how this constant was derived / established; it seems rather arbitrary and I could not source an explanation. Tangentially, I wonder if it can be improved.

Second, I wonder how we can remove the check and avoid the potential spin-lock introduced when there is truly are congruent paths for the given points.

Interestingly, an EllipsoidGeodesic beginning and ending at the poles [(0, 90) and (0, -90)] has no issue being computed and does not spin-lock (block a whole thread/CPU core); the resulting line appears to be along the prime meridian.

An EllipsoidGeodesic beginning and ending at opposites on the equator however, does give rise to the non-converging math / spin-lock/blocking.

Could Cesium make an assumption in the cases where there are multiple solutions (like it seems to do with the poles/prime meridian)? Could Cesium allow the user to override this assumption?

Input regarding these ideas is much appreciated; thanks!

This check, including the constant value, was ported from the STK Components implementation in the very earliest days of Cesium. Ultimately this check is attempting to deal with situations where Vincenty’s inverse method fails to converge. More details on wikipedia: https://en.wikipedia.org/wiki/Vincenty%27s_formulae#Nearly_antipodal_points

There is an open issue to port the improved algorithms which do not suffer from these issues to Cesium: https://github.com/AnalyticalGraphicsInc/cesium/issues/3057

Thank you Scott.

I created this PR while familiarizing myself more with the issue; https://github.com/AnalyticalGraphicsInc/cesium/pull/7457

I hope these improved algorithms can be looked at again soon.