X-Plane Airport & Navigation Data

FAQs (Frequently Asked Questions) for data designers

FAQs for data designers

Answers to more technical questions for airport and navigation data designers and scenery developers.

Where are all the elements of an ILS positioned?

Localizer aerialILS component placement:  X-Plane requires all ILS components to be placed in their correct, real-world locations. 

The localizer aerial (image on the left) is positioned beyond the far end of the runway it serves, pointing back down the runway towards approaching aeroplanes.  This ensures that an aeroplane can have localizer guidance on the final stages of its flare to land (after it has crossed the runway threshold, or as it begins its missed approach.  The localizer is almost always perfectly aligned with the runway it serves ... but sometimes they are slightly offset, usually to provide terrain clearance on the approach.  If so, the localizer position will be moved so that it still points across the touch down zone of the runway.  You can see an example of this at KBOS.

The glideslope aerial is positioned to one side of the touch down zone, usually perpendicular to the touch down zone markings on the runway, close to the VASI / PAPI location.  It operates on a frequency paired to the localizer frequency.

Marker beacons are becoming rarer, but are positioned along the final approach path.  The outer marker is usually at the Final Approach Fix, usually 4NM to 7NM from the runway threshold, and is sometimes paired with short range NDB (called a Locator Outer Marker or LOM).  The middle marker is closer to the runway, usually at point at which an aeroplane flying the glideslope should be at the Decision Height (DH) for the approach, typically about 3,500 feet out from the runway threshold.  The inner marker is very close to the threshold, and is rare - they are used for Category 3 approaches to very low DHs.

How will my custom scenery affect the "master" airport data?

Fragments of the apt.dat file may also be stored in X-Plane's "Custom Scenery" folders, in which case any airport data in the custom scenery apt.dat file will over-ride the entries in the 'master' apt.dat.  This enables detailed taxiways within customized scenery to be distributed as a complete package. For apt.dat fragments in the custom scenery folder note that:

  • The apt.dat file fragment must have the same header and closing lines as a 'full' apt.dat file (detailed definitions of the format of the file can be found on the Designers page).
  • The apt.dat file fragment must be stored in an "Earth Nav Data" sub-folder within the relevant custom scenery folder (eg. in "C:\X-System 9.x\Custom Scenery\Test Scenery\Earth Nav Data\apt.dat").
  • If an airport appears in multiple apt.dat file fragments in custom scenery folders, then the entry in the first (alphabetically by custom scenery folder name) will be used, and the others will be ignored.

Can I use custom nav-aid or fix data in a custom scenery package?

No.  Any earth_nav.dat or earth_fix.dat files in a custom scenery package are ignored by X-Plane. 

It is not possible to uniquely identify a nav-aid by its ID or frequency, so it would not be possible for X-Plane to match nav-aid information in a custom scenery package against the matching data in the 'master' earth_nav.dat file.  (This process does work for airports because the airport ICAO codes are guaranteed to be unique.)  In addition, the purpose of the custom nav-aid data may be to correct the ID or frequency of a 'bad' nav-aid, making making the suppression of the 'bad' master data impossible.  Similarly, fix names are not unique at a global level.

So, changes to nav-aids must be made in the 'master' earth_nav.dat file and fixes must be changed in the earth_fix.dat file.  You can send any corrected data to me to be included in my master database.

My airport does not have an ICAO or FAA code.  What should I use in X-Plane?

Within the USA, almost every airport has either an ICAO or FAA airport code.  But in many other countries, smaller, disused or private airports do not have any kind of published code.  But, X-Plane requires a unique code for every airport.

The recommended approach is to create a dummy, unique code for such airports by combining the ICAO country code (such as "EG" for the United Kingdom) with a two-digit number.  You can check the existing apt.dat file to ensure that you select a unique combination.  So, a disused airport in the UK might have a code of "EG12".

  • In many cases, a disused airport may have previously had a valid ICAO assigned to it.  If so, use this older code.  But note that it in rare cases ICAO codes from a closed airport are 'recycled' and re-used at a different airport.  For example, in Austin, Texas, the commercial airport  (KAUS, Austin-Robert Mueller) was closed, and a former USAF base (KBSM - Austin Bergstrom) was converted to the new commercial airport.  When the former base re-opened in its new role, it stole the KAUS code (presumably, to avoid confusion with the airline ticketing systems).
  • A planned enhancement to X-Plane will enable optional six-character ICAO codes, to allow a greater number of these 'dummy' airport codes for each country (eg. "LF1234").