sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charles Karney (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SIS-386) Deprecate DefaultEllipsoid.orthodromicDistance(…) method
Date Wed, 17 Jan 2018 15:39:05 GMT

    [ https://issues.apache.org/jira/browse/SIS-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16328875#comment-16328875
] 

Charles Karney edited comment on SIS-386 at 1/17/18 3:38 PM:
-------------------------------------------------------------

I recommend against [GeodeticCalculator|http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/GeodeticCalculator.html].
 It's based on the same Vincenty method currently used by SIS and has the same well-known
defect of failing to converge for some points.  Obvious choices are:

1. the [Java implementation of GeographicLib|https://repo1.maven.org/maven2/net/sf/geographiclib/GeographicLib-Java/];
2. the C implementation which is included in recent versions of [proj.4|http://proj4.org/].

Both of these options provide a full suite of geodesic calculations:

1. full accuracy solutions of inverse and direct problems;
2. rapidly computing points on a geodesic;
3. computing geodesic areas;
4. returning differential quantities for the adjustment of triangulation networks.

In addition, for the foreseeable future I can provide rapid and knowledgeable support for
this package.  This is something that has been notably absent for the Vincenty method (for
the last 20 years at least).

*NOTE:* GeodeticCalculator uses an [out-of-date version|ftp://ftp.ngs.noaa.gov/pub/pcsoft/for_inv.3d/source/inverse.for]
of the NGS routine inverse.for.  Here is the [latest version|https://www.ngs.noaa.gov/PC_PROD/Inv_Fwd/source/inverse.for].
 Unfortunately, although Dennis Milbert made the updates in 2011, they weren't posted until
2013.  However, this is all water under the bridge.  The 2011 updates only partially cure
the defects in Vincenty's method.  In fact, Dennis recommended that NGS replace its code with
a Fortran implementation of the my routines in GeographicLib.  However, due to institutional
inertia, this never happened.



was (Author: cffk):
I recommend against [GeodeticCalculator|http://www.geotoolkit.org/apidocs/org/geotoolkit/referencing/GeodeticCalculator.html].
 It's based on the same Vincenty method currently used by SIS and has the same well-known
defect of failing to converge for some points.  Obvious choices are:

1. the [Java implementation of GeographicLib|https://repo1.maven.org/maven2/net/sf/geographiclib/GeographicLib-Java/];
2. the C implementation which is included in recent versions of [proj.4|http://proj4.org/].

Both of these options provide a full suite of geodesic calculations:

1. full accuracy solutions of inverse and direct problems;
2. rapidly computing points on a geodesic;
3. computing geodesic areas;
4. returning differential quantities for the adjustment of triangulation networks.

*NOTE:* GeodeticCalculator uses an [out-of-date version|ftp://ftp.ngs.noaa.gov/pub/pcsoft/for_inv.3d/source/inverse.for]
of the NGS routine inverse.for.  Here is the [latest version|https://www.ngs.noaa.gov/PC_PROD/Inv_Fwd/source/inverse.for].
 Unfortunately, although Dennis Milbert made the updates in 2011, they weren't posted until
2013.  However, this is all water under the bridge.  The 2011 updates only partially cure
the defects in Vincenty's method.  In fact, Dennis recommended that NGS replace its code with
a Fortran implementation of the my routines in GeographicLib.  However, due to institutional
inertia, this never happened.


> Deprecate DefaultEllipsoid.orthodromicDistance(…) method
> --------------------------------------------------------
>
>                 Key: SIS-386
>                 URL: https://issues.apache.org/jira/browse/SIS-386
>             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|https://lists.apache.org/thread.html/eee29fc53123e94b74c22737413b2572d3e4c9e4f111847fefb6a3af@%3Cdev.sis.apache.org%3E].
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
algorithm.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message