This RFC proposes new features to the apt.dat format for X-Plane 10.50 to support the X-Plane Scenery Gateway and static aircraft spawning. It consists of two parts: one for static spawning and one for airport identifiers.
This RFC is not a general call for feature requests for the apt.dat format – it aims to solve two specific problems.
Part 1: Static Aircraft Spawning and Aircraft Metrics
In order to make ramp positions more suitable to both AI and static aircraft, the apt.dat 1050 file format includes extra meta-data on parking spots and ATC taxi routes.
Clearance Widths on Taxi Edges
Clearances for aircraft are described using the standard ICAO category codes for aircraft, A-F. Roughly speaking the coding is:
|Wheel Base||Wing Span||Category|
Both parking spots and ATC taxi route (that are not runways) gain a new maximum ICAO category, describing the largest aircraft that can safely operate on this ATC taxi route or parking spot.
For ATC taxi route edges, this is accomplished with 6 new type tokens: where taxiway edges (record type 1202) could normally be one of “runway” or “taxiway”, new “sized” taxiways are permitted: taxiway_A, taxiway_B, taxiway_C, taxiway_D, taxiway_E, taxiway_F. Edges corresponding to runways do not need sizes because X-Plane can determine the runway width from the actual runway (type 100) record.
Additional metadata is included in a new 1301 record, which follows the 1300 (new ramp start) record.
The 1301 record consists of an ICAO width code, an operations type code and zero or more space separated 3-letter airline codes, e.g.
1301 icao_width operations_type [airlines] 1301 C airline AAL SWA UAL
The ICAO width must be one of: A, B, C, D, E, F
The operations type must be one of: none, general_aviation, airline, cargo, military
Additional Equipment Classes
A new equipment class is introduced, “fighters” – it is allowed anywhere that the original five equipment classes (heavy, jets, turboprops, props and helos) are allowed.
For ramp starts, this is accomplished by allowing a size flag (A, B, C, D, E, or F) to be included in a new extended ramp start (type 1301) record.
Ramp Operation Types
Ramps gain a new field: “operations type,” indicating what kind of AI or static aircraft appear there. Can be set to: none, general_aviation, airline, cargo, military.
A ramp start may optionally tagged with a set of valid 3-letter ICAO airline codes, which must be entered as capital letters.
Part 2: Airport Identification Meta-Data
Historically, the apt.dat file provided a single identifier field, sometimes referred to as an ICAO identifier. This identifier was a mandatory primary key for the airport, and therefore if an ICAO code did not exist for an airport, some non-ICAO code had to be made up and stuffed in this field. For US airports, typically an FAA code was used, and for non-US airports, there was no clear standard. Recently the X-Plane Scenery Gateway project designed a fixed rule-set to create non-conflicting synthetic identifiers by extending the field beyond four characters.
Finding an airport by identifier can thus be challenging; if the identifier is synthetic, searching by an IATA code or a local authority code will not work.
This extension aims to solve this problem by separating the primary airport identifier key (whose goals are uniqueness and stability) from other meta-data keys aimed at airport discovery (e.g. to aid search).
Going forward, the airport identifier referred to in the type 1, 16 or 17 record is known as an airport identifier, and is required to be a globally unique identifier for a particular real-world airport. The identifier can be synthetic or match a real world authority, but it cannot be ambiguous, and it cannot be omitted.
Each airport may have zero or more meta-data records, record code 1302, which is defined as
1302 key value
1302 icao_id KBOS 1302 faa_id BOS 1302 iata_id BOS
A key may not appear more than once per airport amongst all 1302 records. Keys must not contain white space or commas but values may.
The legal semantics of a given key (e.g. global uniqueness, accepted character set) is defined on a per-key basis; the only guarantees of the file format itself are file-valid (UTF8) characters, no white space or commas in keys, no newlines in keys or values, and no repeating keys. No key is mandatory. An empty key is illegal. Only officially defined, supported, conforming, and non-empty keys are allowed.
For the purposes of the initial specification, the following keys are being officially defined:
|icao_id||ICAO airport identifier code||EDDF|
|faa_id||FAA airport identifier (“LID”)||MA52|
|iata_id||IATA airport code||FRA|
|country_id||Country name||United States|