Doing some research to replace the functions I use in ArcObjects. I ran some minor tests and GeoLib showed that it was a great replacement. To fully convince myself I then ran about a half-million cases with a random start point and a random end point. All looks good but this one case stuck out. The first case is to show that I am running the process correctly. The second case is the one that looks dubious. Granted it is a path that goes half way around the world so maybe that’s the issue. I am using ArcObjects as the baseline only because that is what I have been using for years.
All calculations run with WGS84. Great Circle is with f=0 and geodesic is the standard spheroid. Gavaghan is a freeware geodesy library http://www.gavaghan.org/blog/free-source-code/geodesy-library-vincentys-formula/, GeoLib Std is NETGeographicLib.Geodesic, GeoLib Exc is NETGeographicLib.GeodesicExact, and ArcObjects is using the ArcGIS Military Analyst API class IMeasurementTool.
Great Circle has great agreement. Geodesic is where I saw the disparity in Case 2. GeoLib<->ArcObjects there is a delta of 38078.8 and Gavaghan<->ArcObjects there is a delta of 60120.0. I am probably doing something wrong but would appreciate any thoughts on this subject.
------------------------------------------------
Case 1
Start: x=-175.000000000000000, y=45.000000000000000
End : x=172.000000000000000, y=47.000000000000000
Great Circle Geodesic
Gavaghan : 1028334.05 1029963.12
GeoLib Std: 1028334.05 1029963.12
GeoLib Exc: 1028334.05 1029963.12
ArcObjects: 1028334.05 1029963.12
------------------------------------------------
Case 2
Start: x=-161.447217064652000, y=-07.945383422982600
End : x=017.952566164523600, y=07.769422129620540
Great Circle Geodesic
Gavaghan : 19968482.25 19981880.01
GeoLib Std: 19968482.25 19959838.73
GeoLib Exc: 19968482.25 19959838.73
ArcObjects: 19968482.25 19921759.97
------------------------------------------------
Thanks
~AGP
Last edit: AGP 2017-05-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The GeographicLib results are correct! One thing to try is to check the ArcObjects result
by solving the direct problem with ArcObjects using the same start position and ArcObjects'
distance and azimuth.
Ok so I ran the study with my start point and the distance and azimuth given by GeoLib. The results show that on direct problem they all are fairly accurate with GeoLib being accurate to the 13th decimal of end coordinates. Do the direct and inverse problems use different algorithms but based on the same premise? I just don’t get why the disparity in distance is so large.
Gavaghan------------------------------- Expected Delta
Start Point Longitude -161.447217064652000 degrees
Start Point Latitude -7.945383422982590 degrees
Ellipsoidal Distance 19959838.727419400000000 meters
Azimuth 134.901274703379000 degrees
End Point Longitude 17.952566163824700 degrees 17.952566164523600 0.000000000698900
End Point Latitude 7.769422129620720 degrees 7.769422129620540 -0.000000000000180
GeographicLib--------------------------
Start Point Longitude -161.447217064652000 degrees
Start Point Latitude -7.945383422982600 degrees
Ellipsoidal Distance 19959838.727419400000000 meters
Azimuth 134.901274703379000 degrees
End Point Longitude 17.952566164523300 degrees 17.952566164523600 0.000000000000298
End Point Latitude 7.769422129620290 degrees 7.769422129620540 0.000000000000250
ArcObjects-----------------------------
Start Point Longitude -161.447217064652000 degrees
Start Point Latitude -7.945383422982600 degrees
Ellipsoidal Distance 19959838.727419400000000 meters
Azimuth 134.901274703379000 degrees
End Point Longitude 17.952566163824700 degrees 17.952566164523600 0.000000000698900
End Point Latitude 7.769422129620720 degrees 7.769422129620540 -0.000000000000180
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gavaghan uses Vincenty; this uses the same basic formulas for the direct
and inverse problems. My guess is the ArcObjects does the same based on
the fact that the direct calculations coincide. They get different
results for the inverse problem, presumably because they have different
criteria for ending the algorithm.
The fact that they all basically agree on the solution to the direct
problem demonstrates that the inverse solutions for Gavaghan and
ArcObjects are wrong.
The problem is that Vincenty fails to converge for your chosen points.
It's not just a question of needing to increase the number of
iterations. The basic iterative scheme is unstable. Gavaghan sets the
iteration count to 20 and returns whatever the result is at that point.
Possibly ArcObjects does the same (but with a different iteration count).
If you paid good money to use ArcObjects then I recommend that you
complain loudly and tell them to use GeographicLib. (It's under the MIT
license, so they don't have to pay me or even to ask my permission.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK so re-reading some of the documentation I see that GeoLib uses an algorithm that resolves some of the issues with Vincenty. I also agree that ArcObjects most probably uses Vincenty with different tolerances.
I think GeoLib from the start was going to be the replacement library of my choice but had to convince myself that it was accurate. I also needed a study that would show disparities with other libraries and an explanation of why they existed. I am fully convinced that GeoLib gives the correct answer.
As for the ESRI product, that particular library was deprecated many years ago. Thus why I have been searching for a replacement. Once I implement GeoLib I can move forward to upgrade the version of ArcGIS on our desktops. However, they still have other libraries that provide geodesics. My plan is to run the same type of tests. Once that is done I will provide the results to ESRI and also post them here.
Many, many thanks for your hard work on this library. It has helped me in ways you cannot even imagine.
Abel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doing some research to replace the functions I use in ArcObjects. I ran some minor tests and GeoLib showed that it was a great replacement. To fully convince myself I then ran about a half-million cases with a random start point and a random end point. All looks good but this one case stuck out. The first case is to show that I am running the process correctly. The second case is the one that looks dubious. Granted it is a path that goes half way around the world so maybe that’s the issue. I am using ArcObjects as the baseline only because that is what I have been using for years.
All calculations run with WGS84. Great Circle is with f=0 and geodesic is the standard spheroid. Gavaghan is a freeware geodesy library http://www.gavaghan.org/blog/free-source-code/geodesy-library-vincentys-formula/, GeoLib Std is NETGeographicLib.Geodesic, GeoLib Exc is NETGeographicLib.GeodesicExact, and ArcObjects is using the ArcGIS Military Analyst API class IMeasurementTool.
Great Circle has great agreement. Geodesic is where I saw the disparity in Case 2. GeoLib<->ArcObjects there is a delta of 38078.8 and Gavaghan<->ArcObjects there is a delta of 60120.0. I am probably doing something wrong but would appreciate any thoughts on this subject.
------------------------------------------------ Case 1 Start: x=-175.000000000000000, y=45.000000000000000 End : x=172.000000000000000, y=47.000000000000000 Great Circle Geodesic Gavaghan : 1028334.05 1029963.12 GeoLib Std: 1028334.05 1029963.12 GeoLib Exc: 1028334.05 1029963.12 ArcObjects: 1028334.05 1029963.12 ------------------------------------------------ Case 2 Start: x=-161.447217064652000, y=-07.945383422982600 End : x=017.952566164523600, y=07.769422129620540 Great Circle Geodesic Gavaghan : 19968482.25 19981880.01 GeoLib Std: 19968482.25 19959838.73 GeoLib Exc: 19968482.25 19959838.73 ArcObjects: 19968482.25 19921759.97 ------------------------------------------------
Thanks
~AGP
Last edit: AGP 2017-05-05
The GeographicLib results are correct! One thing to try is to check the ArcObjects result
by solving the direct problem with ArcObjects using the same start position and ArcObjects'
distance and azimuth.
Perhaps you could also try the equivalent of
with Gavaghan and ArcObjects. (I.e., solve the direct problem using the distance
and azimuth found by GeographicLib.)
Last edit: Charles Karney 2017-05-06
Ok so I ran the study with my start point and the distance and azimuth given by GeoLib. The results show that on direct problem they all are fairly accurate with GeoLib being accurate to the 13th decimal of end coordinates. Do the direct and inverse problems use different algorithms but based on the same premise? I just don’t get why the disparity in distance is so large.
Gavaghan uses Vincenty; this uses the same basic formulas for the direct
and inverse problems. My guess is the ArcObjects does the same based on
the fact that the direct calculations coincide. They get different
results for the inverse problem, presumably because they have different
criteria for ending the algorithm.
The fact that they all basically agree on the solution to the direct
problem demonstrates that the inverse solutions for Gavaghan and
ArcObjects are wrong.
The problem is that Vincenty fails to converge for your chosen points.
It's not just a question of needing to increase the number of
iterations. The basic iterative scheme is unstable. Gavaghan sets the
iteration count to 20 and returns whatever the result is at that point.
Possibly ArcObjects does the same (but with a different iteration count).
If you paid good money to use ArcObjects then I recommend that you
complain loudly and tell them to use GeographicLib. (It's under the MIT
license, so they don't have to pay me or even to ask my permission.)
OK so re-reading some of the documentation I see that GeoLib uses an algorithm that resolves some of the issues with Vincenty. I also agree that ArcObjects most probably uses Vincenty with different tolerances.
I think GeoLib from the start was going to be the replacement library of my choice but had to convince myself that it was accurate. I also needed a study that would show disparities with other libraries and an explanation of why they existed. I am fully convinced that GeoLib gives the correct answer.
As for the ESRI product, that particular library was deprecated many years ago. Thus why I have been searching for a replacement. Once I implement GeoLib I can move forward to upgrade the version of ArcGIS on our desktops. However, they still have other libraries that provide geodesics. My plan is to run the same type of tests. Once that is done I will provide the results to ESRI and also post them here.
Many, many thanks for your hard work on this library. It has helped me in ways you cannot even imagine.
Abel
You're welcome! As you might imagine my work on GeographicLib is largely
a labor of love.