Talk:Great-circle distance

WikiProject Mathematics (Rated Start-class, Low-priority)
This article is within the scope of WikiProject Mathematics, a collaborative effort to improve the coverage of Mathematics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Mathematics rating:
 Start Class
 Low Priority
Field: Geometry
WikiProject Geography (Rated Start-class)
This article is within the scope of WikiProject Geography, a collaborative effort to improve the coverage of geography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start  This article has been rated as Start-Class on the project's quality scale.
???  This article has not yet received a rating on the project's importance scale.

Page name

Why is "spherical distance" a better name for this page than great circle distance, which has now been made a redirect page? Is it not standard to speak of "great circle distance"? Michael Hardy 21:26, 5 Oct 2004 (UTC)

I agree, I think the page has been made, while perhaps mathematically correct, harder to understand by introducing the formulas using spherical coordinates instead of latitude and longitude.

I think it's wise to at least break it up into two sections, one for the math principals behind it, and one for a practical use case (latitude and longitude to find distance).

I always intended for it to be easy to understand. --JeremyCole 17:34, Oct 16, 2004 (UTC)

The article says:

Consider a sphere of radius r centered at the origin. That is, the set of all points (x1, x2, x3) such that
$x_1^2 + x_2^2 + x_3^2 = r^2$
The spherical distance between any two points x and y on this sphere is given by
$d(x,y) = r \cos^{-1}\left(\frac{x_1 y_1 + x_2 y_2 + x_3 y_3}{r^2}\right).$

Why is this of interest? The spherical distance is r times the angle (in radians). That seems to be the main point. The dot product over r2 is the cosine of the angle. Taking the arccosine of the cosine, after using a needlessly complicated expression for the cosine, when one could have said simply "The spherical distance is r times the angle (in radians)" would be more to the point. Michael Hardy 23:48, 16 Oct 2004 (UTC)

It's useful if you want to see a derivation of the spherical distance formula. You start with your statement (d = r times the angle) then solve for the angle in terms dot product, which leads to the above formula. Then just plug in your favorite spherical coordinates to arrive at the final formula. -- Fropuff 01:27, 2004 Oct 17 (UTC)

Proof ?

Is it possible to give a proof that it is really a distance ? it has to satisfy these three conditions

acos(P.Q)=0 <=> P=Q
acos(P.Q)=acos(Q.P)
acos(P.Q)<=acos(P.M)+acos(M.Q)

The first two are trivial and the triangle inequality can be shown from the cosines rules of sides (see Haversine formula)

Note that the distance (ab is the same as the angle <AOB on the unit sphere)

The cosines rules of sides states that for a spherical triangle ABC

cos(ac)=cos(ab)cos(bc)+sin(ab)sin(bc)cos(<ABC)

Given that -1<=cos(<ABC)<=1

cos(ac)>=cos(ab)cos(bc)-sin(ab)sin(bc)=cos(ab+bc)

Given that acos is strictly decreasing

We get ac<=ab+bc that is <AOC <= <AOB +<BOC

Sorry for the syntax !

Polar vs. equatorial (meridional) arcradius

The meridional (vertical, north-south) arcradius ("radius of curvature") variation is relatively inverse to the radius. This is easy to visualize: Picture the transverse equator of an oblate spheroid——i.e., the facing, horizonal meridian (viewed as 2-D, it would be the perimeter of the ellipse). At the poles, where the radius (b) is less than at the equator (a), the arcradius flattens, meaning the "per unit radius of curvature" is greater than the vertical, chordial radius. Conversely, at the equator, where the horizontal radius spreads out, the vertical arc squeezes closer together, so that the per unit value is less than the horizontal radius (which equals the horizontal arcradius, since the equator is a great circle). The actual vertical values are $\frac{b^2}{a}\,\!$ at the equator and $\frac{a^2}{b}\,\!$ at the poles.  ~Kaimbridge~17:27, 12 January 2006 (UTC)

The following comments relate to the "Spherical distance on the Earth" section.
Why not state the simple polar and equatorial radii instead of giving the "radius of curvature" at a pole and the equator?
How would one who is interested in great-circle distances on a spherical Earth use a "radius of curvature"? Why would they distinguish between common (geodetic or geographic) latitude and geocentric latitude?
The "average great-circle radius" is linked to "ellipsoidal quadratic mean radius", which is calculated using the simple polar and equatorial radii.
The mean radius given in the link is 6,372.7976 km (˜3,959.873 mi; ˜3,441.035 nmi), which differs slightly from the value 6372.795 km in the "Spherical distance on the Earth" section.
I suggest including the "statute mile" value for the average radius in this article. Most landlubbers have little occasion to use nautical miles, though they may still be interested in great-circle distances. -Ac44ck (talk) 15:28, 24 October 2008 (UTC)
The thing is, the mean radius and arcradius along the conjugate (north-south) meridian from equator to pole are the same, about 6367.449. But, they are based on two different sets of endpoint values: a, b for the radius and b^2/a, a^2/b for the arcradius. Using the given a and b values,
b^2/a ≈ 6335.439; a^2/b ≈ 6399.594;
(lat=45°) mid radius ≈ 6367.418; mid arcradius ≈ 6367.382;
(a^2/2+b^2/2)^.5 ≈ 6367.454;
(6335.439^2/2+6399.594^2/2)^.5 ≈ 6367.597;
(a^2/3+6367.418^2/3+b^2/3)^.5 ≈ 6367.441;
(6335.439^2/3+6367.382^2/3+6399.594^2/3)^.5 ≈ 6367.435;
Since the spread between the boundaries is greater for the arcradii than for the radii, averaging takes longer, so using a and b for the two point average is closer to the actual average, however, the b^2/a and a^2/b arcradii are the theoretically proper endpoints. For the whole average (not just the north-south conjugate) the average radius and arcradius are different, but the given ellipsoidal quadratic mean with just a and b are the desired elements. ~Kaimbridge~ (talk) 17:15, 24 October 2008 (UTC)
Thanks for the effort to explain. It appears that the "root mean square" is about the same for the actual radii and for the radii of curvature. It still isn't clear to my why values _derived from_ a and b _instead of_ a and b are used to introduce the mean radius if the "ellipsoidal quadratic mean with just a and b are the desired elements."
The values are presented in a section entitled "Spherical distance on the Earth". The radius of curvature is constant for a sphere. The polar and equatorial radii of a deformed sphere are measurable and easily envisioned. They can be used directly in arriving at an "average" radius.

Parametric equations?

I'm not good enough with my trigonometry, but perhaps someone else would be able to add in the conversions of the arcsine (and maybe even the arctan) solved for $\phi_1$ and $\lambda_1$ rather than the distance. That would be helpful if you know the distance, and you're looking for the point the satisfies it; that's the situation I'm in. I'm trying to draw a circle on a sphere, and so I know the distance (radius), but not the $(\phi, \lambda)$ coordinates of a point on the circle. MidnightLightning 21:50, 13 January 2006 (UTC)

Dot product

