Difference between revisions of "About Scenery/Airports"

From FlightGear wiki
Jump to: navigation, search
(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…')
 
m (Cleanup, "wikify")
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
'''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 devel-list.'''
+
This article gives an '''introduction to the <tt>[[$FG_SCENERY]]/Airports</tt> folder'''.
  
Traditionally, the "three main sources of FlightGear users' joy" (TM) are tightly coupled together:
+
Traditionally, the "three main sources of [[FlightGear]] users' joy" 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.
+
* 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.
  
[...] we came to the conclusion that it's time to untie the Scenery from this dependency chain.
+
From FlightGear 2.0.0 onwards, efforts have been made to untie the scenery from this dependency chain, leading to the <tt>[[$FG_SCENERY]]/Airports/</tt> directory.
  
We plan to achieve this goal by a solution as minimalistic as possible, still keeping compilance with traditional rules in the FlightGear development process.
+
== History ==
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.
+
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.
  
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:<BR>
+
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),<BR>
+
# Threshold positions and orientation (typical startup positions).
2.) ILS positions and orientation (apparently depends on runways),<BR>
+
# ILS positions and orientation (apparently depends on runways).
3.) Taxiway ground network (we don't want AI airliners to taxi off the tarmac),<BR>
+
# 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).<BR>
+
# 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 <tt>[[$FG_SCENERY]]/Airports/</tt> directory alongside the well known <tt>Terrain/</tt> and <tt>Objects/</tt> directories. The directory is organized using sort of a poor-man's alphabetical index, using three stages of subdirectories: <tt>Airports/[I]/[C]/[A]/</tt> (with the three first characters of the ICAO code).
  
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.
 
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.
+
=== 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 <tt>/sim/use-custom-scenery-data</tt>.
 
+
'''For the transition periode a new property is introduced. Durks  [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25478.html 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 <code>AI/Airports/[ICAO]</code>, <BR>and when set to ''true'', it is read from <code>Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml</code>.
+
Whenever this boolean property is set to ''false'', ground network data will be read from <tt>[[$FG_ROOT]]/AI/Airports/[ICAO]</tt> and when set to ''true'', it is read from <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml</tt>.
  
Currently, this property controls the following:
+
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.
+
* Reading of startup information: When set to "true", the runway dimension data in apt.dat are overwritten by those in the <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]</tt>, 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
+
* Use of ground networks.
* the runway use files.
+
* Runway-use files.
  
Currently the /sim/use-custom-scenery-data property defaults to false.
+
{{Appendix|all|
 +
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17407.html |title=Shipping the most relevant airport data with the Scenery |author=Martin Spott |date=16 August 2008 }}
 +
* {{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25478.html |title=parking.xml files under scenery/Airports |author=Durk Talsma |date=22 December 2009 }}
 +
}}
  
[[Category:Scenery enhancement|About_Scenery/Airports]]
+
[[Category:Scenery enhancement]]

Latest revision as of 15:29, 20 May 2012

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