About the Scenery/Airports folder

From FlightGear wiki
Revision as of 09:32, 30 June 2010 by Flughund (talk | contribs) (Created page with ''''Introduction to the Scenery/Airports folder and explanation by Martin, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html original message] on d…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Introduction to the Scenery/Airports folder and explanation by Martin, original message on devel-list.

Traditionally, the "three main sources of FlightGear users' joy" (TM) are tightly coupled together: The Base Package depends on the Sim-/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.

[...] we came to the conclusion that it's time to untie the Scenery from this dependency chain.

We plan 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, we're 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.

Those entities we identified as overlapping between the visual representation of airfields in the Scenery and the respective data files in the Base Package are:
1.) Threshold positions and orientation (typical startup positions),
2.) ILS positions and orientation (apparently depends on runways),
3.) Taxiway ground network (we don't want AI airliners to taxi off the tarmac),
4.) Aircraft parking positions (to avoid airliners parking on the grass or inside the terminal building).

We're storing this information in a couple of XML files in a newly created 'Airports/' directory alongside the well known 'Terrain/' and 'Objects/' directories. The new directory is being organized using sort of a poor-man's alphabetical index, using three stages of subdirectories. 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.

Even though there's no immediate use of this feature, we'll add it to the upcoming Scenery release in order to allow the software adapting to it and to have everything in place until the next software release. You'll find an example of the mentioned structure in CVS.


For the transition periode a new property is introduced. Durks original message on devel-list.

[...]

[Since FlightGear 2.0.0], you can choose which set of data to use, by changing the property /sim/use-custom-scenery-data.

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

Currently, 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 Scenery/Airports/[I]/[C]/[A], so that we have more flexibility in regenerating the terrain tiles without having to force the updated runway positions back into apt.dat.
  • Use of ground networks
  • the runway use files.

Currently the /sim/use-custom-scenery-data property defaults to false.