Tools
World Editor (WED) is a free, open source tool for airport scenery creation.
The Aviation Formulary is a treasure trove of useful formulae used in aviation, usually explained in easy-to-understand terms.
A good text editor is often useful, to review and search the data files, such as Notepad++ for Windows. Amongst other features, it will convert files between Windows, Mac and Linux formats.
‘Real-world’ aviation data sources
X-Plane relies upon publicly-available, freely-available data sources. We cannot reverse-engineer proprietary databases and use that data. Of course, it is hard to find high-quality, global data that meet these criteria.
There are many sources of ‘real world’ aviation data, and each country often has its own process for maintaining and publishing its data. Some make their data freely available, but others regard this data as a valuable asset to which a high price is associated! Within the USA, data is available by subscription for a nominal fee from the FAA’s National Flight Database (NFD).
Common sources of data are AirNav.com and World Aero Data. The National Aeronautical Charting Office (NACO) gives free access to all US airport and instrument approach charts (other sources offering the same data include AOPA, if you are a member). Many countries offer some kind on on-line access to their aviation data and/or charts – for example, the UK NATS site has detailed colour charts of all UK aerodromes.
Google Earth, Google Maps, Live Search Maps and TerraServer all have a role to play in airport design. Depending upon the imagery available, these tools can provide detailed aerial views of many airports. Ortho-rectification of the images is usually good, but remember to switch off any features that try to show 3D terrain (this can distort the images).
Google Earth can be used to obtain latitude/longitude positions for many features (remember to set the format of the lat/lon to decimal degrees in the Tools/Options menu).
The ‘birds eye’ view on Live Search Maps offers extremely detailed imagery – good enough in many cases so that taxiway signs can be read. But coverage is limited.
‘Real-world’ concepts
The US FAA has published standards for the design of airports:
FAA Aeronautical Information Manual (a very important resource for any aviator).
FAA AC on airport design (a large PDF file).
Magnetic variation: All X-Plane data that contains directional/heading information is defined as a true headings. But published data for localizers almost is always expressed on charts as a magnetic heading, so these need to be converted to a true heading for our data files to ensure correct alignment in X-Plane. But … one ‘gotcha’ is that localizers (and other nav-aids) can be edited within X-Plane itself (on the map screen), and here the bearing is shown as magnetic (on the assumption that users may be trying to build an ILS based upon a real-world chart). The data will be automatically converted to a true heading when X-Plane saves the data.
Global data: X-Plane’s data coverage is global. Different countries often have different standards for the definition and use of their aviation data.
Many pilots who fly only within the USA believe that altimeters should always be switched from a local barometric setting to a standard setting (29.92 inches or 1013 hPa) when climbing through 18,000 feet (the Transition Altitude). But in many countries the TA is much lower, and may even vary within a country (it is usually printed on airport diagrams and approach charts). For example, the TA is at 3,000 feet over much of England, so it is normal for a VFR pilot to cruise at FL40.
The UK and some other countries uses different types of runway markings – these are available in X-Plane, but must be explicitly selected in WED.
Taxiway signs and painted markings are generally consistent around the world, but stylistic difference do exist.
Double check the units of measure: Many countries use a complex mix of metric and imperial units in aviation. The USA generally uses imperial units (but uses the Celsius scale for temperatures). Many other countries use metric units for all measurements, except for elevations (which are – usually – in feet). So, it’s easy to look at an airport diagram and to forget to convert a measurement to the appropriate units for X-Plane. For example, X-Plane now requires all distances (such as displaced thresholds, blastpads) to be defined in metres in its data files, though elevations are still defined in feet.
REVISION HISTORY
16 Nov 2021 Updated new lines styles added in 11.30, correct wording in rowcode 21 name field.
11 April 2019 Updated with new COM frequency capabilities added in 11.30.
14 Feb 2018 Minor corrections to Definition of Data fields.
11 April 2017 Revised row code 1201.
18 Jan 2017 Spec created.
APPLICABILITY
This specification (APT.DAT 1100) is supported in X-Plane 11.00 and later and by WorldEditor 1.6b1 and later. The prior specification for airport data was APT.DAT 1050, which is recommended for X-Plane 10.50+. This spec is an extension to 1050 – all features in 1050 are fully supported.
SUPPORT FOR DEPRECATED FILE FORMATS
The deprecated file specification (APT.DAT 1050, 1000) is still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to this specification can be included in a file otherwise complying with the APT.DAT 1100 specification.
The specification for APT.DAT 1050 is available to view here.
OVERVIEW & SCOPE
This specification defines core airport data for X-Plane. This includes the locations of runways, taxiway and apron pavement, basic airport ‘furniture’ (VASI/PAPIs, windsocks, light beacons and taxiway signage) and communications frequencies. It also includes attributes for each of these features to fully describe them (eg. it includes runway surface type, runway markings, taxiway lighting and markings, approach lighting, taxiway sign text, etc).
This specification (1100) introduces new service truck parking and destination features.
This specification does not include scenery objects (such as buildings, static aeroplanes or underlying terrain textures).
BASIC CONCEPTS
- Latitudes and longitudes are described in a decimal notation (eg. 20.12345678) up to 8 decimal places.
- A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
- North latitudes and east longitudes are positive. South latitudes and west longitudes are negative.
- All headings are referenced to true north (not magnetic north).
FILE CHARACTERISTICS
The apt.dat files are plain text files:
- Fields in the data can be separated by one or more white space characters (space, tab).
- By default, the files are generated so that columns of data are consistently aligned, but this is not required.
- Blank rows are permitted and are helpful to differentiate between airports.
- Comments are permitted and are indicated by “#” as the first two characters of a row.
FILE STRUCTURE
It is recommended that all airports be created in WorldEditor (“WED”). This will ensure that all structural requirements listed here for airport data are met. WED version 1.6 is required to support the features in this spec.
In common with most other X-Plane data file specification, header rows of data define the origin of a particular copy of a file, and define the file specification version. The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a copyright message:
I
1000 Version - data cycle 2012.03, build 20121054, metadata AptXP1000. Copyright © 2012, Robin A. Peel (robin@xsquawkbox.net)...
The complete copyright message must be left intact if you redistribute this data. The GNU GPL (general public License) under which this data is released is designed to encourage modifications, enhancements and redistribution, even in commercial derivative products.
Subsequent rows of data follow a hierarchical structure:
- Each row of data has a numeric ‘row code’ as its first field, to define its content.
- The top level of this hierarchy defines an individual airport, defined by an airport header row (a row code of ‘1’, ‘16’ or ‘17’).
- Subsequent rows define elements of an airport:
- Runways (including helipads) follow the airport header row (one row per runway).
- Pavement (taxiway/apron) definitions have a header row followed by an ordered list of nodes that define its boundaries:
- Each pavement definition must each have a single boundary with no overlaps with itself.
- Nodes on this outer boundary must be defined in a counter-clockwise direction.
- Boundaries must be terminated with a node with a row code ‘113’ or ‘114’.
- Pavement definitions may overlap with another pavement chunk. But this is not recommended – instead consider precise alignment of adjacent features by ‘snapping’ nodes to identical locations in World Editor (WED).
- A pavement definition can never overlap with itself.
- The sequencing of the pavement definitions is the layering in which they will be rendered in X-Plane, top-down. So the last piece of pavement in the file will be rendered underneath any others with which it overlaps.
- Holes can be defined for pavement (through which the underlying terrain texture will show):
- Hole boundaries should follow the termination of the pavement definition in which the hole occurs (starting with a row type ‘111’ or ‘112’).
- Hole boundaries are defined in a clockwise direction (ie, opposite direction to the boundary nodes).
- Hole boundaries must form a closed loop (ie. must terminate with a row code ‘113’ or ‘114’).
- Each pavement definition can have zero, one or multiple hole boundaries.
- Hole boundaries must be contained within the outer boundary of the pavement definition.
- Holes cannot overlap each other.
- After creating a hole boundary, it can be ‘filled’ with a new pavement chunk (probably using a different surface type).
- Linear features also have a header row followed by an ordered list of nodes that define the line:
- Linear features can be closed loops (terminating in a node of type ‘113’ or ‘114’) or just strings (terminating with ‘115’ or ‘116’).
- An airport boundary is defined with nodes in a counter-clockwise direction. A boundary can contain holes (see above) and must form a closed loop (terminating in a node of type ‘113’ or ‘114’).
- Airport traffic flows have a header row (row code ‘1000’) followed by multiple rows that define rules of multiple classes (time, wind direction, ceiling, visibility, runway in use, VFR traffic pattern) that indicated that a flow should be used (wind rules, minimum ceiling rules, visibility rules, time rules, and operations rules).
- A flow is acceptable is any rule of a class is acceptable, or if there are no rules of a given class. So to permit a flow with no time restrictions, simple exclude any traffic time rules (row code ‘1004’).
- Rules use ‘or’ logic. For example, a flow may have two wind rules (row code ‘1001’) – one for slight winds very generally aligned with a runway, and one with strong winds only if they are almost exactly with the runway.
- A flow will be used only if all its rule classes are ‘passed’.
- The flows are evaluated in sequence. The first flow to ‘pass’ will be used. So, the most specific-but-useful rule should be listed first (eg. parallel VFR approaches on a clear, calm day) and the most general (but least useful) rules should be listed last (eg. a single ILS cat III approach to a single runway).
- If the rules prevent any defined flow from being ‘passed’ then the X-Plane’s AI engine will create a flow.
- ‘Runway in use’ rules (row code 1100} are also evaluated in sequence. The first ‘runway in use’ rule to ‘pass’ will be used for the parent flow. So rules should be listed in preferential sequence.
- Airport taxi routes & networks begin with a row code ‘1200’ and are defined by a set of nodes (row code ‘1201’) and ‘edges’ (the taxi routing) that connect two nodes (row code ‘1202’):
- Nodes can be defined as ‘init’ (a point at which X-Plane will try to start a taxi route), ‘end’ (where X-Plane will try to end a taxi route), or ‘both’. ‘junc’ can also be used for junctions between taxi routes.
- Edges must specify an allowed width, sizes A-E, and may be followed by multiple rows (row code ‘1204) defining an ‘active zone’ ‘for that parent edge (eg. if the edge conflicts with arrival or departure runways, or an ILS-critical area).
- Taxi routings begin or end at ramp locations (row code ‘1300’), which are also available as startup-locations in X-Plane. These locations may not be directly connected to the taxi route network – X-Plane’s ATC engine will calculate how to direct an airplane between the taxi route network and each location.
- Ground truck route edges (row code ‘1206’), parking locations (row code ‘1400’), and destinations (row code ‘1401’) are included under row code header ‘1200’ for taxi networks.
- Other airport features are defined with one row for each feature.
The file is terminated by a ‘99’:
99
ROW CODES
Each row of data begins with an integer code that defines the type of data:
| Row Code |
Meaning |
Comment |
| 1 |
Land airport header |
|
| 16 |
Seaplane base header |
|
| 17 |
Heliport header |
|
| 100 |
Runway |
|
| 101 |
Water runway |
|
| 102 |
Helipad |
|
| 110 |
Pavement (taxiway or ramp) header |
Must form a closed loop. |
| 120 |
Linear feature (painted line or light string) header |
Can form closed loop or simple string |
| 130 |
Airport boundary header |
Must form a closed loop |
| 111 |
Node |
All nodes can also include a “style” (line or lights) |
| 112 |
Node with Bezier control point |
Bezier control points define smooth curves |
| 113 |
Node with implicit close of loop |
Implied join to first node in chain |
| 114 |
Node with Bezier control point, with implicit close of loop |
Implied join to first node in chain |
| 115 |
Node terminating a string (no close loop) |
No “styles” used |
| 116 |
Node with Bezier control point, terminating a string (no close loop) |
No “styles” used |
| 14 |
Airport viewpoint |
One or none for each airport |
| 15 |
Aeroplane startup location |
*** Convert these to new row code 1300 *** |
| 18 |
Airport light beacon |
One or none for each airport |
| 19 |
Windsock |
Zero, one or many for each airport |
| 20 |
Taxiway sign (inc. runway distance-remaining signs) |
Zero, one or many for each airport |
| 21 |
Lighting object (VASI, PAPI, Wig-Wag, etc.) |
Zero, one or many for each airport |
| 1000 |
Airport traffic flow |
Zero, one or many for an airport. Used if following rules met (rules of same type use ‘or’ logic, rules of a different type use ‘and’ logic). First flow to pass all rules is used. |
| 1001 |
Traffic flow wind rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
| 1002 |
Traffic flow minimum ceiling rule |
Zero or one rule for each flow |
| 1003 |
Traffic flow minimum visibility rule |
Zero or one rule for each flow |
| 1004 |
Traffic flow time rule |
Zero, one or many for a flow. Multiple rules use ‘or’ logic. |
| 1100 |
Runway-in-use arrival/departure constraints, 10kHz frequency resolution |
First constraint met is used. Sequence matters! |
| 1110 |
Runway-in-use arrival/departure constraints, 1kHz frequency resolution |
Alternate option to row code 1100 |
| 1101 |
VFR traffic pattern |
Zero or one pattern for each traffic flow |
| 1200 |
Header indicating that taxi route network data follows |
| 1201 |
Taxi route network node |
Sequencing must be 0 based, ascending by ID. Must be part of one or more edges. |
| 1202 |
Taxi route network edge |
Must connect two nodes. Also takes one of 6 sizes (A-F). |
| 1204 |
Taxi route edge active zone |
Can refer to up to 4 runway ends |
| 1300 |
Airport location (deprecates code 15) |
Not explicitly connected to taxi route network |
| 1301 |
Ramp start metadata. |
Includes width, operations type, equipment type, & airlines. |
| 1302 |
Metadata records |
Zero or many for each airport. |
| 1400 |
Truck Parking Location |
Not explicitly connected to taxi route network. |
| 1401 |
Truck Destination Location |
Not explicitly connected to taxi route network. |
| 1050-1056 |
8.33kHz communication frequencies (11.30+) |
Zero, one or many for each airport |
| 50 – 56 |
Legacy 25kHz communication frequencies |
Zero, one or many for each airport. Ignored if row codes 1050-1056 exist. |
EXAMPLE DATA
Here is some example data for KBFI. It is not real and is very incomplete, but it illustrates examples of most types of data found in an apt.dat file. This data includes an airport header, runway, water runway, helipad, PAPI, taxiway definition, painted line, viewpoint, startup location, light beacon, windsock, taxiway sign and an ATC communications frequency:
1 21 1 0 KBFI Boeing Field King Co Intl
100 29.87 1 0 0.15 0 2 1 13L 47.53801700 -122.30746100 73.15 0.00 2 0 0 1 31R 47.52919200 -122.30000000 110.95 0.00 2 0 0 1
101 49 1 08 35.04420900 -106.59855700 26 35.04420911 -106.59855711
102 H1 47.53918248 -122.30722302 2.00 10.06 10.06 1 0 0 0.25 0
21 47.53666659 -122.30585255 2 150.28 3.30 13L PAPI-2L
110 1 0.25 150.29 A2 Exit
111 47.53770968 -122.30849802
111 47.53742819 -122.30825844 3
112 47.53752190 -122.30826710 47.53757385 -122.30824831 3 102
114 47.53768630 -122.30834929 47.53768690 -122.30838150 3 102
120 Line B1
111 47.53969864 -122.31276189 51
111 47.53977825 -122.31255145 1
115 47.54002296 -122.31189878
14 47.52917900 -122.30434900 100 0 ATC Tower
15 47.52926674 -122.29919589 304.16 A8 Run Up
18 47.52920400 -122.30412800 1 BCN
19 47.53900921 -122.30868700 1 WS
20 47.54099177 -122.31031317 235.71 0 2 {@L}A1{@R}31R-13L
50 12775 ATIS
Here is some example data for KSEA showing the new 1000 version traffic flow and taxi route data:
1000 Calm and South flow
1001 KSEA 000 359 5
1001 KSEA 070 250 999
1002 KSEA 0
1003 KSEA 0
1004 0000 2400
1100 16C 11920 arrivals jets|turboprops|props 160340 161161 Arrival 16C
1100 16R 11920 arrivals jets|turboprops|props 341159 161161 Arrival 16R
1100 16L 11920 arrivals heavy 000359 161161 Arrival Heavy Jets
1101 16R right
1200
1201 47.46360812 -122.30613338 both 5416 A_stop
1202 5258 5266 twoway taxiway B
1204 ils 34R
1300 47.43931757 -122.29806851 88.78 gate jets|turboprops A10
Here is some example data for KSEA showing the 1050 metadata and 1100 ground truck additions:
1000 Calm and South flow
1001 KSEA 000 359 5
1001 KSEA 070 250 999
1002 KSEA 0
1003 KSEA 0
1004 0000 2400
1100 16C 11920 arrivals jets|turboprops|props 160340 161161 Arrival 16C
1100 16R 11920 arrivals jets|turboprops|props 341159 161161 Arrival 16R
1100 16L 11920 arrivals heavy 000359 161161 Arrival Heavy Jets
1101 16R right
1200
1201 47.46360812 -122.30613338 both 5416 A_stop
1202 5258 5266 twoway taxiway B
1204 ils 34R
1300 47.43931757 -122.29806851 88.78 gate jets|turboprops A10
DEFINITION OF DATA FIELDS
For a complete table of example definitions, download the APT1100 Spec pdf document.
This information is historic and only relevant to X-Plane 10 and earlier
REVISION HISTORY
12 Nov 2015 Update to move spec to developer site
7 May 2009 Spec converted to this new format to support new web site (//data.x-plane.com).
8 Sept 2009 Error in usage of row type 13 fixed in “applicability” section below.
31 May 2010 Corrected error in specification of VOR and localizer radio frequencies. Added elevations to NDB spec. Corrected references to apt.dat.
29 July 2011 Fixed minor error in definition of nav-aid frequencies
27 Oct 2011 Fixed minor error in definition of glideslope approach angle
8 July 2012 Corrected error in definition of nav-aid ranges
This specification (XP NAV810) is supported in X-Plane 8.10 to X-Plane 10.52. It is identified in the data files as “810 Version” on the second row of the file. The prior specification for airport data was XP NAV740, which is recommended for X-Plane 7.40 – 8.09.
Changes in the spec for XP NAV810 were:
A new row code for DMEs (13) for which the frequency display will be shown on X-Planes charts. DMEs with a row type 12 will have their frequency display suppressed on X-Plane’s chart to prevent clutter (such DMEs are usually co-located with a VOR or an ILS).
OVERVIEW & SCOPE
This specification defines all radio navigation data for X-Plane, including NDBs, VORs (inc. VORTACs and VOR-DMEs), and ILS components (localisers, glideslopes, marker beacons). The effect of this data is to:
- Allow these radio navigation facilities to be used when flying in X-Plane.
- Display the navigation facilities on X-Plane’s chart.
- Render objects in the X-Plane scenery system to represent each facility
BASIC CONCEPTS
- Latitudes and longitudes are described in a decimal notation (eg. 20.12345678).
- A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
- North latitudes and east longitudes are positive. South latitudes and west longitudes are negative.
- All headings are referenced to true north (not magnetic north). X-Plane has an internal model of magnetic variation
FILE CHARACTERISTICS
The earth_nav.dat (and nav.dat) files are plain text files:
- Fields in the data can be separated by one or more white space characters.
- By default, the files are generated so that rows of data are consistently aligned, but this is not required.
FILE STRUCTURE
The navigation data can be edited in X-Plane in the “Location | Local Map” view, and by clicking on the “edit” button at the top of the screen. If data is changed here, then X-Plane will ask for confirmation that the new data should be saved when quitting X-Plane. This will ensure that all structural requirements listed here for airport data are met.
[Note that the current version of X-Plane displays headings for an ILS in magnetic degrees on this screen, but that this data is converted to a true heading when the data is saved to earth_nav.dat.]
In common with most other X-Plane data file specification, header rows of data define the origin (PC or Mac) of a particular copy of a file, and define the file specification version. The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a copyright message:
I
810 Version - data cycle 2009.01, build 20081054, metadata NavXP810. Copyright © 2009, Robin A. Peel (robin@xsquawkbox.net)...
The complete copyright message should be left intact if you redistribute this data. The GNU GPL (general public License) under which this data is released is
designed to encourage modifications, enhancements and redistribution, even in commercial derivative products.
Subsequent rows of data define each nav-aid. Sequence is not important, but by default this file is sorted by row code, then by nav-aid name.
The file is terminated by a ‘99’.
ROW CODES
Each row of data begins with an integer code that defines the type of data:
| Row Code |
Meaning |
Comment |
| 2 |
NDB (Non-Directional Beacon) |
Includes NDB component of Locator Outer Markers (LOM) |
| 3 |
VOR (including VOR-DME and VORTACs) |
Includes VORs, VOR-DMEs and VORTACs |
| 4 |
Localiser component of an ILS (Instrument Landing System) |
|
| 5 |
Localiser component of a localiser-only approach |
Includes for LDAs and SDFs |
| 6 |
Glideslope component of an ILS |
Frequency shown is paired frequency, not the DME channel |
| 7 |
Outer markers (OM) for an ILS |
Includes outer maker component of LOMs |
| 8 |
Middle markers (MM) for an ILS |
|
| 9 |
Inner markers (IM) for an ILS |
|
| 12 |
DME, including the DME component of an ILS, VORTAC or VOR-DME |
Frequency display suppressed on X-Plane’s charts |
| 13 |
Stand-alone DME, or the DME component of an NDB-DME |
Frequency will displayed on X-Plane’s charts |
EXAMPLE DATA
Here is some example data for the Seattle, Washington, USA area (note the separate data row for the DME component of the Seattle VORTAC):
2 47.63252778 -122.38952778 0 362 50 0.0 BF NOLLA NDB
3 47.43538889 -122.30961111 354 11680 130 19.0 SEA SEATTLE VORTAC
4 47.42939200 -122.30805600 338 11030 18 180.343 ISNQ KSEA 16L ILS-cat-I
6 47.46081700 -122.30939400 425 11030 10 300180.343 ISNQ KSEA 16L GS
8 47.47223300 -122.31102500 433 0 0 180.343 ---- KSEA 16L MM
12 47.43433300 -122.30630000 369 11030 18 0.000 ISNQ KSEA 16L DME-ILS
12 47.43538889 -122.30961111 354 11680 130 0.0 SEA SEATTLE VORTAC DME
DEFINITION OF DATA FIELDS
For a complete table of example definitions, download the NAV810 Spec pdf file.
This information is historic and only relevant to X-Plane 10 and earlier
This specification defines all fixes (also known as intersections) X-Plane 10. The effect of this data is to:
- Allow these fixes to be selected in X-Plane’s GPS and FMC systems.
- Display the fixes on X-Plane’s charts.
BASIC CONCEPTS
- Latitudes and longitudes are described in a decimal notation (eg. 20.12345678).
- A latitude of 50 degrees 30 minutes south would be defined as -50.50000000
- North latitudes and east longitudes are positive. South latitudes and west longitudes are negative.
- Unlike other data files, no ‘row codes’ are used for fix data, since the file contains just one type of data.
FILE CHARACTERISTICS
The earth_fix.dat files are plain text files:
- Fields in the data can be separated by one or more white space (space, tab) characters.
- By default, the files are generated so that columns of data are consistently aligned, but this is not required.
FILE STRUCTURE
- In common with most other X-Plane data file specification, header rows of data define the origin (“I” = PC or “A” = Mac) of a particular copy of a file, and define the file specification version. The file specification may be followed by a reference to a sequential release data cycle and build number for the data, and a copyright message.
- Subsequent rows of data define each nav-aid. Sequence is not important, but by default this file is sorted by row code, then by nav-aid name.
- The file is terminated by a ‘99’.
EXAMPLES
Here is example data for a fix:
37.428522 -097.419194 ACESI
DEFINITION OF DATA FIELDS
| Meaning of example fix data (fix.dat) |
| Fix example |
Example Usage |
| 37.428522 |
Latitude of NDB in decimal degrees. Eight decimal places supported. |
| -097.419194 |
Longitude of NDB in decimal degrees Eight decimal places supported. |
| ACESI |
Name of fix. Usually five characters. Unique within an ICAO region. |
This information is historic and only relevant to X-Plane 10 and earlier
The awy.dat file defines all airway segments in X-Plane 10. This data is used in X-Plane 10 to draw high and low level airways on X-Plane’s charts.
File structure
The file structure is similar to all other X-Plane data files.
- The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and big-endian/little-endian issues.
- The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “640 version” implies that this file format was first available for use in X-Plane version 6.40). The version number is followed by Robin Peel’s long copyright message that also includes the sequential build number of the data and internal code for the metadata that drives the formatting. This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
- The very last line of each file is marked by a “99”.
Here is an example of the two header lines, three airway segments and the file termination line:
I
600 Version - DAFIF data cycle 200502, build 1922, metadata AwyXP640, Copyright © 2005, Robin A. Peel (robin@xsquawkbox.net). This data is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program ("AptNavGNULicence.txt"); if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. This product was developed using DAFIF (the Defense Aeronautical Flight Information File), a product of the US National Imagery and Mapping Agency (NIMA). NIMA requires the following warranty statements: (A) Under 10 U.S.C. 456, no civil action may be brought against the United States on the basis of the content of a navigational aid prepared or disseminated by either the former Defense Mapping Agency (DMA) or the National Imagery and Mapping Agency (NIMA). (B) The DAFIF product is provided "as is," and no warranty, express or implied, including, but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NIMA as to the accuracy and functioning of the product. (C): Neither NIMA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of this product. The user agrees to hold harmless the United States National Imagery and Mapping Agency. The user's sole and exclusive remedy is to stop using the DAFIF product.
ABCDE 32.283733 -106.898669 ABC 33.282503 -107.280542 2 180 450 J13
ABC 33.282503 -107.280542 DEF 35.043797 -106.816314 2 180 450 J13
DEF 35.043797 -106.816314 KLMNO 35.438056 -106.649536 2 180 450 J13-J14-J15
99
Sequencing of data is conceptually unimportant. By default the segments are sorted by the initial “from” fix and then by the “to” fix.
Example data
Here is a simplified data fragment for three airway segments in awy.dat:
ABCDE 32.283733 -106.898669 ABC 33.282503 -107.280542 2 180 450 J13
ABC 33.282503 -107.280542 DEF 35.043797 -106.816314 2 180 450 J13
DEF 35.043797 -106.816314 KLMNO 35.438056 -106.649536 2 180 450 J13-J14-J15
The meaning of this data is (subject to change):
| Meaning of example airway data |
| Airway example |
Example Usage |
| ABCDE |
Name of intersection or nav-aid at the beginning of this segment (the fix ABCDE in this example). |
| 32.283733 |
Latitude of the beginning of this segment. |
| -106.898669 |
Longitude of the beginning of this segment. |
| ABC |
Name of intersection or nav-aid at the end of this segment (the nav-aid ABC in this example). |
| 33.282503 |
Latitude of the end of this segment. |
| -107.280542 |
Longitude of the end of this segment. |
| 2 |
This is a “High” airway (1 = “low”, 2 = “high”). If an airway segment is both High and Low, then it should be listed twice (once in each category). This determines if the airway is shown on X-Plane’s “High Enroute” or “Low Enroute” charts. |
| 180 |
Base of airway in hundreds of feet (18,000 feet in this example). |
| 450 |
Top of airways in hundreds of feet (45,000 feet in this example). |
| J13 |
Airway segment name. If multiple airways share this segment, then all names will be included separated by a hyphen (eg. “J13-J14-J15”) |
The astro.dat file defines the astronomical data used by X-Plane. It consists of a list of stars, their positions and brightness (magnitudes).
File structure
The file structure is similar to all other X-Plane data files.
- The first line of each file indicates if the file was generated on a PC (“I” for Intel or IBM) or Macintosh (“A” for Apple). X-Plane uses this code to help deal with the different ways in which PCs and Macs manipulate carriage returns in text files, and big-endian/little-endian issues.
- The second line contains a version number used by X-Plane. This usually implies the first version of X-Plane that can utilise the file format (eg. “640 version” implies that this file format was first available for use in X-Plane version 6.40). The version number is followed by Robin Peel’s long copyright message that also includes the sequential build number of the data and internal code for the metadata that drives the formatting. This copyright message is very long, and includes a reference to the GNU General Public Licence under which this data is published as modifiable freeware, and also an acknowledgement and a disclaimer for the US Department of Defense NIMA for the DAFIF data. The terms of this license require that this copyright message must be left intact if this file is modified and/or redistributed.
- The very last line of each file is marked by a “99”.
Here is an example of the two header lines, one star and the file termination line:
I
740 Version - DAFIF data cycle 200502, build 1922, metadata AstroXP740, Copyright © 2005, Robin A. Peel (robin@xsquawkbox.net). This data is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program ("AptNavGNULicence.txt"); if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307, USA. This product was developed using DAFIF (the Defense Aeronautical Flight Information File), a product of the US National Imagery and Mapping Agency (NIMA). NIMA requires the following warranty statements: (A) Under 10 U.S.C. 456, no civil action may be brought against the United States on the basis of the content of a navigational aid prepared or disseminated by either the former Defense Mapping Agency (DMA) or the National Imagery and Mapping Agency (NIMA). (B) The DAFIF product is provided "as is," and no warranty, express or implied, including, but not limited to the implied warranties of merchantability and fitness for particular purpose or arising by statute or otherwise in law or from a course of dealing or usage in trade, is made by NIMA as to the accuracy and functioning of the product. (C): Neither NIMA nor its personnel will be liable for any claims, losses, or damages arising from or connected with the use of this product. The user agrees to hold harmless the United States National Imagery and Mapping Agency. The user's sole and exclusive remedy is to stop using the DAFIF product.
6.752569 -16.713143 -1.43 Sirius
99
Sequencing of data is conceptually unimportant. By default the segments are sorted by the initial “from” fix and then by the “to” fix.
Example data
This file contains each star’s position (Right Ascension and Declination), visible magnitude and an optional name. X-Plane dynamically converts these astronomical co-ordinates into positions in the sky appropriate to your location, date and time. So you should recognise appropriate constellations as you fly. To fully understand the use of Right Ascension, Declination, sidereal time, and other astronomical issues, you may need to look at a basic reference book on astronomy.
Example lines of data from astro.dat are:
6.752569 -16.713143 -1.43 Sirius
19.846301 8.867385 0.77 Altair
2.529743 89.264138 1.97 Polaris
The meaning of the first line of this data for Sirius (the brightest star in the sky) is:
| Meaning of example star data (star.dat) |
| Star example |
Example Usage |
| 6.752569 |
Right Ascension in decimal hours. Always a positive number. |
| -16.713143 |
Declination in decimal degrees. Positive declinations are north of the celestial equator (eg. the pole star, Polaris, is at a declination of 89.264138 degrees). |
| -1.43 |
Visible magnitude of the star. This is a weird logarithmic scale (low numbers are brightest), and stars to a magnitude of +6.5 are considered visible to the naked eye (though this will vary hugely with your local seeing conditions, light pollution, altitude, etc.). Sirius (the brightest star in the night sky) has a negative magnitude (-1.43) because it is very, very bright. |
| Sirius |
Star name (optional – not used by X-Plane). |