Might it be worthwhile pointing out that the dot product of two unit vectors is the cosine of the angle between them, and that great circle didtance can be computed in this way? —The preceding unsigned comment was added by Pmurray bigpond.com (talkcontribs) 04:26, 13 February 2006 (UTC)

I had that in here at one point (see top of this page), but it got taken out. People seem to prefer complicated formulas. -- Fropuff 04:54, 13 February 2006 (UTC)
Try an example (starting with latitude and longitude of the two points) and use the dot product to calculate the distance. The result won't be unbearably complicated, but it won't be any simpler/quicker than either the law-of-cosines formula or the haversine. Tim Zukas (talk) 18:50, 9 August 2010 (UTC)

Confusing discussion of relative errors

Previously, the article contained several overly-complicated equations and somewhat misleading discussion of the rounding errors. In particular, it gave six equations:

$\Delta\sigma=\arcsin\left\{\sqrt{\left[\cos\phi_2\sin\Delta\lambda\right]^2+\left[\cos\phi_1\sin\phi_2-\sin\phi_1\cos\phi_2\cos\Delta\lambda\right]^2}\right\},\,\!$
$=\arccos\left\{\sin\phi_1\sin\phi_2+\cos\phi_1\cos\phi_2\cos\Delta\lambda\right\},\,\!$
$=\arctan\left\{\frac{\sqrt{\left[\cos\phi_2\sin\Delta\lambda\right]^2+\left[\cos\phi_1\sin\phi_2-\sin\phi_1\cos\phi_2\cos\Delta\lambda\right]^2}}{\sin\phi_1\sin\phi_2+\cos\phi_1\cos\phi_2\cos\Delta\lambda}\right\};\,\!$

and

$=2\arcsin\left\{\sqrt{\sin\left\{\frac{\phi_2-\phi_1}{2}\right\}^2 +\cos{\phi_1}\cos{\phi_2}\sin\left\{\frac{\Delta\lambda}{2}\right\}^2}\right\},\,\!$
$=2\arccos\left\{\sqrt{\cos\left\{\frac{\phi_2-\phi_1}{2}\right\}^2-\cos{\phi_1}\cos{\phi_2}\sin\left\{\frac{\Delta\lambda}{2}\right\}^2}\right\},\,\!$
$=2\arctan\left\{\sqrt{\frac{\sin\left\{\frac{\phi_2-\phi_1}{2}\right\}^2+\cos{\phi_1}\cos{\phi_2}\sin\left\{\frac{\Delta\lambda}{2}\right\}^2}{\cos\left\{\frac{\phi_2-\phi_1}{2}\right\}^2-\cos{\phi_1}\cos{\phi_2}\sin\left\{\frac{\Delta\lambda}{2}\right\}^2}}\right\};\,\!$

Of these six, the two arccos versions are inaccurate for small distances due to rounding, but all of the other equations are almost equally accurate for most distances. In particular, the 2arcsin equation, the haversine formula, is perfectly fine for small distances; the article incorrectly stated that it was inaccurate — this would indeed be surprising, since the haversine formula was specifically created for use in navigation and has been used for almost two centuries.

(I wrote a quick C program to check the accuracy for various angles by comparing calculations in double and single precision). As far as I can tell, the haversine formula (the 2arcsin formula) has a very slight edge over the others in accuracy for small distances, which is not surprising since it requires fewer operations and has no fundamental instabilities in that regime.

The advantage of the arctan formula comes for large distances. In particular, for points on almost exactly opposite ends of the sphere, the haversine formula has rounding problems, but the arctan equation is still accurate. In fact, out of the six, it seems to be the only one that maintains high accuracy in all regimes.

I've edited that section of the article to only list the haversine (2arcsin) formula and the inaccurate-but-simple cosine formula, and the arctan formula. There are an infinite variety of other formulas, of course, thanks to trig identities, but I don't see any point to listing them if they have no accuracy or simplicity advantages.

—Steven G. Johnson 02:40, 2 March 2006 (UTC)

I'm the culprit who added the "overly-complicated equations"! P=)
First of all, the full "1arcsin", while the choice for small values, is unacceptable for general application because the result is found from a square root——thus it only recognizes the primary, 0-90°, quadrant! But, beyond its "small value" advantage (plus, you need it for 1arctan, anyways), its components have another major application——azimuth (α1):
$SA=\cos\phi_2\sin\Delta\lambda;\,\!$
$SB=\cos\phi_1\sin\phi_2-\sin\phi_1\cos\phi_2\cos\Delta\lambda;\,\!$

then

$\Delta\sigma=\arcsin\left(\sqrt{SA^2+SB^2}\right);\,\!$
$\alpha_1=\arctan\left(\frac{SA}{SB}\right).\,\!$
If you are just looking to consolidate appearance, you could redefine as sin(σ), cos(σ) and then define σ from arctan:
$\sin\Delta\sigma=\sqrt{\left[\cos\phi_2\sin\Delta\lambda\right]^2+\left[\cos\phi_1\sin\phi_2-\sin\phi_1\cos\phi_2\cos\Delta\lambda\right]^2};\,\!$
$\cos\Delta\sigma=\sin\phi_1\sin\phi_2+\cos\phi_1\cos\phi_2\cos\Delta\lambda;\,\!$
$\Delta\sigma=\arctan\left(\frac{\sin\Delta\sigma}{\cos\Delta\sigma}\right).\,\!$
But doing it that way upsets the formulatic continuity! P=|
As for the 2arcsin "small distance inaccuracy", yes it is relatively more error-prone. The "C" is just limited to single and double, but other programs/languages may be more flexible. I use UBasic, where precision can be defined to less than .11000!!! Using this little program,
  10 RF=#Pi/180
100 BLat=(81-0.1^13)*RF:DLat=(81+0.1^10)*RF:MD=0.1^9*RF
200 SA=cos(DLat)*sin(MD):SB=cos(BLat)*sin(DLat)-sin(BLat)*cos(DLat)*cos(MD)
1000 V1=asin((SA^2+SB^2)^0.5)/RF
1010 V2=acos(sin(BLat)*sin(DLat)+cos(BLat)*cos(DLat)*cos(MD))/RF
1020 V3=2*asin((sin(0.5*(DLat-BLat))^2+cos(BLat)*cos(DLat)*sin(0.5*MD)^2)^0.5)/RF
1030 V4=2*acos((cos(0.5*(DLat-BLat))^2-cos(BLat)*cos(DLat)*sin(0.5*MD)^2)^0.5)/RF
2000 ?"V1=";V1:?"V2=";V2:?"V3";V3:?"V4";V4

The last 4-5 decimals are always error-prone, so they will be ignored:
Point 15 (≈.172)
V1= 0.0000000001857195516152077495375701342520533447749318909192117752252
V2= 0.0000000001857195516152077495375701342520533447749318909192768034706
V3= 0.0000000001857195516152077495375701342520533447749318909191948355277
V4= 0.0000000001857195516152077495375701342520533447749318909199951831628

Point 12 (≈.157)
V1= 0.0000000001857195516152077495375701342520533427367852
V2= 0.0000000001857195516152077495375701342520533525926904
V3= 0.0000000001857195516152077495375701342520533372508105
V4= 0.0000000001857195516152077495375701342520535174730760

Point 7 (≈.133)
V1= 0.0000000001857195516127245757
V2= 0.0000000001857195516212353316
V3= 0.0000000001857195516110224245
V4= 0.0000000001857195517267687042


Point 5 (≈.124)

V1= 0.0000000001805150554
V2= 0.0000000002084408316
V3= 0.0000000001473899255
V4= 0.0000000004168816632

As you can see, V3 (2arcsin) isn't the best choice, in any case! P=) Granted, UBasic doesn't use floating point, so, yes, it will be more prone to error rounding (so just set the "point" value higher), but that means there are other programs (likely not precision adjustable) that are also susceptible. I don't have any fanatical obsession to include all of the different forms——so I won't run over and revert it P=)——I just think, if they are all known (sin, cos and tan) for a given equation version, then they all should be provided (some programs may only utilize arcsin or arccos or arctan). One thing I do want to revert is varphi to phi: Phi, rather than varphi, does seem to be the defacto standard: See Vincenty's formula(PDF))——just keep in mind, in this paper, $''\sigma''=\Delta\sigma\,\!$ (ellipsoidal, not spherical; likewise λ and α) while $\Delta\sigma\,\!$ is an ellipsoidal cosine multiple series complement for the binomial series expansion approximation.  ~Kaimbridge~16:03, 2 March 2006 (UTC)
Error comparisons in fixed-point are not very relevant in the real world, come on. Even very accurate methods can become horrendously innaccurate in fixed point if careful attention is not paid to scaling. Computer users these days will almost always employ floating point, and the historical users of manual tables would also use floating point (effectively). —Steven G. Johnson 17:48, 2 March 2006 (UTC)

Example gives incorrect result

It should be around 1562 miles, not 1794 as stated. Have a look at [1] if you don't believe me. Btyner 21:43, 11 October 2006 (UTC)

My bad, I was accidentally using nautical miles Btyner 21:55, 11 October 2006 (UTC)

Request for formula comparison

Would someone please provide a long/lat pair that demonstrates how each formula is progressively better? -- Myearwood 15:48, February 17, 2007

Look ↑two sections up↑, towards the end: $\phi_1\,\!$ = 80.9999999999999°, $\phi_2\,\!$ = 81.0000000001°, $\Delta\lambda\,\!$ = 0.000000001°. ~Kaimbridge~22:49, 17 February 2007 (UTC)

Calculator needed

Disappointingly, none of the external links on this article is to a site which lets users enter two sets of coordinates, then returns the distance between them. Do you know of such a site, or a freeware Windows utility, which does that? Andy Mabbett 11:43, 18 April 2007 (UTC)

Whoops, you're right! P=/
Okay, a couple added.  ~Kaimbridge~15:40, 18 April 2007 (UTC)
Thank you. I'm told Google Earth does it, too; and I've suggested that the functionality be added to Geo microformat parsers. Andy Mabbett 16:16, 18 April 2007 (UTC)
I've found a calculator and added it: http://www.wcrl.ars.usda.gov/cec/java/lat-long.htm Joost 99 12:34, 20 August 2007 (UTC)

I just stop to say that I hate the mathematical/too much formal aspect that much of wikipedia article took these days. By mathematicians, for mathematicians. If I want to know why the shortest path in a sphere is not a straight line, I'll have to understand the equations. I hope in the future you will add more pictures —Preceding unsigned comment added by 82.246.191.200 (talk) 04:52, 5 January 2008 (UTC)

EXCEL Formula

All credits to this page; I have used the formula mentioned on this page to come up with a simple distance calculating formula between the 2 points (WGS84).
=(2*ASIN(SQRT(POWER(SIN((D2/57-B2/57)/2),2)+COS(B2/57)*COS(D2/57)*POWER(SIN((E2/57-C2/57)/2),2))))*6000
Where:
B2 contains latitude (point-1)
C2 contains longitude (point-1)
D2 contains latitude (point-2)
E2 contains longitude (point-2) ... and you get the result in meters; this is the distance between the 2 points.
213.132.61.14 (talk) 11:09, 24 February 2008 (UTC)aqib razzaq

I don't know the particulars of EXCEL, but I see two problems right away:
• "57" should be $\scriptstyle{\frac{180^\circ}{\pi}}\,\!$, or 57.295779513...° (or better, its inverse: $\scriptstyle{\frac{\pi}{180^\circ}}\,\!$, or 0.0174532925199...);
• "6000" should be "6372.797556" km, or "6372797.556" meters;
Thus, let RF = π/180° and adjust the radius:
DxQm = 2 * 6372797.556 * ASIN(SQRT(POWER(SIN((D2-B2)*RF/2),2)+
COS(B2*RF)*COS(D2*RF)*POWER(SIN((E2-C2)*RF/2),2)))
~Kaimbridge~14:46, 24 February 2008 (UTC)

Problem with formula

As to the distance calculating formula:

${\color{white}\frac{\bigg|}{|}|}\Delta\widehat{\sigma}=\arctan\left(\frac{\sqrt{\left(\cos\phi_f\sin\Delta\lambda\right)^2+\left(\cos\phi_s\sin\phi_f-\sin\phi_s\cos\phi_f\cos\Delta\lambda\right)^2}}{\sin\phi_s\sin\phi_f+\cos\phi_s\cos\phi_f\cos\Delta\lambda}\right);\;\!$

I suspect that it gives wrong results for locations in different hemispheres. For instance, if you calculate the distance between Sydney $(\lambda_s = 151.2^\circ$, $\phi_s = -33.9^\circ)$ and Chicago $(\lambda_c = -87.6^\circ, \phi_c = 41.9^\circ)$, the outcome of the formula is -5139,3. Can someone clear this out? —Preceding unsigned comment added by 157.193.55.129 (talk) 08:29, 11 April 2008 (UTC)

I have no clue where you got that number! P=) I get $\Delta\widehat{\sigma}\approx133.829212^\circ\approx 2.33576\;\mbox{radians}\,\!$ or $\sin(\Delta\widehat{\sigma})\approx.72140725;\quad\cos(\Delta\widehat{\sigma})\approx-.69251107\,\!$, what about you?  ~Kaimbridge~13:16, 11 April 2008 (UTC) —Preceding unsigned comment added by Kaimbridge (talkcontribs)

VBA gives me $\Delta\widehat{\sigma}\approx -0.80583\;\mbox{radians}\,\!$. But I realize my mistake now, you have to add $\pi$ to make sure that $\Delta\widehat{\sigma} \in [0,\pi]\!$... —Preceding unsigned comment added by 157.193.55.129 (talk) 12:51, 15 April 2008 (UTC)

It seems like the above formula can not be correct. Its not symmetric relative to $\phi_s$ and $\phi_f$. If you reverse the 2 latitudes, you get completely different answers. —Preceding unsigned comment added by 139.169.209.65 (talk) 19:22, 19 June 2008 (UTC) ok, nm. Found my error —Preceding unsigned comment added by 139.169.209.65 (talk) 19:26, 19 June 2008 (UTC)

