[
https://issues.apache.org/jira/browse/SIS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux updated SIS-467:
------------------------------------
Description:
The {{GeodesicOnEllipsoid}} class tries to implement the equations published in
Charles F. F. Karney, 2013, [Algorithms for
geodesics|https://doi.org/10.1007/s00190-012-0578-z] (SRI International),
completed by Karney 2011, [Geodesics on an ellipsoid of
revolution|https://arxiv.org/pdf/1102.1215.pdf]. Those algorithms were already
implemented in [GeographicLib|https://geographiclib.sourceforge.io/], which we
use as a reference implementation in our tests but not in the main code in
order to keep the amount of Apache SIS dependencies low. We also want close
integration with the rest of SIS framework (automatic conversion of
input/output coordinates), keep some intermediate values for computing Bezier
curves, _etc._ However our current implementation has the following limitations
(maybe because of misunderstanding on our side). The GeographicLib source code
may be examined for understanding what we are doing wrong, but the
relationships between that source code and the formulas are not easy to
establish.
h2. Points at poles
In {{computeEndPoint()}}, calculation of ω2 and azimuth become indeterminate at
the poles, where sin α₀ = cos σ = 0. Karney "ensures that ω (and hence λ) and α
are consistent with their interpretation for a latitude very close to the pole
(i.e., cos β is a small positive quantity) and that the direction of the
geodesic in three-dimensional space is correct", but we have not identified how
he does that exactly.
h2. Nearly antipodal geodesics on equator
Apache SIS does not have a solution for geodesics on equator when the
difference of longitude is ∆λ > (1 - _f_)⋅π (close to 180°). This issue is
discussed in Karney (2013) below equation 44, but we have not yet understood
what is the appropriate action. Even if equation 57 can be use for computing α₁
in such case, we still have equations 11 and 12, for example σ = atan2(sinβ,
cosα⋅cosβ), producing 0 because sin β = 0, which result in a geodesic distance
of 0. We surely do something wrong, but I haven't understood what yet. Current
SIS implementation throws {{GeodesicException}} in such case.
h2. Extra-terrestrial ellipsoid
Current implementation is tested on WGS84 ellipsoid. Prolate ellipsoids or
[ellipsoids with high
eccentricities|https://issues.apache.org/jira/browse/SIS-465] have not been
tested. There is some special cases in GeographicLib source code for those
kinds of ellipsoids, but not yet in SIS.
h2. Possible optimizations
In {{createGeodesicPath2D}}, since we only need points which are approximately
evenly spaced on the geodesic, we could replace ∆s distance by ∆σ arc length on
the auxiliary sphere. It would avoid the conversion from τ to σ.
was:
The {{GeodesicOnEllipsoid}} class tries to implement the equations published in
Charles F. F. Karney, 2013. [Algorithms for
geodesics|https://doi.org/10.1007/s00190-012-0578-z], SRI International. Those
algorithms were already implemented in
[GeographicLib|https://geographiclib.sourceforge.io/], which we use as a
reference implementation in our tests but not in the main code in order to keep
the amount of Apache SIS dependencies low. We also want close integration with
the rest of SIS framework (automatic conversion of input/output coordinates),
keep some intermediate values for computing Bezier curves, _etc._ However our
current implementation has the following limitations (maybe because of
misunderstanding on our side). The GeographicLib source code may be examined
for understanding what we are doing wrong, but the relationships between that
source code and the formulas are not easy to establish.
h2. Nearly antipodal geodesics on equator
Apache SIS does not have a solution for geodesics on equator when the
difference of longitude is ∆λ > (1 - _f_)⋅π (close to 180°). This issue is
discussed in Karney (2013) below equation 44, but we have not yet understood
what is the appropriate action. Even if equation 57 can be use for computing α₁
in such case, we still have equations 11 and 12, for example σ = atan2(sinβ,
cosα⋅cosβ), producing 0 because sinβ = 0, which result in a geodesic distance
of 0. We surely do something wrong, but I haven't understood what yet. Current
SIS implementation throws {{IllegalStateException}} in such case.
h2. Extra-terrestrial ellipsoid
Current implementation is tested on WGS84 ellipsoid. Prolate ellipsoids or
[ellipsoids with high
eccentricities|https://issues.apache.org/jira/browse/SIS-465] have not been
tested. There is some special cases in GeographicLib source code for those
kinds of ellipsoids, but not yet in SIS.
> Unsupported geodesics
> ---------------------
>
> Key: SIS-467
> URL: https://issues.apache.org/jira/browse/SIS-467
> Project: Spatial Information Systems
> Issue Type: Bug
> Components: Referencing
> Affects Versions: 1.0
> Reporter: Martin Desruisseaux
> Priority: Major
>
> The {{GeodesicOnEllipsoid}} class tries to implement the equations published
> in Charles F. F. Karney, 2013, [Algorithms for
> geodesics|https://doi.org/10.1007/s00190-012-0578-z] (SRI International),
> completed by Karney 2011, [Geodesics on an ellipsoid of
> revolution|https://arxiv.org/pdf/1102.1215.pdf]. Those algorithms were
> already implemented in [GeographicLib|https://geographiclib.sourceforge.io/],
> which we use as a reference implementation in our tests but not in the main
> code in order to keep the amount of Apache SIS dependencies low. We also want
> close integration with the rest of SIS framework (automatic conversion of
> input/output coordinates), keep some intermediate values for computing Bezier
> curves, _etc._ However our current implementation has the following
> limitations (maybe because of misunderstanding on our side). The
> GeographicLib source code may be examined for understanding what we are doing
> wrong, but the relationships between that source code and the formulas are
> not easy to establish.
> h2. Points at poles
> In {{computeEndPoint()}}, calculation of ω2 and azimuth become indeterminate
> at the poles, where sin α₀ = cos σ = 0. Karney "ensures that ω (and hence λ)
> and α are consistent with their interpretation for a latitude very close to
> the pole (i.e., cos β is a small positive quantity) and that the direction of
> the geodesic in three-dimensional space is correct", but we have not
> identified how he does that exactly.
> h2. Nearly antipodal geodesics on equator
> Apache SIS does not have a solution for geodesics on equator when the
> difference of longitude is ∆λ > (1 - _f_)⋅π (close to 180°). This issue is
> discussed in Karney (2013) below equation 44, but we have not yet understood
> what is the appropriate action. Even if equation 57 can be use for computing
> α₁ in such case, we still have equations 11 and 12, for example σ =
> atan2(sinβ, cosα⋅cosβ), producing 0 because sin β = 0, which result in a
> geodesic distance of 0. We surely do something wrong, but I haven't
> understood what yet. Current SIS implementation throws {{GeodesicException}}
> in such case.
> h2. Extra-terrestrial ellipsoid
> Current implementation is tested on WGS84 ellipsoid. Prolate ellipsoids or
> [ellipsoids with high
> eccentricities|https://issues.apache.org/jira/browse/SIS-465] have not been
> tested. There is some special cases in GeographicLib source code for those
> kinds of ellipsoids, but not yet in SIS.
> h2. Possible optimizations
> In {{createGeodesicPath2D}}, since we only need points which are
> approximately evenly spaced on the geodesic, we could replace ∆s distance by
> ∆σ arc length on the auxiliary sphere. It would avoid the conversion from τ
> to σ.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
