sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Karney (JIRA)" <>
Subject [jira] [Commented] (SIS-386) Deprecate DefaultEllipsoid.orthodromicDistance(…) method
Date Fri, 19 Jan 2018 21:53:00 GMT


Charles Karney commented on SIS-386:

Any of these approaches is fine with me...
# use Proj.4.  See geodesic(3) for a quick summary of the API.  Here is the [application programming
# The Java implementation of GeographicLib is already deployed on Maven Central (I think!):
# Incorporation and refactoring the Java implementation is also fine.  On this:
## How do I stipulate that GeographicLib-Java needs a certain minimum version of Java?  I'd
love to get rid of my work-alikes for log1p, etc.
## Note that GeoMath.sincosd does something that sin/cos doesn't do, namely to guarantee identities
such as sin(7200°) == 0, cos(89°) == sin(1°), etc.  This means that a geodesic starting
on the equation with an azimuth of 90° exactly tracks the equator.
## Note too that my rules about legal latitudes and longitudes is different from SIS.  Latitudes
outside [-90°, 90°] are converted to NaNs (the expectation is that a front-end will check
and complain about bad latitudes).  There is no restriction on longitude values. Don't forget
that with longitudes in degrees, range reduction is exact.  Furthermore, you can ask that
the result longitude not be mapped back to [-180°, 180°]; this is useful if you want to
know how many times a long geodesic wrapped around the globe.
## The documentation for DoubleAccumulator says nothing about improving the accuracy.  On
the contrary it says "this class may not be applicable if numerical stability is required,
especially when combining values of substantially different orders of magnitude."  (The documentation
suggests that the "value added" is thread safety with parallel accumulations.)
## One feature that my Accumulator offers, that I don't see in DoubleAccumulator, is the ability
to tentatively add and test a value to the accumulator.  This supports a continuous readout
of, e.g., polyline length as the user moved an endpoint around.
## I'd be happy to learn what "stronger encapsulation" entails. Perhaps I'll back-port your
work into GeographicLib-Java.

> Deprecate DefaultEllipsoid.orthodromicDistance(…) method
> --------------------------------------------------------
>                 Key: SIS-386
>                 URL:
>             Project: Spatial Information Systems
>          Issue Type: Bug
>          Components: Referencing
>    Affects Versions: 0.4, 0.5, 0.6, 0.7, 0.8
>            Reporter: Martin Desruisseaux
>            Priority: Major
>             Fix For: 1.0
> The {{DefaultEllipsoid.orthodromicDistance}} method has the following problems:
> * Could have a better name.
> * It does not converge in some situations.
> * The wraparound over some non-convergence problems is itself erroneous.
> Charles Karney kindly listed the problems [on the developer mailing list|].
A possible action would be to deprecate {{orthodromicDistance}}, to be replaced by the same
{{GeodeticCalculator}} (or any other name) class than the one proposed for SIS-385.
> *Historical note:* {{orthodromicDistance}} was defined in the {{DefaultEllipsoid}} class
because it made easy to override the method with code optimized for the spherical case. A
future version could also override the method with code for triaxial ellipsoid. But experience
in the Geotk project suggest that this method is almost never used, since {{GeodeticCalculator}}
is used instead.
> As an alternative to deprecate {{DefaultEllipsoid.orthodromicDistance}}, we could keep
it (after renaming), fix the issues identified by Charles, and design {{GeodeticCalculator}}
as a class that use {{DefaultEllipsoid}} under the hood instead than re-implementing its own

This message was sent by Atlassian JIRA

View raw message