Airport Data (apt.dat) 11.00 File Format Specification

REVISION HISTORY

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 (“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 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 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. 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.
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

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.

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