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 Fri, 19 Jan 2018 21:56:00 GMT

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

Charles Karney edited comment on SIS-386 at 1/19/18 9:55 PM:
-------------------------------------------------------------

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
interface|https://geographiclib.sourceforge.io/html/C/geodesic_8h.html].
 # The Java implementation of GeographicLib is already deployed on Maven Central (I think!):
{code:xml}
<dependency>
    <groupId>net.sf.geographiclib</groupId>
    <artifactId>GeographicLib-Java</artifactId>
    <version>1.49</version>
</dependency>
{code}

 # 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 are 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.


was (Author: cffk):
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
interface|https://geographiclib.sourceforge.io/html/C/geodesic_8h.html].
# The Java implementation of GeographicLib is already deployed on Maven Central (I think!):
{code:xml}
<dependency>
    <groupId>net.sf.geographiclib</groupId>
    <artifactId>GeographicLib-Java</artifactId>
    <version>1.49</version>
</dependency>
{code}
# 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: 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