About the Scenery/Airports folder

This article gives an introduction to the $FG_SCENERY/Airports folder.

Traditionally, the "three main sources of FlightGear users' joy" are tightly coupled together:

• The base package depends on the SimGear and FlightGear source, mainly because aircraft features are being developed in sync with the available FDM and rendering facilities.
• The scenery on the other hand depends on the base package because we rely on deriving runway threshold positions and other geographic entities from the files which are shipped as a part of the base package.

From FlightGear 2.0.0 onwards, efforts have been made to untie the scenery from this dependency chain, leading to the $FG_SCENERY/Airports/ directory.

History

The task was to achieve this goal by a solution as minimalistic as possible, still keeping compilance with traditional rules in the FlightGear development process. In other words, deriving an absolute minimal subset, basically: the geographic information that is required to match with the scenery airport layout, from the respective sources and store this in a 'traditional' file format that, as usual, allows every contributor to verify his contributions before submitting to some general repository.

Several entities were identified as overlapping between the visual representation of airfields in the scenery and the respective data files in the base package, namely:

1. Threshold positions and orientation (typical startup positions).
2. ILS positions and orientation (apparently depends on runways).
3. Taxiway ground network (we do not want AI airliners to taxi off the tarmac).
4. Aircraft parking positions (to avoid airliners parking on the grass or inside the terminal building).

This information is stored in a couple of XML files in the relatively new $FG_SCENERY/Airports/ directory alongside the well known Terrain/ and Objects/ directories. The directory is organized using sort of a poor-man's alphabetical index, using three stages of subdirectories: Airports/[I]/[C]/[A]/ (with the three first characters of the ICAO code).

Note, this directory structure is not meant to be used primarily as a datasource during runtime. Instead, this directory structure is designed as a transport to be editable by the average developer. A tool to create a condensed runtime-extract is being prepared and is expected to get introduced until the next FlightGear software release is due.

Transition period

For the transition periode (FlightGear 2.0.0 till 2.4.0), a new property was introduced. Users of those versions can choose which set of data to use, by toggleing the property /sim/use-custom-scenery-data.

Whenever this boolean property is set to false, ground network data will be read from $FG_ROOT/AI/Airports/[ICAO] and when set to true, it is read from $FG_SCENERY/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.

This property controls the following:

• Reading of startup information: When set to "true", the runway dimension data in apt.dat are overwritten by those in the $FG_SCENERY/Airports/[I]/[C]/[A], so that there is more flexibility in regenerating the terrain tiles without having to force the updated runway positions back into apt.dat.
• Use of ground networks.
• Runway-use files.

References Martin Spott (16 August 2008). Shipping the most relevant airport data with the Scenery. Durk Talsma (22 December 2009). parking.xml files under scenery/Airports.