sis-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Desruisseaux (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SIS-386) Deprecate DefaultEllipsoid.orthodromicDistance(…) method
Date Thu, 18 Jan 2018 10:15:00 GMT

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

Martin Desruisseaux commented on SIS-386:
-----------------------------------------

I didn't knew that GeographicLib was included in Proj.4. This is an important information;
since we already have a {{sis-proj4}} module doing the binding, an obvious approach is to
extend this binding to geodetic calculations. It could be done for the next SIS release.

For the port to Java, we could use the Java implementation of GeographicLib as a dependency.
But it may not be in the SIS core since we try to reduce external dependencies in the core
parts (we can add dependencies more easily in extension modules). Furthermore SIS is deployed
on Maven Central, and libraries deployed on Maven Central are encouraged to avoid dependencies
deployed outside Maven Central.

Alternatively, would you allow us to port the Java implementation of GeographicLib to Apache
SIS? This would require relicensing from MIT/X11 to Apache 2 (only the code ported to SIS;
the original code is of course unaffected). GeographicLib would be referenced in the [NOTICE|https://svn.apache.org/repos/asf/sis/trunk/NOTICE]
file in the root directory. This would allow us to integrate this code in the core of {{sis-referencing}}
module and to apply the following modifications:

* Replace some {{GeoMath}} methods by Java 8 {{Math}} methods (e.g. {{hypot}}, {{log1p}},
{{copysign}}, {{cbrt}}, {{atan2}}, {{isFinite}} with strong guarantees on accuracy and some
hardware accelerations). For example {{GeoMath.sincosd(double)}} refines sin / cos calculations,
reducing the range to [-45° … 45°] range. This was required in C/C++ because the compiler
used directly the 80x287 instructions, which have known inaccuracy regarding sin / cos. But
Java already fixes that with its own argument reduction (which is why Java sin / cos are slightly
slower than C/C++ sin / cos). {{Math.sin}} and {{Math.cos}} are guaranteed to be within 1
ULP of the exact mathematical answer for all argument values.
* Replace {{Constants}} by use of values provided by OGC/ISO {{Ellipsoid}} data structure
(e.g. provided by EPSG geodetic database).
* Replace {{Accumulator}} by Java 8 {{DoubleAccumulator}} (it also uses double-double arithmetic).
* Refactor {{Gnomonic}} as a SIS map projection (would allow integration with all the SIS
referencing engine, e.g. concatenation with other operations, Well Known Text, GML, _etc._).
* Stronger encapsulation (current Java implementation exposes all internal states as public
variables).

Would the above be acceptable?


> 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