Hello,
Those using the
Git repository can try out the new Airport Finder dialog accessible under the Tools menu:
The Airport Finder dialog:
This dialog allows one to find all airports located in a given area specified with maximum and minimum distances to a reference airport. The direction of the path (from or to the reference airport) can be chosen. For each result, the dialog gives the orthodromic distance (i.e., the length of the shortest path following the Earth curvature) between the two airports as well as the initial and final bearings of the course, according to the chosen direction. It is also possible to choose between magnetic and true bearings, nautical miles and kilometers (for display of the results), Vincenty and Karney calculation methods. Finally, a button allows one to choose the airport selected in the results table and automatically close the dialog.
This dialog was written with the following use case in mind: suppose you found on
Lenny's site or on the
FlightGear multiplayer map that there is an
ATC session at some airport and would like to land there. For example, let's assume the ATC session is taking place at MHTG (Toncontin Intl, Tegucigalpa, Honduras). So, you need to find an airport that is neither too close nor too far from MHTG given the time you are ready to spend for this flight (in general, when an airport is under ATC control, you should be either on ground or at least 70-80 nautical miles away from the controlled airport at the time you connect to the multiplayer network, in order to let the controller(s) enough time to properly insert you into the existing traffic).
With the multiplayer map, estimating distances between airports is not easy. This can be done by trial and error with FlightGear of course, but using FFGo's new Airport Finder dialog is much quicker and more convenient. You just have to enter MHTG as the “reference airport”, check that the minimum and maximum distance fields have values you are satisfied with and click on the Search button, or use the Alt-S keyboard shortcut. You will then obtain a list of airports in the given range, with for each of them its distance to the reference airport, as well as the initial and final bearings for the course using the shortest path. If you have installed the MagneticField program that comes with
GeographicLib, you will have the choice to display magnetic or true headings.
This use case is why the reference airport is considered as the destination of your flight by default. However, if you want to start from a particular airport and find which airports are in a given range of this airport, all you have to do is to change the “Direction” radio button to “from reference airport” and all bearings will be updated accordingly in the list of results.
Both tables (multicolumn lists) can be sorted in ascending or descending order using any column as the sort criterion by simply clicking on the column header, as usual with this type of interface. By specifying a maximum distance that is greater than the half-length of the equator (10820 nautical miles should be enough), you can list all airports known to FlightGear, and sort them for instance by distance from the reference airport (this is the default). Looking at the maximum distances, you can find nearly-antipodal airports relatively to the airport of your choice, which you may find amusing. For instance, using Paris Orly (LFPO) as the reference airport, one can find that the farthest airport from it is NZCI, which is located on an island east of New-Zealand. But you can also sort the lists by ICAO, airport name, initial or final bearing, of course (sorting by bearing can be useful if you want your flight to go roughly north-west, for instance).
Particular care has been taken to make sure the reference
airport selection interface is as convenient as possible. It is similar to what already exists in the main window, but with a few improvements: real multicolumn widget (allowing proper alignment as well as sorting); small delay before updating the list (as in FGo! and in previous versions of FFGo, implemented in a CPU-efficient way); smarter selection. Let's explain the last one a little bit. When you know the ICAO code of an airport and type it in the search field, it's a bit annoying if the default selection, after you have typed the ICAO in the search field, goes to an airport that by “chance” contains the ICAO code in its name. So, this new airport selection mechanism selects an exact (case-insensitive) match on the ICAO field by default if such a match exists. If not, it tries to keep the selection on the airport that was selected before the last change in the search field. And if the search was refined in such a way that makes this impossible, the default selection goes to the first result, which is what the widget in the main window does in all cases. This interface will probably replace the one in the main window in a future release.
This may be easier to understand with an example: typing "lfpo" in the search field automatically selects Paris Orly (LFPO), not any airport containing this string in its name (such as Gulfport Biloxi Intl or Gulfport Jail)---those are still listed and available for selection, though. This is particularly convenient for airports such as Turtle Island, whose code "TTL" is contained in the name of many other airports (most of which containing the word "little").
It would be possible to add other elements to the search criteria and display them in dedicated columns in the tables. The most interesting candidates that come to mind are:
- max./min. number of land runways;
- max./min. number of water runways;
- max./min. number of helipads;
- maybe the length of the longest runway in the airport, too.
These are not difficult to add but require including the corresponding data into the apt digest file (aka airport database), otherwise reading them for more than 34000 airports would be dreadfully slow. I don't see any major problem for the first three points above. The last one would require computing the length of each runway in the world whenever the airport database is rebuilt, which is certainly doable but will make it last a bit longer (not sure how much yet, I would say on the order of 3 to 15 seconds approximately using Vincenty's formula on my computer).
Note: the Treeview widget used to implement the multicolumn lists should be part of Tk since version 8.5. Debian jessie already has Tk 8.6, so I don't think this requirement should be a problem in practice (i.e., normally, things should work without installing anything else than what you already have for FFGo). Tested on Debian wheezy and unstable, no problem found.
Finally, for those wondering why the table of results gives an initial and a final bearing for each airport, think about this: imagine you are very close to the North or South pole, moving with true bearing (azimuth) 90°. You are following a line of constant latitude, i.e. a circle whose axis is the North-South axis of the Earth. Clearly, this shows that a path with constant bearing (azimuth) is neither straight (if close to the North pole, you are constantly turning left in this example) nor a shortest path between two points on the Earth surface. Curves on the Earth's surface corresponding to “straight” walking or flying are called
orthodromes or geodesic lines (at each point, the projection of the curve on the plane that is tangent to the Earth's surface at the point in question has zero curvature). Curves with constant azimuth at each point are different beasts called
loxodromes, rhumbs or rhumb lines. And flying your plane with constant altitude and magnetic heading in the absence of any wind doesn't even follow a loxodrome, because the magnetic declination changes all along your path, therefore your true heading can't be constant...