Navdata in X-Plane 11

One dataset to rule them all

In X-Plane 11 one single database is used for all purposes of navigational data in the simulator. All items defined in this common database will be used for the scenery, the map, ATC, AI and the GPS/FMS and radio navigation avionics. In X-Plane 10, it was possible to have a discrepancy between what you saw in the X-Plane world and what was available for GPS navigation. This lack of data integrity is no longer possible. X-Plane 11 has a redesigned navdata hierarchy and new formats, that strongly enforce referential integrity and correctness. Note that the format is not backwards-compatible to any of the old datasets, X-Plane 11 will only load data in the X-Plane 11 format.

No more duplicate airport information

Furthermore, all data about airports and runways is taken from the apt.dat, which has been extended so it can carry information necessary for the avionics. Previously, a separate airports.txt was used to hold information like transition level, longest runway length, etc. Now all this information is taken from apt.dat, which uses the 1302 row code for key-value pairs, which can be edited in WED. The following key-value pairs are part of the apt.dat 1050 specification and are used in X-Plane 11:

  • region_code, this must specify the region according to ICAO document No 7910
  • datum_lat, datum_lon, those specify the location of the airport datum in decimal degrees, North and East positive
  • transition_alt, this must specify the transition altitude in feet
  • transition_level, this must specify the transition level in feet

Note that this data is already populated for most airports in the scenery gateway (Currently there’s a bug in the Gateway that causes incorrect export of these values for some airports. This will be fixed soon). If you find an airport with these values missing or incorrect, use WED 1.5 or later to add/edit these values and upload your change to the scenery gateway.

Correct roles and regions, please

X-Plane 11 distinguishes between global and terminal fixes and navaids. Terminal fixes and navaids must specify the arpt/heli ident of their terminal area, according to the 424.20 5.6 Airport/Heliport Identifier. All fixes and navaids must specify the region ICAO code according to the 424.20 5.14 ICAO code. Note especially the seven regions defined for the continental United States. See ICAO document No 7910 for details.
By classification into terminal vs global items, and assigning the correct parent terminal area or ICAO region, each item in the database is addressable by a globally unique identifier. Only then it is possible to build the layered structure. X-Plane enforces integrity of this unique index, because it is needed to build the graph of the airway network.

Two supported formats

X-Plane 11 supports two formats in which the global database can be provided:

  • ARINC 424 supplements 18 up to 20, with the exceptions noted in the FAA/Aeronautical Information Services CIFP Readme
  • XPNAV1100, as explained further down

Sim-wide ARINC424 override

Professional customers with access to 424 master files can use them to override the X-Plane global database.

Upon sim start, X-Plane will examine the $X-Plane/Custom Data/ folder of its installation for a file named earth_424.dat. If this file is found, it will be interpreted according to the ARINC 424.18 standard with the FAA CIFP exceptions, and will be used to load the following information into X-Plane:

  • Fixes (EA and PC records)
  • Navaids (D, DB and PN records)
  • Airways (ER records)
  • ILS (PI records)
  • Markers (PM records)
  • Airport data (PA records)
  • Airport gate/parking locations (PB records)
  • Airport terminal procedures (PD, PE, PF records)
  • Airport runway information (PG records)
  • Path points (PP records)
  • GLS stations (PT records)
  • GBAS path points (PQ records)

After this file has been read, X-Plane will not load any other information from other text files. It is assumed that when the installation is provided with a global 424 file, no data of any other format needs to be loaded. In particular, X-Plane will then NOT load any of the files described in the following as “Global data”.

Global data

If no global 424 file is present, X-Plane will instead load files of the XPNAV1100/XPFIX1100/XPAWY1100 format. These look superficially similar to the data files of previous versions, but they are fundamentally different in that referential integrity is required, and globally uniqueness with respect to type, code, and region code is enforced at load time. Full file format specifications are available below.

The layered hierarchy of global data

It is important to understand that rather then a full replacement of data, X-Plane 11 allows the data to be organized in layers with increasing priority, where higher priority data overrides the data from all layers below.

The base – what is shipped with X-Plane:

X-Plane 11 ships with a global base layer of data that enables IFR navigation world-wide. The data cycle represented by those files will remain the same over the lifetime of X-Plane 11.
These files are:

  • earth_fix.dat
  • earth_awy.dat
  • earth_nav.dat
  • CIFP/$ICAO.dat (where $ICAO is each airport with instrument procedures)

they are located in $X-Plane/Resources/default data/

The updated base – what is supplied by third-party providers

This layer is what advanced hobbyist users care about. They want updated data, because they want to fly online. Participation in the online networks usually requires fairly recent data. Aerosoft and Navigraph offer newest data by a monthly subscription. This data consists of the files:

  • earth_fix.dat
  • earth_awy.dat
  • earth_nav.dat
  • CIFP/$ICAO.dat (where $ICAO is each airport with instrument procedures)

they must be located in $X-Plane/Custom Data/

These files completely replace the base layer of X-Plane. If these files are present, the X-Plane base layer is ignored. Note that because of the referential integrity, it is not possible to update just the earth_fix.dat and not the earth_awy.dat. Upon load, it is checked that all files are of the same cycle number. Mix-matching different cycles is not supported.

The updated approaches – what we get from the FAA for free

The FAACIFP file is an ARINC424.18 file provided by the Federal Aviation Administration free of charge, and can be downloaded from their website.

