It displays a map depicting the great circle path between locations and computes the distance along that path. It can also display the area which is within a given range of a location.
A great circle path is the shortest path on the surface of a sphere
between two points on that sphere. Technically, the term
path should be used in this page since Earth is not a true sphere,
circle terminology is common usage.
A path consists of two or more locations, separated by hyphens (aka dashes). For example, ORD-SFO plots a path from ORD (Chicago O'Hare International Airport) to SFO (San Francisco International Airport).
Sure! Independent paths can be placed on separate lines or separated by commas or semi-colons. You can also specify more than two locations in a single path for multi-hop routings. For example, LAX-JFK,LAX-TUS-FTW-BNA-LGA compares the contemporary non-stop flight from Los Angeles to New York to the 1941 vintage route of American Airlines' Flight 004, the "Limited Mercury," operated using a Douglas DC-3.
If you specify a ground speed the distance table below the map will include a time computed from the distance and speed. This assumes the entire trip will occur at the selected speed, ignoring acceleration and deceleration.
A Mach number is a fraction of the speed of sound. The speed of sound varies as a function of type of gas (dry air is different from humid air!) , pressure, and temperature, so there isn't a straightforward conversion of Mach to distance/time. The Great Circle Mapper assumes the speed of sound is 574 knots (about 660.5 miles/hr or 1063 km/hr), which is a close approximation for the lower stratospheric altitudes from 36,000 feet to well above 65,000 feet, where transport jets usually fly, using a temperature of -70°F. For more information, see
Locations may be FAA, IATA, or ICAO airport codes, or latitude and longitude.
Not to the mapper, but you can lookup a code by city or airport name.
Search for an airport code using the lookup page.
This is nicely answered in an excellent article by Dave English, Airport ABCs: An Explanation of Airport Identifier Codes, published in the December 1994 issue of the Journal of the Air Line Pilots Association, Air Line Pilot.
The IATA and ICAO databases were initially derived from a database which once lived at the Johnson Space Center, subsequently augmented with material from a variety of sources. Most ICAO data now comes from NGA's DAFIF® product (see Credits and Copyrights), which offered excellent data quality. Unfortunately, NGA ceased distributing DAFIF® except within the military effective 1 October 2006. The airport database uses the final public DAFIF® data (cycle 0610, effective 28 September 2006 to 25 October 2006),
IATA charges a large and recurring price for their data, so airport locations for non-US IATA codes (and scattered ICAO codes) continue to be derived from a patchwork of sources. While most major airports are now included, given the unknown ancestry of the data, the accuracy of the data is often suspect. Special thanks to Thomas Jäger, Iikka Meriläinen, Yann Gascard, and Nils Rennenberg for their assistance in cleaning up this mess as much as possible.
Authoritative data is used for US and Icelandic airports. See Credits and Copyrights for details.
The databases have been merged into a single database which attempts to use the "best" data. Because of its greater precision and trustworthiness, the FAA data is favored for a given airport. However, while the FAA ensures that any airport with both an FAA and IATA code has the same code in both registries, it does not otherwise avoid conflicts. For example, CBG is assigned to Cambridge, Minnesota, while IATA uses the same code for Cambridge, England. To resolve this ambiguity, the IATA-listed airport is used if the latitude and longitude are not both within a few degrees of the FAA location. Presumably an IATA-listed airport will be more interesting for great circle routes than a small US airport.
Append .FAA to the airport code to force use of the FAA definition. For example, while CBG (and CBG.IATA) use the IATA definition of CBG (Cambridge, England), CBG.FAA will use the FAA definition (Cambridge, Minnesota).
The FAA data is considerably more precise. The full database even includes the latitude and longitude of each end of each runway, with precision down to fractions of a second of arc. In contrast, some of the IATA and ICAO source data only have degrees and minutes; the original source file listed coordinates that appeared to be for the city, not the airport. For example, it had London's Heathrow and Gatwick airports at the same location. (The current database has more accurate locations for London's airports.)
The airport database contains 45,000 codes representing over 35,000 locations. (A given location may have multiple codes. For example, London's Heathrow Airport is associated with both LHR and EGLL.)
The input parser tries to be as forgiving as possible. Degrees alone may be specified or degrees and minutes, or even degrees, minutes, and seconds. The last value may also have a decimal and a fractional portion. Directions must be specified; latitude and longitude may be specified in either order. For example, the following are all valid ways to specify the location of Chicago O'Hare International Airport:
41.979595 N 87.904464 W 41°58'46.5"N 87°54'16.1"W 41d58'46.5"N 87d54'16.1"W 41d58m46.5sN 87d54m16.1sW 41 58 46.5N 87 54 16.1W 41 59N 87 54W N41 59 W87 54 W87 54 N41 58
There isn't complete agreement on whether latitude or longitude comes first (though usually it's latitude) and it saves confusion to make N/S and E/W explicit.
Besides that confusion, the source data has surprisingly little consistency in the sign conventions for the hemispheres. One might expect negative latitudes to be south of the equator and negative longitudes to be west of the prime meridian. However, an early dump of the FAA data had the sign of the longitude reversed so most of the airports it lists have positive longitudes. (Not all, though. US territories are listed, and GUM, for example, is in the eastern hemisphere, as are a few airports in the far reaches of Alaska's Aleutian Islands.) An even stranger convention was found in the first file from which I distilled the IATA and ICAO data. While longitudes were normal enough, latitudes were relative to the south pole, so the equator was at 90 degrees, not zero, and the north pole was at 180! (This is called a false northing.)
Part 139 refers to 14 CFR Part 139 which requires the FAA to issue an airport operating certificate to US airports which serve scheduled air carrier operations with 10 or more seats or unscheduled (charter, not diversions) operations with 30 or more seats. There are four classes of airports which can be summarized as follows:
Class Scheduled Large
Class I ok ok ok Class II - ok ok Class III - ok - Class IV - - ok
A range consists of a comma-separated list of distances, followed by an at sign ('@') and a location. Distances consist of a number followed by an option unit, which may be any one of the following: statute miles (mi), nautical miles (nm), kilometers (km), or minutes (min) at 389 kts. If no units are specified for a given distance, nautical miles are assumed. For example, 500mi,1000mi@FRA displays areas within 500 mile and 1000 mile ranges of Frankfurt.
Alternately, instead of specifying a single location, a list of locations may be specified inside parentheses. In addition to being a shorthand form, this allows a group of overlapping airports to be shaded as a set. For example, 90min@(EINN,BIKF,BGSF,CYYR,CYQX) displays the regions where a twin-engined airliner may fly across the North Atlantic under a 90 minute ETOPS rule-time.
Specifying a range in minutes of flying time from an alternate airport is useful for discussions of ETOPS. 389 kts is the rule-speed used for the ETOPS maps.
If you don't pick a style, the program tries to pick what it thinks
will look best. Overlapping shaded areas can be confusing so if you
request ranges from several different locations, the outline style
is used unless you group them inside
parentheses. Shading also starts to look bad with more than three levels
of shading, so if you specify more than three ranges, outline style is
used. Otherwise, the shaded style is used.
ETOPS is an acronym for Extended-Range Twin-Engine Operations. Without an ETOPS rating, an aircraft with only two engines must be able to get to an airport where it can safely land within 60 minutes if an engine fails in-flight. ETOPS extends this "rule time" to 90 minutes or more, up to a maximum of 180 minutes. Obtaining an ETOPS rating requires certification of the reliability of an airframe/engine combination as well as an airline's flight operations and maintenance. Usually extra equipment is required as well, such as additional backup systems for electrical power. ETOPS does not require over-water equipment (e.g., life rafts) or additional fuel tanks, though these are usually required for the typical missions of ETOPS-rated aircraft.
Some pilots claim ETOPS really means "Engines Turn Or Passengers Swim." :-)
The database of suitable alternate airports is incomplete. For some areas, such as the North Atlantic, very good data is readily available. It also doesn't take a rocket scientist to figure out that many airports in the U.S. (for example) which have regularly scheduled service with large, widebody airliners are suitable alternates. For other parts of the world, the data isn't readily available, and it's not obvious what airports might be suitable. (Improvements have been rapid, thanks to many contributions of information from the net.)
Just because you're over land doesn't mean you can land a large commercial airliner there. Antarctica, for example, doesn't really have any airports and is quite rugged. Air service to Antarctica does exist, but it uses special aircraft such as ski-equipped C-130 Hercules military transports which can safely operate from short airstrips of packed snow or ice. Given a choice of landing a 767 in most parts of that continent versus ditching in the ocean, ditching might be the safer alternative!
There are two distinct routes across the North Atlantic, one using Iceland's Keflavik airport as a key alternate, and another, more southerly route using Lajes in the Azores. West of these islands, there's a small, triangular area which is not within 120 minutes of any suitable airport. A 138 minute rule-time (120 minutes plus 15%) removes this last "no-go" area over the North Atlantic, and the UK's CAA approved operation under this enhanced rule for several carriers. (180 minute ETOPS is significantly more difficult, and with no reason for it over the Atlantic, many carriers neither need nor want the added expense.)
Boeing's 777 was the first airliner designed with ETOPS in mind from its inception, including systems to support single-engine operations for considerably longer than 180 minutes. While proposals to extend ETOPS to a 240-minute rule-time haven't met with much success, an interim proposal for 207 minutes (180 minutes plus 15%, similar to the 138 minute rule-time) has been adopted, primarily as an exception for 180-minute routes when key alternate airports are unavailable due to weather.
Longer ETOPS rule-times would also allow closure of alternate airports along routes which currently can be served under less stringent ETOPS rules, such as Midway Island (MDY), which is currently subsidized in part by Boeing to provide an ETOPS alternate. This fact has pilots concerned since it affects all planes, not just twins. They note that even if all engines are still running (and at this point twins aren't significantly more likely to divert due to engine failure than aircraft with three or more engines), a four-hour diversion due to a fire or a medical emergency or any one of a number of other problems is an awfully long time.
(See AW&ST, 30 November 1998, pp. 50-51.)
Boeing built the 777-300ER with the capabilities for 330-minute ETOPS. Using existing alternates, this is mainly of value between New Zealand and South America, and in September 2003 Boeing plans to fly a 777-300ER non-stop from Sydney to Rio de Janeiro. In addition, this could improve safety by allowing the overflight of some marginal alternate airports in the event of an engine failure, diverting instead to further airports which are more capable of handling a large jetliner.
Yes. The areas displayed are based on a speed of 389 kts at the specified rule-time. This value was used in several early papers on ETOPS and is appropriate for a Boeing 757, though values for other large twins should be similar.
The boundaries of the ETOPS areas are pre-computed. Computing them on-the-fly would require roughly a minute per area requested, so a map with 90-, 120-, and 180-minute rule-times would require about three minutes to generate instead of a few seconds as the current implementation requires. Since most airliners for which ETOPS is an issue will have similar rule-speeds, the high cost of allowing various speeds adds little value.
Obviously there may be airports which a
can use which larger twin-engined airliners, such as the
cannot use, even in an emergency. It is believed that the alternate
airports used for these maps can accommodate any current twin-engined
airliner, and in most cases can even handle a
The rectangular projections were generated using the Xerox map server and were colored by hand using xpaint. The orthographic projections of the poles were generated using the Online Map Creation site and re-colored. Coordinates for paths and ranges are generated using the PROJ.4 cartography tools and projected onto the maps using a custom rendering program.
Most of these maps use a rectangular or Plate Carrée projection because it is trivial to project latitude and longitude into map coordinates. The polar maps are a special case for paths that traverse the Arctic (or Antarctic) regions of the globe; with the restricted set of maps the orthographic projection didn't require much additional work to implement. Together, the results are adequate for the intended purpose, so I didn't want to invest a lot of effort (and compute time!) on more complex projections.
The polar maps are orthographic projections centered on the two poles. They are automatically used instead of the default rectangular projection if all of the following conditions are true:
In the interest of keeping the user interface from being too complex, there is not currently any way to explicitly request a polar map or not. Whether this is a bug or a feature is perhaps debatable.
Only a limited set of base maps are available. The smallest one for a given request is chosen, but if nothing else fits, that may be a map of the world. (Additional base maps will be built as time and resources permit.)
It's significantly slower to produce custom maps on the fly. In addition, the Xerox server adds margins which aren't easy to predict, which in turn makes it impossible to know where to plot the paths, and the lack of full coloring makes the maps harder to read.
See the comments on map choices above. Beyond that, this page was written to study great circle routes, which aren't very interesting over short distances, so detailed local maps have not been included.
A number of sites offer custom maps of varying levels of detail.
The geod program from the PROJ.4 cartography tools is used to calculate both the distances and the points along the paths, which are rendered using a custom rendering tool.
No, the WGS 84 model of Earth's ellipsoid is used.
Assuming Earth is a perfect sphere of radius 6371.2 km, convert longitude and latitude to radians (multiply by pi/180), then compute as follows:
theta = lon2 - lon1The resulting distance is in kilometers.
dist = acos(sin(lat1) × sin(lat2) + cos(lat1) × cos(lat2) × cos(theta))
if (dist < 0) dist = dist + pi
dist = dist × 6371.2
One good page is
Time and Motion,
from Issue 7 of
Flying eastbound, tail winds make it advantageous to fly a more southerly route even though it is longer. The great circle route is the same in either direction but is only used for the westbound, ORD-HKG flight, which would encounter substantial head winds if it flew the more southerly route.
PROJ.4 doesn't handle edge conditions properly. I looked at the code but decided it wasn't worth the effort to try to fix it.
Another example of this is a path from some random point on Earth to the exact opposite side of the planet. This does produce an image, but the results are very strange, including an obviously erroneous distance.
You may use maps generated by the Great Circle Mapper on your web pages so long as you do not profit from them and you include the following credit on pages which include maps:
Maps generated by the Great Circle Mapper - copyright © Karl L. Swartz.
Adding the following HTML to your page will accomplish this:
Maps generated by the
<a href="http://gc.kls2.com/">Great Circle Mapper</a> -
copyright © <a href="http://www.kls2.com/~karl/">Karl L. Swartz</a>.
This permission may be altered or rescinded at any time and for any reason.
In addition, I'd appreciate it if you would e-mail me a brief note about your use of my maps including the URL of your site. If you'd like me to include a pointer in the Other Applications section of this FAQ, please let me know how you'd like it to read.
You can donate if you like via PayPal.
Here are a few:
Also several maps of past U.S. Presidential election using shades of purple, rather than simple blue (Democrat) versus red (Republican):
The following sites are known to embed great circle maps from this site in their own pages. Please send any additions to this list to firstname.lastname@example.org.
The tools and data used to build the Great Circle Mapper are derived from a variety of sources.
All these pieces are glued together by some home-grown software, including about 2,850 lines of C and another 8,000 lines of Perl online. There is also a large amount of support code, all written in Perl, including 6,250 lines or so used to build the airport location database, ETOPS data, etc., and another 900 lines of Perl to perform log analysis, cache maintenance, and the like.
Copyright © 1996-2013, Karl L. Swartz. All rights reserved.