Handling ambiguity/sanity check constant in EllipsoidGeodesic

Nathan_Schulte · January 2, 2019, 8:45pm

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);

github.com

CesiumGS/cesium/blob/1.53/Source/Core/EllipsoidGeodesic.js#L181


      
              ellipsoidGeodesic._uSquared = uSquared;
          }
          
          var scratchCart1 = new Cartesian3();
          var scratchCart2 = new Cartesian3();
          function computeProperties(ellipsoidGeodesic, start, end, ellipsoid) {
              var firstCartesian = Cartesian3.normalize(ellipsoid.cartographicToCartesian(start, scratchCart2), scratchCart1);
              var lastCartesian = Cartesian3.normalize(ellipsoid.cartographicToCartesian(end, scratchCart2), scratchCart2);
          
              //>>includeStart('debug', pragmas.debug);
              Check.typeOf.number.greaterThanOrEquals('value', Math.abs(Math.abs(Cartesian3.angleBetween(firstCartesian, lastCartesian)) - Math.PI), 0.0125);
              //>>includeEnd('debug');
          
              vincentyInverseFormula(ellipsoidGeodesic, ellipsoid.maximumRadius, ellipsoid.minimumRadius,
                                     start.longitude, start.latitude, end.longitude, end.latitude);
          
              ellipsoidGeodesic._start = Cartographic.clone(start, ellipsoidGeodesic._start);
              ellipsoidGeodesic._end = Cartographic.clone(end, ellipsoidGeodesic._end);
              ellipsoidGeodesic._start.height = 0;
              ellipsoidGeodesic._end.height = 0;

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!

Scott_Hunter · January 2, 2019, 9:06pm

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

Nathan_Schulte · January 3, 2019, 6:11am

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.