Azimuthal Equidistant spherical not as accurate as ellipsoidal #1654
Comments
rouault
added a commit
to rouault/PROJ
that referenced
this issue
Oct 3, 2019
…case when the point coordinates are super close to the origin (fixes OSGeo#1654)
rouault
added a commit
that referenced
this issue
Oct 4, 2019
aeqd: for spherical forward path, go to higher precision ellipsoidal case when the point coordinates are super close to the origin (fixes #1654)
backporting bot
pushed a commit
that referenced
this issue
Oct 4, 2019
…case when the point coordinates are super close to the origin (fixes #1654)
rouault
added a commit
that referenced
this issue
Oct 4, 2019
[Backport 6.2] aeqd: for spherical forward path, go to higher precision ellipsoidal case when the point coordinates are super close to the origin (fixes #1654)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tested on Proj 6.2.0.
echo -120.234501 30.234501 0 | ./src/.libs/proj +proj=aeqd +a=6371008.771415 +b=6371008.771415 +lat_0=30.2345 +lon_0=-120.2345
0.00 0.00 0
echo -120.234501 30.234501 0 | ./src/.libs/proj +proj=aeqd +a=6371008.771415 +b=6371008.7714149 +lat_0=30.2345 +lon_0=-120.2345
-0.10 0.11 0
In the first command we have a==b which seems to go through the spherical support in aeqd.cpp. In the second command, b is an epsilon smaller which triggers the ellipsoidal code path.
I would expect the first command to return something similar to the second one.
The text was updated successfully, but these errors were encountered: