This is a HUGE bug. Preface: I'm a huge math nerd and have a degree in applied mathematics.

In trying to find a tech stop solution to fly from Paris to Tahiti, I used a great circle mapper:

http://www.gcmap.com/mapui?P=ory-ppt&MS=wls&DU=miFlying from Paris to Tahiti is 8487nm according to AWS. I threw in a tech stop at Ontario in Southern California as the great circle shows the line going straight through it. Flying Paris to Ontario is 4891nm and Ontario to Tahiti is 3597nm. If you add those together, the total flight with the tech stop is 8488nm--or only 1nm farther than flying direct. I LOL'd as this is the most efficient tech stop I've ever seen.

The problem is that the great circle distance flying from Paris to Tahiti is not 8487nm--it is 9773nm. I have developed websites and calculated a user's distance from a set location using a Haversine formula, so I immediately went over to a Haversine calculator and got the same result--9773nm.

A great circle, by definition, is the shortest path between two points on a sphere: noun a circle on the surface of a sphere that lies in a plane passing through the sphere's center. As it represents the shortest distance between any two points on a sphere, a great circle of the earth is the preferred route taken by a ship or aircraft.

So there is something wrong with the way AWS calculates distances and when you get out there really far, the error grows very large (1200nm in this instance). I tried to come up with the 8487 value using other methods, such as the classic distance formula, but failed to get the same result. The Haversine formula works because Earth is an oblique spheroid and while degrees of latitude are equally spaced, degrees of longitude fluctuate from being the widest at the equator to converging on zero at the poles.

For reference, below is my php Haversine equation for distance between two zip codes with corresponding lon/lat data stored in a database ($row* = database row). The return value is multiplied by 60 to go from seconds to minutes (1nm = 1 minute) and the 1.1515 value is to convert from nm to miles (take out the 1.1515 to leave it in nm obviously).

$theta = $rowzip1['lon'] - $rowzip2['lon'];

$dist = rad2deg(acos(sin(deg2rad($rowzip1['lat'])) * sin(deg2rad($rowzip2['lat'])) + cos(deg2rad($rowzip1['lat'])) * cos(deg2rad($rowzip2['lat'])) * cos(deg2rad($theta))));

return round($dist * 60 * 1.1515);

I have absolutely no idea how this change would be made to existing game worlds as it would absolutely destroy existing long haul route times/turnaround/slots/etc...meanwhile I'm going to hurry up and schedule my flight to Tahiti while it's short