This page is the gateway to a series of pages that each define the file formats of X-Plane's data files. These data files are continually evolving to include more and more data, and so multiple versions of each file definition are sometimes available.
apt.dat 90x version DRAFT (X-Plane 9.xx) (NEW) (DRAFT for review only - not yet used)
apt.dat 850 version (X-Plane 8.50 and later) (Latest
production version)
apt.dat 810 version (X-Plane 8.10 - 8.40)
apt.dat 715 version (X-Plane 7.15 - 8.06)
nav.dat 810 version (X-Plane 8.10 onwards) (Latest)
nav.dat 740 version (X-Plane 7.40 - 8.06)
fix.dat 600 version (X-Plane 6.40 onwards) (Latest)
awy.dat 640 version (X-Plane 7.00 onwards) (Latest)
astro.dat 740 version (X-Plane 7.40 onwards) (Latest)
This page also includes some background information on X-Plane's data files.
General issues questions:
Where do I find the latest data?
How can I correct errors or omissions that I find in the data?
Technical questions:
Where is the data stored in X-Plane and what data does each file contain?
How do the X-Plane custom scenery folders affect the airport data?
Data design questions:
Where are the localiser and glideslope aerials positioned in the “real world”?
Why is the DME component of a VORTAC or VOR-DME listed separately in nav.dat?
How do I convert my data to decimal degrees?
Where can I find the mathematical formulae used for real world navigation and spherical geometry?
Why are some runway and localiser headings very precise (to three decimal places)?
What are all the different codes used to identify an airport?
Return to the X-Plane airport and nav-aid data homepage
Sometime in 1997, I volunteered to Austin Meyer (the owner of Laminar Research and the developer of X-Plane) to try and improve upon the very basic airport data included in X-Plane version 3.x. I built an application in Microsoft Access 97 (now converted to Access 2000 and Microsoft SQL Server 2000) to store and manipulate the airport, nav-aid and intersection data. I have worked with Austin to add additional airport and nav-aid details to X-Plane (such as custom taxiways, airports outside the boundaries of the USA, more accurate runway markings, airways, stars, etc.). In late 2002 I started using the the US Department of Defense NGA (National Geospatial-Intelligence Agency - formerly NIMA) DAFIF data as a primary data source for new releases of the X-Plane data files, and my master database system was then converted to run on Microsoft SQL Server 2000.
This data is published as a free resource to the X-Plane community and is also the default data published with the retail versions of X-Plane. But if you really appreciate my efforts, please make a contribution to your local humane society or dogs’ / cats' home (and let me know – I would like to keep tally)!
The data is global in scope, but data for smaller airports is only available for the USA and parts of Europe. As users create data for the smaller airports, the global coverage will become more complete. The database has airports in every continent – including the US base at the South Pole.
Get the latest data file from here.
| I will always assume that the DAFIF data is correct. However, the DAFIF does contain many errors, and I am able to force users’ data to overwrite the DAFIF data in such cases. |
See my detailed instructions of making submissions for missing or erroneous data.
The following files contain airport, nav-aid, intersection, airway and astronomical data in X-Plane:
These files are all installed in the “Resources\Earth Nav Data\” folder of your X-Plane installation. You will also find different copies of some (or all) of these files in "Resources\Mars Nav Data".
These files are all plain text files that can be viewed or edited with any text editor (such as Notepad on a Windows PC). Be warned that, on occasions, a file created on Macintosh may not display carriage returns correctly on a PC. Importing the file into Microsoft Word and then saving it as a text file seems to fix these issues. For PC users, I suggest using the third-party text editor “TextPad”.
Fragments of the apt.dat file may also be stored in X-Plane's "custom scenery" folders, in which case any airports in the custom scenery apt.dat file will over-ride the entries in the 'master' apt.dat. This enables detailed taxiways within customised scenery to be distributed as a complete package. For apt.dat fragments in the custom scenery folder note that:
Flight simulator pilots often get confused about where the aerials that form the components of an ILS are positioned in relation to the runway. In X-Plane, all the aerials are visible, so it is quite easy to figure what is going on. Here is a simple example for a fictitious ILS for runway 09.
Localisers (LLZ)
The localiser (providing left-right guidance to the pilot) is usually positioned just beyond (500 – 1000 feet) the far end of the runway it serves (ie. beyond the eastern end of our example runway). The localiser’s beam points back down the runway (westward in our example) towards an approaching plane – the center of the beam passes through the runway’s touch down zone. You can see the localiser aerial at your nearest major airport – the aerial is a wide, flat thing, usually painted red, and hidden amongst the forest of approach lighting for the opposite runway (runway 27 in our example). It is usually the first valuable thing destroyed by an aeroplane that over-runs the end of a runway – or by an aeroplane the approaches the opposite end of the runway a little low.
Some localisers exist in isolation from other components of an ILS. These form part of Localiser (LOC), Localiser Directional Aid (LDA) or Simplified Directional Facility (SDF) approaches. Such aerials can be positioned wherever is most useful … an extreme example is the LOC on top of a mountain near Aspen, Colorado (KASE) that is used to provide guidance for departures (not arrivals).
Some localisers are not aligned with the runway they serve (they are termed “offset”). This usually helps pilots approach a runway that suffers from topographical obstructions. In such cases, the localiser beam will still pass through the touch down zone of the runway, but may be up to 30 degrees offset from the runway heading. Examples can be found at such diverse locations as Honolulu (PHNL) and Fayetteville Drake Field, Arkansas, USA. Some offset localisers do not even pass through (or close to) the touch down zone, such as Innsbruck, Austria (LOWI), Washington National (KDCA) and Burbank, California, USA (KBUR).
Glideslopes (GS)
The glideslope (GS) aerial (which provides up-down guidance to the pilot) is usually positioned just to one side of the runway’s touch down zone (TDZ), which is about 1,000’ along the runway from the threshold. Typically, a GS aerial might be 200 – 300 feet to the left (north in our example for runway 09) of the TDZ. Again, you can see this vertical aerial at your local airport – it often has a small shack close by housing the electrical gear. The shack is often painted in lurid red/white or orange. The beam from the glideslope is typically angled up from the TDZ at 3 degrees, though this may vary. Steeper angles may not sound significant (say 5 degrees at London City, EGLC) but they are surprisingly disconcerting to nervous passengers (and pilots with too much airspeed).
Marker beacons (OM, MM and IM)
The marker beacons (which provide information to a pilot about the distance from the runway) are placed on the ground at certain distances from the runway’s threshold. The Inner Marker (IM) is usually very close to (or at) the runway threshold. The Middle Marker (MM) is typically 3,500’ out from the threshold (to the west in our example) and usually indicates a point at which an approaching aeroplane on the glideslope should be 200’ above the TDZ elevation - this is often the point at which an aeroplane will be at the Decision Height (DH) on the approach. The Outer Marker (OM) varies in location, but is usually 4 – 7 nautical miles for the runway. Not all ILS approaches have the full complement of marker beacons – inner markers are relatively rare. Many marker beacons are now being decommissioned, since DME or GPS can provide more useful and accurate distance information.
Distance Measuring Equipment (DME)
DME is not an essential component of an ILS – though many installations do have a co-located DME. The DME aerial may be located near the localiser aerial, the glideslope aerial, or somewhere else. Approach charts will indicate what the DME will read at the runway threshold, and will also indicate if DME is a required part of the approach.
X-Plane defines all latitudes and longitudes as “decimal degrees” to six decimal places (eg. –123.456789). This makes mathematical calculations faster. You may remember from your basic school geometry that a degree may be subdivided into 60 minutes, and that a minute can be further subdivided in 60 seconds. Some aviation data sources choose not to use the “seconds” – instead they use decimal parts of a minute. Other sources use data defined in degrees and the decimal part of degrees, just as in X-Plane's data files. Here are some example data formats (all refer to the same position):
N35.5000 W106.5000 (Decimal degrees, or dd.dddd)
35 30.00N 106 30.00W (Degrees and decimal minutes, or dd mm.mm)
35 30 00N 106 30 00W (Degrees, minutes and seconds, or dd mm ss)
X-Plane has a convention that western longitudes and southern latitudes are negative numbers when converted to decimal degrees. So data for the USA will have positive latitudes and negative longitudes (see all the example data quoted above). Australia will have negative latitudes and positive longitudes.
So, to convert a dd mm.mm format (eg. 35 30.00N) to decimal degrees), you need to:
Similarly, to convert a dd mm ss.ss format (eg. 52 30 15W) to decimal degrees), you need to perform the same process as above to convert the minutes to decimal degrees, then perform a similar process to convert the seconds to decimal degrees, and then aggregate these two components together. Remember, there are 60 seconds in a minute and 60 minutes in a degree, so there are 60x60 = 3,600 seconds in a degree. So to convert 52 30 15.00W to decimal degrees the process becomes:
A fascinating web site that contains many formulae for pilots and simulator designers (and that will make you scratch your head) is the Aviation Formulary.
Most “real-world” runway and localiser headings are quoted on charts to the nearest whole degree (magnetic), since this is usually more than accurate enough for day-to-day flying. But runways and localisers are not always laid out neatly in whole degree increments … and X-Plane needs to have precise headings (in true degrees, not magnetic) in order to make localiser alignments work, and ensure that taxiways join up neatly with each other and with the runways. An error of 0.5 degrees in a runway heading can misplace the runway threshold by up to 50 feet on a 12,000’ runway … a significant margin if you are trying to land a Boeing 747 on a narrow runway.
So, although your airport chart may show a nice simple runway magnetic heading of 90.0 degrees, when converted to a precise, true heading this may appear more accurately in the X-Plane data file as 91.234 degrees.
Entertainingly, there are at least three sets of codes for airports. There is no fool-proof way to derive one code form another code automatically.
ICAO (International Civil Aviation Organisation) codes are usually used for aviation operations around the world, including flight planning. These codes consist of four letters. The first letter indicates a region in the world, the second indicates a country within that region. The last two characters identify a specific airport. For example, London Heathrow has an ICAO code of EGLL - the EG implies the United Kingdom and is common to all other UK airports (eg. EGKK for London Gatwick).
The United States and Canada are 'special cases' - there are so many airports in each country that the initial letter "K" is used to identify an airport in the contiguous United States (ie. excluding Alaska, Hawaii and anything else not on the mainland), and an initial "C" are used to identify Canadian airports. In the USA, the remaining three letters are almost always the FAA code for that airport (see below), such as KABQ for Albuquerque International Sunport. Note that are some rare cases in the USA where the IATA and FAA codes may differ (see examples below).
It is a common practice in some countries to designate the major airports with repeated characters as the last two letters of the ICAO code (eg. in the United Kingdom).
IATA (International Air Transport Association) codes are used by airlines for reservations, ticketing and baggage checking. These codes consist of exactly three letters. They are (usually) easily interpreted. For example, the IATA code for London Heathrow is LHR. Others are less obvious, such as CMH for Columbus, Ohio, USA or ORD for Chicago O'Hare (formerly called Orchard Field), USA. These are the codes that you will see on the baggage labels when you check a bag with the airlines (when the code is, of course, totally unrelated to the airport to which your bags will be delivered). As far as I am aware, every airport with an IATA code also has an ICAO code.
In the USA, the IATA code is usually the same as the FAA code (see below).
One of the few exceptions to this rule is the airport from which I fly a rented Diamond Star (DA-40) - Carlsbad, California has an FAA code of CRQ (ICAO code is KCRQ) and an IATA code of CLD. Another example is Taos, New Mexico which has an FAA code of SKX (ICAO code is KSKX) and an IATA code of TSM.
FAA (Federal Aviation Administration) codes are also used for all airports in the USA. These can be three or four characters and are sometimes a combination of letters and numbers. (eg. 4AC for Albuquerque Coronado).
If the airport also has an IATA code, then the FAA code will usually be the same as the IATA code (but there are exceptions - see above).
If the airport also has an ICAO code, then the ICAO code can usually be created by prefixing the FAA code with a "K" (in the contiguous states) but in such cases the FAA code must consist of three letters (such as GTU, Georgetown, Texas) - no numeric characters are allowed in ICAO codes.
According to FAA Order 7350.7A: "Three-letter identifiers are assigned as radio call signs to aeronautical navigation aids; to airports with a manned air traffic control facility or navigational aid within airport boundary; to airports that receive scheduled route air carrier or military airlift service, and to airports designated by the U.S. Customs Service as Airports of Entry.".
Recently there has been a steady migration of FAA codes away from letter/number combinations to all letter codes - this is often related to the installation of updated weather reporting services at an airport, which require an ICAO code to disseminate the meteorological data (and hence require an all-letter FAA code).
Note also that:
© Robin Peel, 2007. Last updated December 16, 2007