Worked-out example?

The example is not really worked out. It gets 0,45306 by using some angular difference/distance equation, but where are these? I calculated the distance with the spherical law of cosines and got nearly the desired result (1795), however with the harvesine equation I got 1785. So does "difference/distance equation" refer to the law of cosines?? --Jirka6 (talk) 18:53, 28 May 2008 (UTC)

Should be clearer now. But the haversine formula and law of cosines are mathematically equivalent, and will agree closer than that (1785 vs 1795) as long as your calculator has 8+ digits.Tim Zukas (talk) 18:01, 23 August 2010 (UTC)

Law of cosines?

The article says that the central angle $\Delta\widehat{\sigma}$ can be constituted from the spherical law of cosines, but I take issue with that claim. A spherical triangle connects three points with great circles, and while meridians are great circles, parallels (lines of constant latitude) are not.

Trying to solve this problem on my own, I attempted to use the spherical Pythagorean theorem:

$\cos \left(c\right)=\cos \left(a\right)\,\cos \left(b\right)$

This doesn't work because while a delta latitude is measured along a great circle, a delta longitude is not (except at the equator). The spherical law of cosines would work if delta latitude and delta longitude were two sides of a spherical triangle, but not necessarily a right triangle. While I wondered for a while if this could be true, I arrived at the conclusion that it is not.

I believe the math on this page is correct. The only thing I take issue with is the statement that the central angle $\Delta\widehat{\sigma}$ can be found using the spherical law of cosines. I'd love to have someone either back me up on that or help me understand what I'm missing. Butlertd (talk) 17:28, 10 November 2008 (UTC)

In terms of the notation in the law of cosines article, one simply considers the special case where u is the north pole, while v and w are the two points whose separation d is to be determined. In that case, a and b are π/2 - φ1,2 (i.e., 90° − latitude), C is the longitude separation Δλ, and c is the desired distance d/R or $\Delta\widehat{\sigma}$. Noting that sin(π/2 - φ) = cos(φ), the result follows. —Steven G. Johnson (talk) 00:53, 6 December 2008 (UTC)

Typos in FCC prescription?

Shouldn't what are found as multipliers on the ML actually be exponents on the cosines?

For example, shouldn't this formula:

$KPD_{LON} = 111.41513 \cos(ML) - 0.09455 \cos(3ML) + 0.00012 \cos(5ML)\,\!$

Actually be written as:

$KPD_{LON} = 111.41513 \cos(ML) - 0.09455 \cos^3(ML) + 0.00012 \cos^5(ML)\,\!$

I didn't find a source which shows the constants as exponents, but I don't see why the terms for variation in KPD should change in sign as mean latitude varies from 0 to 90 degrees. For example, cos(5*ML) is positive at ML = 10°; it is negative at ML = 30°. In contrast, (cos(ML))^5 doesn't become negative at any latitude. - Ac44ck (talk) 18:26, 4 December 2008 (UTC)