In X-Plane 11, this file is used to replace P* records with the latest from the FAA. The following data is read from this file, and overrides data loaded from the global layer:

  • Terminal Fixes (PC records)
  • Terminal Navaids (D records where the 5.6 field is not empty, PN records)
  • ILS (PI records)
  • Markers (PM records)
  • Airport data (PA records)
  • Airport gate/parking locations (PB records)
  • Airport terminal procedures (PD, PE, PF records)
  • Airport runway information (PG records)
  • Path points (PP records)
  • GLS stations (PT records)
  • GBAS path points (PQ records)

The file

  • FAACIFP18

must be located in $X-Plane/Custom Data/

This file is not shipped with X-Plane, but can be obtained from the FAA website free of charge.

Note that no enroute waypoints, VHF enroute navaids, or enroute airways are loaded from this file. These cannot be replaced safely as it would affect the referential integrity of the airway network.

Note that for integrity reasons, the cycle number of the FAA data must always match the cycle number of the underlying layer. Terminal procedures do reference waypoints out of the terminal area, therefore, the data source for global waypoints must be at the same cycle number.

Note also that when FAACIFP is in effect, terminal procedures are overridden on a per-airport basis. No attempt is made to mix-match terminal procedures from global data with those loaded from FAACIFP. As terminal procedures reference terminal waypoints, trying to build terminal procedures from global data with points loaded from FACCIFP could lead to unpredictable results. Therefore, once FAACIFP is in effect, Custom Data/CIFP/$ICAO.dat is overridden for each $ICAO with PD/PE/PF records in FAACIFP.

Hand-placed localizers – how we ensure it works with global scenery

Previously, many users of X-Plane 10 using data products from third-parties have complained of discrepancies between ILS components from this data and airports in X-Plane, leading to ILS signals guiding the airplane besides the runway.

In X-Plane 11, the next layer of navdata that is layered above global and FAACIFP data, is the curated localizer, glideslope and marker data from the scenery gateway.

This file ensures hand-curated localizers collected in the gateway database are working perfectly with the gateway airports.

The file

  • earth_nav.dat

is located in $X-Plane/Custom Scenery/Global Airports/Earth nav data/

and is updated with the gateway airports as necessary via the X-Plane updater. It ensures that hand-corrected localizers match our airports perfectly.

If you encounter a mismatch in runway placement between custom scenery and gateway airports, leading to localizer offsets when using custom scenery, always refer to government data to confirm runway placements. Scenery authors, please don’t try to work around incorrect placements in the X-Plane default scenery or incorporate eventual errors into your own custom scenery. If you encounter airport or runway placements that are not accurate according to government data, always report this as a bug to the scenery gateway, and include a government source with correct data. The goal is to get the X-Plane world as accurate as possible, instead of carrying scenery errors forever.

User data – per-user overrides

The last layer is the user-defined layer.

These files are where all edits made in X-Plane’s map ui are saved. Whenever a fix or navaid is altered through the X-Plane map, its modified entry is saved in the user_* file, which overrides previously loaded information.

The files

  • user_nav.dat
  • user_fix.dat

are located in $X-Plane/Custom Data/

and are non-existent in a default installation of X-Plane and not touched by the updater.

They are created once a fix or navaid was modified through the map GUI in X-Plane. They are the highest layer and ensure user modifications are preserved even with updates from Aerosoft or Navigraph.

ONLY in these user_fix.dat/user_nav.dat can you add or edit the X-Plane world data without being at risk of breaking data integrity. So if you want to add custom fixes or navaids to X-Plane, this is the only safe place to do it.

Note that this does not work for deleting objects that were loaded in a lower layer. You can no longer delete a fix from the UI in a persistent way. If we’d allow for selective deletion of fixes or navaids, airways that might be referencing them would break.

From 424 to XPNAV1100

We provide a simple command line tool called convert424toxp11 that is available free of charge. With this tool, data providers can convert 424.18+ files into navdata guaranteed to be compatible with X-Plane 11.

Do not try to create or edit XPNAV1100/XPFIX1100/XPAWY1100 files by hand. While the format is reasonably human-readable, the data integrity assumptions that are inherent are easily overlooked. Always edit the data in a 424 file, using a tool like the ARINCDecoder v4.3, to ensure validity. Then export the data to X-Plane using the convert424toxp11 command line tool.

How do I make my own approach? No hand editing, please!

In the past, we have been asked how to edit existing procedures or create own, fictional procedures – maybe you want to prototype a future LPV approach into your own backyard airstrip?

Terminal Procedure description follows the coding rules laid out in ARINC 424.20, Attachment 5, “Path and terminator”. Correctly coding procedures obeying all those rules by hand is next to impossible, which is why industry tools have been developed to work with these files.

For X-Plane 10, no tools existed to design custom approaches, and attempts to hand-code them in text were extremely difficult and didn’t work most of the time.

With X-Plane 11, you have the full power of the ARINC424.18+ at your disposal. To evaluate, edit, or even design a new procedure, we strongly recommend the ARINCDecoder v4.3 program, which is an incredibly powerful tool.

Global Data Formats

The files are designed to be easily parsed, have low overhead (no XML!) and will look inherently familiar in structure if you’re familiar with the files for X-Plane 10 already. The file format changes to X-Plane 10 are clearly lined out at the beginning of each document.

Please consider the following file format specifications as a guide how to parse X-Plane 11 navdata, not to generate it (see warning above).

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn