This information is historic and only relevant to X-Plane 10 and earlier
REVISION HISTORY
12 Mar 2012 Spec created, based upon prior apt.dat 850 spec. 14 Mar 2012 Minor updates & corrections 10 Apr 2013 Updates on airport traffic flows and taxi networks based on Ben’s feedback
APPLICABILITY
This specification (APT.DAT 1000) is supported in X-Plane 10.00 and later and by WorldEditor 1.2 and later. The prior specification for airport data was APT.DAT 850, which is recommended for X-Plane 8.60 – 9.70. This spec is an extension to 850 – all features in 850 are fully supported. However it is recommended that old data for ramp start locations (row code 15) be upgraded to the new row code 1300.
SUPPORT FOR DEPRECATED FILE FORMATS
The deprecated file specification (APT.DAT 810) is still supported. A dwindling quantity of custom airport data exists only in this format. So airports defined according to this specification (APT.DAT 810) can be included in a file otherwise complying with the APT.DAT 1000 specification.
The specification for APT.DAT 810 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 (1000) introduces new airport data to define arrival and departure traffic flows to airports and taxi networks & routings for AI-controlled airplanes.
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
All airports must be created in WorldEditor (“WED”). This will ensure that all structural requirements listed here for airport data are met. WED version 1.2 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 (“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:
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 may be optionally 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 airport locations (row code ‘1300’), which are also available as startup-locations in X-Plane. These locations are not 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.
- 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 | First constraint met is used. Sequence matters! |
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 is arbitrary. Must be part of one or more edges. |
1202 | Taxi route network edge | Must connect two nodes |
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 |
50 – 56 | Communication frequencies Zero, one or many for each airport |
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
DEFINITION OF DATA FIELDS
For a complete table of example definitions, download the APT1000 Spec pdf document.