Nope, they are cosine multiples——those "KPD" equations are binomial series expansions of M and N (see my reply in Talk:Earth radius, including Rapp's Geometric Geodesy, as there is a whole section on this in pt.I, pg.9 P=).  ~Kaimbridge~ (talk) 18:50, 4 December 2008 (UTC)

approximate formulae seem pointless

Why is so much space devoted to crude Pythagorean approximations when exact formulas (on spheres) are available? Except possibly in very specialized applications, it's hard to believe that the computational savings of the approximate formula are relevant in practice today. It's not like anyone has to use slide rules or manually interpolate from trigonometric tables anymore.

—Steven G. Johnson (talk) 02:17, 5 December 2008 (UTC)

Comparison of formulae

Using the coordinates for the worked example, I get the following results:

Formula Distance in km
Vincenty formula 2886.449
Haversine 2886.449
Pythagorean with converging meridians 2899.2406
Flat-Earth polar coordinates 3350.0357
Pythagorean with parallel meridians 3536.5379

The "Pythagorean with converging meridians" result looks pretty good, but it didn't have to work very hard because the difference in latitude is small.- Ac44ck (talk) 02:44, 5 December 2008 (UTC)

I still don't understand why we are giving any of these crude approximations. A typical reader should just use the exact formulas for spheres; steering them towards the approximations seems like a disservice. —Steven G. Johnson (talk) 03:47, 5 December 2008 (UTC)
Maybe so. There seems to be agreement with that point of view here:
http://mathforum.org/library/drmath/view/54891.html
You can correct the Pythagorean theorem so that it becomes a better approximation by adjusting it for latitude, but it is basically just wrong and you shouldn't use it.
But that doesn't stop people from using it. In my searching, I found a number of web pages to give only the version for parallel meridians.
The formulae exist and the version which accounts for converging meridians comes pretty close for the sample problem, though it may not be a challenging test case.
A version of the Pythagorean formula can be "close enough" in some cases, and it seems more intuitive (thus easier to scan for typos in a spreadsheet formula) to me. A crude formula coded correctly may out-perform an exact formula with a typo.
http://www.louisepryor.com/showTopic.do?topic=31
Lawrence and Lee found that 30% of the spreadsheets they reviewed had errors in over 10% of unique formulae
The FCC _prescribes_ the use of what is essentially the Pythagorean theorem for distances less than 300 miles.
I agree that the approximations could be used inappropriately. But having a handy reference for them could be useful for someone who only needs to be in the ballpark and has to put something together quickly for short distances. -Ac44ck (talk) 05:37, 5 December 2008 (UTC)
♦ Given that the approximations are widely known and perhaps used, I think it's useful to document them, but we should also give appropriate caveats. --R27182818 (talk) 15:40, 5 December 2008 (UTC)
Please explain the circumstances where the FCC says that you should use the Pythagorean formula instead of the correct spherical formula (as opposed to instead of some other crappy Pythagorean approximation). If they do, it's probably because they are using the Pythagorean formula not to get correct distances but because of some legal baggage—if, in the past, some distances were computed with the Pythagorean formula for regulatory purposes, they might choose to continue to use the incorrect formula because they care about legal continuity more than accuracy. But this is a page about great-circle distances, not about FCC regulatory frameworks, and so I don't see why misleading equations from regulation belong here rather than correct mathematics.
We should say that there are Pythagorean approximations accurate for short distances, and link to the article on Euclidean distance metric, but we should also simply say that these become inaccurate for longer distances and there is no reason to use them when the accurate formula are available (given modern computers/calculators). When a mistake is common, we should point it out, but we shouldn't encourage it.
Your hypothetical person who needs to "put something together quickly for short distances" makes little sense; the exact formulae can be evaluated in nanoseconds by modern hardware. If your distances are large enough that you're expressing coordinates in terms of latitude and longitude, then it's silly not to use the exact formula.
People make typos in spreadsheets, but the exact equations are hardly so complicated as to exacerbate this substantially. (By the same logic, you could recommend that people use x rather than sin(x), since x is a valid approximation for small x and is simpler.) The problem is that determining whether a given approximation is accurate is much more complicated and error prone than checking for typos in an equation with a few extra terms. I don't know if you've noticed, but most people are terrible at error analysis.
It's also a question of balance; currently 1/3 of the article is spent on crappy approximations that most readers would be well-advised to avoid. This is ridiculous. —Steven G. Johnson (talk) 00:28, 6 December 2008 (UTC)
As this article is specifically about "great-circle" and not "short-line" distances, these approximations probably belong elsewhere. The discussions here and at Talk:Earth radius suggest to me that a "Geodetic formulae" article is needed. -Ac44ck (talk) 05:03, 6 December 2008 (UTC)
Maybe a better name for the new article would be "Terrestrial distance formulae", as any flat-Earth approximation ignores the actual shape of the earth, which is important in geodesy. This search:
indicated that it is a common phrase. This search:
didn't turn up a more compact name. -Ac44ck (talk) 06:22, 6 December 2008 (UTC)
Many more hits here:
So I created the "Geographic distance" article. -Ac44ck (talk) 19:11, 6 December 2008 (UTC)
Calculating distance is one of the two "principal problems of geodesy" (the other being finding a second set of coordinates, given one set and a distance and direction), so I was going to suggest either the "Inverse problem of geodesy" or (if it is going to be a presentation and comparison of different formulae) "Geodetic formulation" (or even, like Rapp's book, "Geometric geodesy"). But, given the direction of your first draft, "Geographic distance" seems okay——though I would suggest that that title be made a redirect, with the actual title being "Geographical distance".  ~Kaimbridge~ (talk) 02:13, 7 December 2008 (UTC)

Special case of Vincenty's formula

The comment was recently added that the version of Vincenty's formula in the article is a special case. What makes it a special case? Are there restrictions on the use of the version currently found in the article? -Ac44ck (talk) 04:58, 5 December 2008 (UTC)

Vincenty's results were a general iterative method to compute distances on ellipsoids. The formula in the article is for spheres only. —Steven G. Johnson (talk) 00:36, 6 December 2008 (UTC)
That paragraph should be reworked. There is nothing special about Vincenty's $\scriptstyle{\Delta\widehat{\sigma}}\,\!$, the sine valuation (which is what is "special") was used in Sodano's 1965 paper ("General Non-iterative Solution Of The Inverse And Direct Geodetic Problems"). Regarding "suffers from rounding errors for the special (and somewhat unusual) case of antipodal points (on opposite ends of the sphere)" is referring to the auxiliary, ellipsoidal version, $\scriptstyle{\Delta\tilde{\sigma}}\,\!$, found by using reduced latitudes, an auxiliary longitude difference (involving its own integral) and their transverse companions.  ~Kaimbridge~ (talk) 02:13, 7 December 2008 (UTC)

"Vector solution (non-singular)"

Can anyone see any point to this section? It seems to imply the customary law-of-cosines and haversine formulas won't work in certain cases; can anyone find a case where they don't?

The vector "solution" has no other advantage-- right? Tim Zukas (talk) 17:46, 10 August 2010 (UTC)

I think this section is relevant for several reasons:
• If one of the two positions is at one of the poles, longitude for that position is undefined, and thus delta-longitude is also undefined. The three first equations are all using delta-longitude, while the equations based on n-vector are well-defined also for polar positions.
• The equations based on vectors are simpler (shorter) to read, and are thus simpler to implement in program languages (where vector algebra is supported).
• The equations are intuitive (only based on simple vector algebra), and thus gives the reader an understanding of how they are obtained.
• In some applications the position is given as n-vector instead of lat/long, and then these equations can be used directly.
So, for the completeness of this article, I definitively think this section must be included. However, I agree that the current text implies that the other formulas won’t work in certain cases, without further specification. It should be changed to mention the undefined delta longitude (I can do this change). Isaac Euler (talk) 07:58, 11 August 2010 (UTC)
I think this section should be removed or at least substantially revised. It is:
• currently unreferenced - it is not a question of correctness, it is a question of whether these equations are used in practice by reputable sources. That is, is this formulation notable? (I'm guessing you can find sources that use this formulation, but the reader shouldn't need to speculate.)
• wrong: there doesn't appear to be any "singularity" in the latitude/longitude distance equations at the poles, at least not in any practical sense (nor in the usual mathematical sense of a divergence of the function or its derivatives). If one of the positions is at a pole (i.e. φ=±π/2 for one of the latitudes), then the corresponding cos(φ) term is zero so the longitude is irrelevant in the law-of-cosines or haversine formulas. (The longitude term also cancels in the arctan equation, but seeing this requires a step or two of algebra if φs=±π/2.) That is, if one point is at a pole, you can assign it any longitude whatsoever and it will not affect the distance. Hence there is no problem.
• ill-conditioned: the "vector" arccos formula has the same problem as the law-of-cosines formula for nearby points, in which it is sensitive to tiny roundoff errors in computing the dot product. I haven't checked the other two cases, but I suspect that the arcsin formula has problems with antipodal points similar to the haversine formula.
— Steven G. Johnson (talk) 17:48, 11 August 2010 (UTC)
Replies to your three bullets:
1: I agree, a reference should definitively be included. I saw this formulation in the latest issue of Journal of Navigation, and can add a reference to that paper.
2: The longitude and $\Delta\lambda\;\!$ are singular at the Poles per definition, but I agree that it is unclear whether equations using them as a factor is then also defined to be singular. Since this is unclear, I think the text “(non singular)” in the title should be removed, to avoid implying that the other formulas are singular.
I also agree that the lat/long formulas will work in practice if assigning any numerical value to longitude. However, in practice I have seen several implementations of longitude calculations that generate 0/0 at the poles, which for most program languages (following IEEE 754) deliver NaN. NaN multiplied with zero is also NaN, thus the great circle distance will not be calculated at the poles in these cases. So, these formulas may suffer from the singularity of longitude also in practical programming. In many cases, it is better to avoid going via lat/long in calculations, and find the n-vectors directly.
I agree that in the main article, the main points of the above discussion should be included. I will add this later today.
3: Yes, the problem with arccos for small angles will obviously be relevant for all equations based on arccos, and the solution with full accuracy in all quadrants should always be based on atan2. I fully agree that the comments about ill-conditioned arccos (and arcsin) should also be included for the three vector variants.
In addition, I think it is fair to show the readers that the great circle distance can also be calculated without going via latitude and longitude (and that the solution in that case is simple and intuitive). The readers can then decide themselves which formula they prefer for their specific implementation needs. For readers getting the position as n-vector (e.g. from a navigation system), it is not desirable to first have to calculate lat/long (with possible polar problems). For these readers a direct vector solution is preferable. Isaac Euler (talk) 09:49, 12 August 2010 (UTC)
Sure, if your starting point is x-y-z coordinates for each of the two points, then you might as well use the dot/cross product. But 99%? of readers are starting with lat-lons for the two points.
"I think it is fair to show the readers that the great circle distance can also be calculated without going via latitude and longitude (and that the solution in that case is simple and intuitive)." By all means show them how simple and intuitive it is: start with a pair of lat-lons and take the readers thru your method. Let them decide which is simpler. Tim Zukas (talk) 19:35, 13 August 2010 (UTC)
I agree that there are probably more readers using lat/long in their programs, than non-singular representations, but we should not forget that usage of non-singular representations is not insignificant, e.g.:
• In GPS-calculations (WP-ref), and in several branches of geodesy (WP-ref), the ECEF-vector (non-singular) is the dominant position representation, and then it is undesirable to go via a singular representation to calculate a great circle distance -- when it can be done directly on vector form.
• In aerospace navigation systems, the rotation matrix relating a local level wander azimuth frame and the earth frame is often used as position representation, see e.g. the book “Strapdown Analytics”, by Paul G Savage. In this (non-singular) matrix, the last column corresponds to n-vector, and then it is again preferable to have a direct solution in the navigation computer program, and avoid lat/long.
Isaac Euler (talk) 23:14, 13 August 2010 (UTC)

Regarding the alleged 0/0 and "singularity" problems, you may be thinking of gimbal lock, which is a reason not to use angular representations to describe sequences of rotations. But I have never heard that these problems apply to computing the distance from given angles, nor have your arguments about the poles made sense to me so far. Perhaps you are thinking that other calculations will result in a NaN for the longitude, which if plugged into the distance formula will obviously give NaN: garbage in, garbage out. But that is not a problem with the distance formulas themselves. And as I pointed out above, the ambiguous nature of the longitude at the poles is not a problem for the distance formulas per se: as long as any valid angles are supplied, the distance formulas will give the correct answer (with the caveats already noted about conditioning).

— Steven G. Johnson (talk) 02:27, 14 August 2010 (UTC)

Yes, latitude, longitude and sometimes a third wander azimuth angle (see e.g. http://adsabs.harvard.edu/abs/1989Navig..36..303P from NASA) are Euler angles, with singularities at the poles. And as you say, the Euler angle singularity is sometimes called gimbal lock (see e.g. WP ref1 or WP ref2).
“Garbage in, garbage out” is of course true. But when a distance formula requires an input that is undefined for some positions (i.e. longitude at the poles), it will create an extra requirement for the code that generates the longitude: The code must not produce “garbage” (=NaN or similar exception) for the undefined longitude. Some care must be taken to avoid this: E.g. when finding longitude from Cartesian ECEF coordinates, the Poles may give 0/0. If the program language supports atan2, this function can be used, since it usually handles 0/0: most often it contains an if-statement handling that situation, and usually outputs something else than NaN. If atan2 is not supported, the code that generates longitude must include that if-statement. Also for symbolic calculations, atan2 may return NaN for 0/0. This is also the case for the high precision variant of atan2 (WP ref). Two final examples are Mathematica, which classifies atan2(0,0) (called ArcTan[0, 0]) as an indeterminate expression and Maxima, which returns an error. See also http://www.mapleprimes.com/posts/38678-What-Is-Arctan00.
Based on this, I think it would be reasonable to mention the drawback with a method that requires an input that is undefined for some global positions, while the general task of finding a great circle distance has no such inherent issues. Alternatively (since lat/long is so much used) we could describe it as an advantage of the vector-method; that it never requires an undefined input. But if no one else thinks this is reasonable, we of course don’t include any comment about this in the article. Isaac Euler (talk) 16:16, 16 August 2010 (UTC)
Although of course gimbal lock problems with Euler angles are well known, I think you overstate the problems with the distance formulas (which, I maintain, don't have any problem in themselves). To say that the method "requires an input that is undefined" might give the reader the incorrect impression that they cannot be evaluated for points at the poles; a clearer statement would be that "any longitude is equally valid at the poles, and will give the same distance in all of these formulas (up to roundoff error)".
(Avoiding NaN when computing longitude is hardly an "extra requirement"...I would say that any code that claims to compute longitude should produce a valid longitude at every point, including the poles. At the poles, any numerical value is a valid longitude. NaN, however, is not a numerical value by definition.)
I completely agree that, for some situations, Euler angles and their equivalents are a problematic representation. Computing great-circle distances by itself is, however, not one of those situations. — Steven G. Johnson (talk) 00:02, 17 August 2010 (UTC)

geometry or geodetic astronomy?

The discussion in the previous section can be clarified by focusing on the question of whether this page is mainly one concerned with geodetic issues, or whether it should be thought as a mathematics/geometry page, as well. Certainly there is nothing about the title of the page that would suggest that it is not a mathematics page. From a strictly mathematical point of view, the position that the formula for the spherical distance in terms of angles and/or latitudes should be preferred exclusively at the expense of all other representations, is extremely reductive. Conceptually speaking, we are talking about dot product of vectors (the famous n-vectors, in other words, position vectors on the sphere), and nothing else. This readily generalizes to higher dimensions. And, of course, there is the problem of exceptional cases for the "polar" representations, when some parameters are undefined or multiple-valued. I am greatly in favor of applied mathematics, but not to the point of excluding pure mathematics altogether! Tkuvho (talk) 16:05, 17 August 2010 (UTC)

The people who like n-vectors seem to be suggesting that n-vectors avoid problems ("singularities") with lat-lon solutions-- which could perhaps be true when your starting point is the n-vector. But if (like most readers) you're starting with a pair of lat-lons, a conversion to n-vectors is pointless. The alleged problem of undefined longitude at the pole remains when converting lat-lon to n-vector, and is easily avoided, with or without bothering with n-vectors.
One of these years the n-vector advocates ought to get around to doing an example, starting with the lat-lons and showing everybody how simple and singularity-free their method is. This would include spelling out the calculations of the dot and cross product of the two vectors, so readers can see for themselves how "simple and intuitive" the method is. Tim Zukas (talk) 19:20, 18 August 2010 (UTC)
The n-vector advocates should also make clear that the alleged problems arise when you're trying to program the formulas into a computer or some other device-- that is, the problems are in the program, not in the formulas. Any reader who is just looking for a formula he can use with his pocket calculator to get the distance between two given lat-lons will have no worries.
(Or, if someone thinks that's not the case, give an example.) Tim Zukas (talk) 20:06, 18 August 2010 (UTC)
I really don't know much about the computer implementations of these calculations, but shouldn't their mathematical underpinnings be clarified as well? What's so complicated about taking the dot product of two vectors? It seems to be standard linear algebra material, and it is the most conceptual explanation of spherical/great circle distance. Tkuvho (talk) 20:54, 18 August 2010 (UTC)
The n-vector isn't the mathematical underpinning of the law of cosines-- it's a different approach to the problem. The law of cosines stands on its own, and if you're starting with the lat-lons of the two points it's the quickest route to the distance between them. If you're starting with n-vectors instead of lat-lons, then of course the dot product is the quick route-- but almost no one is starting with n-vectors. —Preceding unsigned comment added by Tim Zukas (talkcontribs) 00:11, 19 August 2010 (UTC)
I am not sure what you are arguing. Are you in favor of deleting the dot product section? Tkuvho (talk) 09:03, 19 August 2010 (UTC)
I don’t think that’s his intention:
• The vector method is the preferred method for those using ECEF-vector, n-vector and rotation matrix (all non-singular), as position representation. This includes
• most people working with GNSS (GPS, Glonass, Galileo and Compass). WP-ref
• most people working with advanced navigation systems for both aerospace and maritime applications see e.g. the book “Strapdown Analytics”, by Paul G Savage
• many geodesists (WP-ref)
• I know from experience several other groups of professionals, but don’t have time to find more references right now.
• Many mathematicians (including myself) consider the vector method to be the best explanation of a great circle distance (spherical distance).
• The vector method does not require an undefined input for any positions.
In summary, the article should now (containing both lat/long and vector methods) satisfy all readers. Isaac Euler (talk) 13:01, 19 August 2010 (UTC)
Yes, it's better now, with the elimination of the suggestion that the law-of-cosines/haversines formulas will sometimes give wrong answers, and that in such a case n-vectors will rescue the situation. It would be better still if it spelled out that n-vectors only make sense for people who are calculating distance from X-Y-Z coordinates, and that if you're starting with lat-lons for the two points n-vectors are pointless. Tim Zukas (talk) 19:50, 20 August 2010 (UTC)

Restored tag for claim about superiority of arctan function

I restored the tag requesting a citation because the cite links to another Wikipedia page. This doesn't qualify as a cite in the sense requested because Wikipedia is not a primary source.

Does not the method of finding great-circle distance from chord length avoid the problems with rounding errors which may disuade use of an arccosine formula? If so, it would seem that using a formula with arctan is not the only solution. -Ac44ck (talk) 03:28, 13 October 2010 (UTC)

Actually, I wouldn’t think a source for this is needed at all. “Every” professional who works with calculation of angles knows about the weaknesses of arccos and arcsin. You can see it easily from a figure of a circle: Try to determine the angle based on a length that is almost 1 (or -1): the angle will obviously be inaccurate. Or, look at the upper figure at the Inverse trigonometric functions page. Here you see that the derivatives of arccos and arcsin goes towards ±inf as you get closer to ±1, while arctan (the figure below) has a derivative of maximum 1.
If this is not enough to be convinced, try this on a computer:
true_angle=base_angle+small_angle
angle_from_acos=acos(cos(true_angle))
angle_from_asin=asin(sin(true_angle))
angle_from_atan2=atan2(sin(true_angle),cos(true_angle))
Vary the base_angle through 0, pi/2, pi, -pi/2 etc, and see how accurate you get the angle. You can use e.g. small_angle=1.23456789e-10. You will see that the angle from atan2 always has full accuracy, while asin and acos are inaccurate for the expected base_angles. Perhaps I should include one of the above explanations in the Inverse trigonometric functions#Practical considerations section? Isaac Euler (talk) 09:37, 13 October 2010 (UTC)
I tried them on a computer. Arcsine missed by a little, but not by enough to be of concern to me. In the order given above and working in degrees (base_angle=89.9999°; small_angle=1.23456789e-10°):
89.999900000123445
89.999900000123445
89.999899999085131
89.999900000123445
Said another way, 1.23456789e-10 degrees of latitude is about 0.00000001373 km on the calculator here: http://www.movable-type.co.uk/scripts/latlong.html. That equates to 0.00054 inch! While arcsine may present a theoretical issue, that issue doesn't appear to be of great import in this practical application of calculating great-circle distances by machines which have far better than slide-rule accuracy. -Ac44ck (talk) 03:36, 14 October 2010 (UTC)
Well, I haven’t checked the maximum error you can get due to the ill-condition, but I tried a larger “small_angle” and then the error was 1.6 cm. You must also be aware that if the input due to rounding errors is just slightly above 1, a complex result will be returned by acos and asin, which might lead to some exceptions. Both of these problems are easily avoided by using atan / atan2. If you don’t care about any of these issues you could stick with the acos variant, for either lat/long or n-vector. Those who want robust and accurate code will prefer the atan variant for lat/long (=Vincenty) or the atan variant for n-vector.
But this discussion was originally about the need for further citations for claiming that arctan is to be preferred over arccos and arcsin. And I don’t think that is needed – it is sufficient to refer within Wikipedia. Compare with the lat/long section: Here the arctan version (Vincenty) is said to be most accurate, but also without any reference. It might be that reference [2] contains this information, but that is not clear from the context. For the vector version, reference [3] contains information about preferring arctan over arccos and arcsine. So, an extra citation to that paper could be added, but I don’t think it is needed. Isaac Euler (talk) 09:10, 14 October 2010 (UTC)
I removed the tag because it didn't seem to fit as well as a FUD tag might, but there isn't a FUD tag.
While the statement about arctan may be true, it seems to have little relevance here. And I find this to be, shall we say, circular: "What I said here is true because it says so where I wrote the same thing elsewhere in Wikipedia." It was the initial justification given for removing the tag.
"The maximum error you can get due to the ill-condition" is admittedly unknown. Yet the warning is presented anyway, inserting fear, uncertainty and doubt (FUD) into the article. The warning seems to create excessive misgivings about the accuracy of arcsine in the context of this article.
"A larger [unspecified] 'small_angle'," at an unspecified base angle, produced an error of 1.6 cm. Perhaps the base angle remained 89.9999°. So there is FUD in the article for an error of this magnitude over a distance of thousands of miles? Why? - 05:01, 15 October 2010 (UTC)

Small but vital point

Latitude and longitude measurements in radians; quite relevant for the non-geometricians. - Amgine (talk) 17:47, 3 January 2011 (UTC)

Please elaborate. The single sentence isn't communicating the vital point to me. - Ac44ck (talk) 04:43, 4 January 2011 (UTC)
Latitude and Longitude as geographic locations are usually discussed as degrees, minutes, seconds, or in decimal degrees. This article (and most geometric discussions) refer to latitude and longitude as radians, angular measurement from the centre of the earth. Converting from degrees to radians is easy and the numbers will very similar, but if you don't know you should you will have consistent errors. (formula $\mbox{deg} = \mbox{rad} \cdot \frac {180^\circ} {\pi}$) - Amgine (talk) 21:35, 10 January 2011 (UTC)
"This article (and most geometric discussions) refer to latitude and longitude as radians..."
If the article does that, it shouldn't. Once you've calculated the central angle for the two points you might as well convert it to radians, but converting lat-lons to radians is pointless. Tim Zukas (talk) 22:39, 15 January 2011 (UTC)
Sure enough, somebody did stick in a bunch of unnecessary radian stuff. Think it's okay now. Tim Zukas (talk) 22:48, 15 January 2011 (UTC)

Request to check

I think there must be sth wrong with the formulas. In all examples it is said the "delta sigma" measured in radian has to be transformed to degree via (pi/180). This can t be true since a cirle measure multiplied with a scalar can t be a distance. The transformation has to be done within the sin, cos, etc -functions. So there is error in the part "Formulae" where it is said that "delta sigma" is given in radian and the "worked example". I am not used to this field so I am not quite sure. Can anyone check this?Flerio (talk) 17:13, 8 January 2011 (UTC) Flerio (talk) 17:13, 8 January 2011 (UTC)

It is not clear what you want checked. What does "sth" mean? Rather than citing "all the examples," please focus on one, quoting what you think is in error. Where do you see the requirement to convert from radians to degrees? As for what can be distance, please refer to the article on radian. - Ac44ck (talk) 21:07, 9 January 2011 (UTC)
In the part "Formulae" it is said that if "delta sigma" is given in radian, the relation "distance=radius*delta sigma is true. I think this is wrong since if the unit of delta sigma is radian than a multiplication with the radius (which is a distance) will not be the distance. To my mind not "delta sigma" has to be given in radian, but the lati- and longitudes. Then the formula would be correct. If lati- and longitudes are given in degree, they have to be transformed via PI/180 WITHIN the formula (i.e. sin(longitude*pi/180)....). If this is true then the "worked example" at the end is wrong, where it is said, that delta sigma can be given in degree and radian. To my mind the transformation from degree to radian has to be done earlier (within the trigonometric functions).Flerio (talk) 13:26, 10 January 2011 (UTC)
Degree to radian conversion is generally presumed, but in this basic example, it probably wouldn't hurt to clarify it (...done!). ~Kaimbridge~ (talk) 15:29, 10 January 2011 (UTC)
Thank you, but what is with the statement "delta sigma comes out to be 25.958 degrees, or 0.45306 radians, and the great-circle distance is the assumed radius times that angle:" in the last part. I think this should is not correct since we multiply 25.958 with pi/180. The result must be wrong since it is a difference if we transform "delta sigma" or the longi- latitutes.Flerio (talk) 15:50, 10 January 2011 (UTC)
Right:
Distance = degrees x radius x pi/180,
= degrees x (km, mi, etc., per degree).
It's just a matter of which factor you apply pi/180 to. ~Kaimbridge~ (talk) 17:20, 10 January 2011 (UTC)

Combining new section into existing

A new section called “From two vectors” was newly added, however this solution is already covered in the section “Vector version”. Thus the new section is not needed as a separate section, but it included more explanation, so I have added some more explanation to the “Vector version” section. Isaac Euler (talk) 09:13, 15 April 2011 (UTC)

I noticed that old section. The problem is that not everyone reading this page is interested in great circles in the geographic setting. I'm working on an optimization problem involving orthogonal matrices, and distances between such matrices involve distances on unit spheres. Wikipedia didn't help me with getting an expression for such distances so I derived it. Doesn't it make sense for me to contribute to this article so that the next person doesn't need to reinvent the wheel?

They are the same formula but n-vector is something geographic that I never heard of and can't be sure is equivalent to my unit vectors, so I really think my contribution should be put back in. Also because it's motivation/derivation was (very briefly) included. - Ben pcc (talk) 17:48, 15 April 2011 (UTC)

n-vector is just the normal vector to a surface, so it is a strictly mathematical quantity, and not “something geographic” (but it is probably used mostly for geographical problems). Thus it is exactly the same as your vectors (and you should probably choose the atan2 solution for numerical reasons). I see your point that it is easy to believe that n-vector is “something geographic”, but after I added comments about 3D vector algebra, dot and cross products, I think it should now be easier for “non-geographic” readers to realize that the solution you are looking for is found in that section. Isaac Euler (talk) 20:39, 15 April 2011 (UTC)
The categories this article is under are Metric geometry and Spherical trigonometry. This article doesn't at all look like it belongs in those categories. In fact, I think a good idea would be to rewrite most of this article so that it sounds like a math article and add some notes on geographic connections in a section including cluttered and obscure "formulae", look at the B class article Stereographic projection for example. -Ben pcc (talk) 21:10, 15 April 2011 (UTC)

Distance through a Sphere's Interior

The introduction says that "[t]he great-circle distance or orthodromic distance is the shortest distance between any two points on the surface of a sphere measured along a path on the surface of the sphere (as opposed to going through the sphere's interior)". What if you actually want to know the distance measured through the sphere's interior? What would that be called? And shouldn't there be a link to it somewhere on this page? -Agur bar Jacé (talk) 19:53, 13 February 2012 (UTC)

It is here:
Great-circle_distance#From_chord_length
- Ac44ck (talk) 22:59, 13 February 2012 (UTC)

Is this external link to a PHP implementation appreciated?

I wanted to add an external link to a PHP example of the Haversine and the Vincenty formula, and would have done it in the same manner as the already existing JavaScript link in the section "external links".

http://www.martinstoeckli.ch/php/php.html#great_circle_dist

Reading the guidelines, i stumbled over the point that one should generally not link to a page that is owned or maintained by onself, and that i should ask other editors about adding the link. That's why i ask here, the code is written by myself (no copyrights) and well tested, the page is a long-lasting page.

So, would this link be appreciated, or would it be considered spam-linking? — Preceding unsigned comment added by Martinstoeckli (talkcontribs) 07:56, 25 October 2012 (UTC)

Implementations don't really add to understanding of the topic, so they should be omitted. - MrOllie (talk) 16:58, 25 October 2012 (UTC)

Use Earth radius once in calculation of distance from chord length for unit sphere

A recent edit re-inserted the radius in the calculation of the central angle on a unit sphere.

This insertion is erroneous because in the context of this section, "r" is the Earth radius not the radius of the unit sphere. - Ac44ck (talk) 05:46, 18 February 2013 (UTC)

Section "Radius for spherical Earth" needs shortening

Discussion moved to /Archive 1

July 2013 suggestions for merging articles

This section is for discussing Fgnievinski's tags suggesting moving articles. cffk (talk) 10:36, 30 July 2013 (UTC)

I recommend against merging Great circle#Derivation of shortest paths into this article. For most people in this business, the fact that the great circle is the shortest path is clear enough and any proofs of it typically end up being confusing. I have started an article User:Cffk/sandbox/Geodesics on an ellipsoid in which I plan to include Bessel's proof of Clairaut relation by the calculus of variations. Great circles drop of this by the application of the sine rule for spherical triangles. On the other hand, it probably would be a good idea to combine Great-circle distance and Great-circle navigation. I also suggest getting rid of the vector derivation of the distance formula in this article. The outline of this derivation is in the article on the solution of triangles. cffk (talk) 21:52, 29 July 2013 (UTC)

The article on geodesics on an ellipsoid has now been created. cffk (talk) 21:33, 19 August 2013 (UTC)

I removed the merge suggestions from the article.cffk (talk) 11:47, 20 August 2013 (UTC)

Would you reconsider the merge? Fgnievinski (talk) 14:49, 25 December 2013 (UTC)
It's fine if you propose a merge once again. However, I recommend that you make specific recommendations on what is to be merged and how. And probably you need to be prepared to do some (most?) of the merging. (And I'll try to pitch in.) cffk (talk) 01:51, 29 December 2013 (UTC)