sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <>
Subject [jira] [Commented] (SIS-386) Deprecate DefaultEllipsoid.orthodromicDistance(…) method
Date Sat, 20 Jan 2018 14:52:00 GMT


Martin Desruisseaux commented on SIS-386:

Indeed, [GeographicLib is deployed on Maven Central|].
I didn't realized that, thanks for pointing that out. It gives us the choice between using
it as a direct dependency, or if the code is integrated in the core of Apache SIS we would
still use {{net.sf.geographiclib}} as a reference implementation in the test suite.

Talking about tests, we have GeoAPI which is an OGC project. GeoAPI tries to define (among
other things) some tests in an implementation-neutral way. For example I have been able to
run [those tests|]
on both Proj.4 and Apache SIS. GeoAPI currently uses [Geospatial Integrity of Geoscience Software
(GIGS)|] data for tests, but I saw that GeographicLib provides
many other test data. Integration those test data into GeoAPI as well as GeographicLib as
a reference implementation is something I would like to explore, if you agree. It would reach
a wider audience than using them in Apache SIS only (SIS uses GeoAPI). If we go that way,
we could create a separated thread for this discussion.

Thanks also for pointing to the GeographicLib documentation in Proj.4. It will probably be
our first approach.

About stipulating that GeographicLib-Java needs a certain minimum version of Java, it seems
to be already done in the {{pom.xml}} file that describe the Maven project. The {{<java.version>}}
property is set to 1.6.

About the guarantees provided by {{GeoMath.sincosd}}, the replacement by {{Math.sin}} and
{{Math.cos}} may indeed break some identities. But the way Java mathematical functions are
defined, we have the guarantee that the difference between cos(89°) and sin(1°) will not
be greater than 2 ULP. Whether it would be sufficient or not, I do not know.

About latitude and longitude ranges, I agree about the rules that you stated. I think that
most of SIS referencing engine applies the same rules, except {{DistanceUtils}} which I see
more like a legacy class. For example the Mercator projection code also sets latitude outside
[-90° … 90°] range to NaN and uses longitude as-is even if outside [-180° … 180°]
range, for the same reason as you stated.

About Java {{DoubleAccumulator}}, it is true that the documentation said nothing about accuracy,
but its implementation actually uses double-double arithmetic. However the fact that it is
not stated in the documentation means that we should not take this implementation details
as granted. The note about numerical stability means that running the same code with the same
data twice may produce two slightly different results. In practice this is true only if data
are sent to {{DoubleAccumulator}} in parallel by two or more threads, since the numbers could
be added in different order (A + B + C may not be strictly equals to A + C + B in IEEE 754
arithmetic). But this problem affects any accumulator using IEEE 754 arithmetic, not only
{{DoubleAccumulator}}. The use of double-double arithmetic reduce or delay the problem, but
does not eliminate it.

GeographicLib {{Accumulator}} may perform more tasks than {{DoubleAccumulator}}, in which
case the later may not be a suitable replacement for the former. We would need to take a closer

By "stronger encapsulation", I mean reduce the number of public methods or fields. Everything
we make public is like a promise we do to the users; we promise to not change the name, parameters,
result, signature or behavior (except bug fixes). If a field or method is unlikely to be useful
to most users, we are better to keep it private in order to it leaves more freedom for modifying
it later. In case of doubt for a given field or method, the recommendation is to keep it private
on the basis that it is much easier to open an API later (declare public something that was
previously private) than to fix something that was wrong but prematurely released as public

> 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