AI Traffic: Difference between revisions

Jump to navigation Jump to search
1,777 bytes removed ,  14 July 2020
Simplified Traffic Files Section. Added link to tools
(Updated Base Groundnet Verification 7.4 & 7.5 Sections)
(Simplified Traffic Files Section. Added link to tools)
Line 173: Line 173:


=== Defining a flight ===
=== Defining a flight ===
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,
The Traffic Manager II file formats contains separate sections for both aircrafts and flights information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a Traffic Manager II file looks something like this:
<syntaxhighlight lang="xml">
<aircraft>
    ...
    <flight>
    </flight>
</aircraft>
</syntaxhighlight>
One major difference from this format is that the Traffic Manager II file formats now contain separate sections for aircraft and flight information, with the common denominator being a shared key that links aircraft and flight information together. In other words, the general layout of a Traffic Manager II file looks something like this:
<syntaxhighlight lang="xml">
<syntaxhighlight lang="xml">
  <aircraft>  
  <aircraft>  
Line 226: Line 218:


== Putting it all together: Including a traffic file ==
== Putting it all together: Including a traffic file ==
After creating a traffic file, all we need to do is make sure FlightGear knows how to use it. In earlier versions of FlightGear, this used to involve quite a bit of editing, because every file had to be referenced in a master traffic file, named fgtraffic.xml.
Traffic files are found under [[$FG_ROOT]]/AI/Traffic. The actual traffic files should be stored in a subdirectory one level below /AI/Traffic.
 
All traffic is organized by Operator ICAO code, and stored in a single letter directory. For example, KLM traffic can be found in [[$FG_ROOT]]/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in [[$FG_ROOT]]/AI/Traffic/U/UAL.xml.
Those days are gone, however, since FlightGear 1.0.0, when a directory scanning mechanism was put in place. Both FlightGear 1.0.0., and 1.9.0 and beyond use this directory scanning mechanism, however, in order to separate between the Traffic Manager I format used by FlightGear 1.0.0, and the Traffic Manager II format used by later versions, these files are located in two different locations. In FlightGear 1.0.0, traffic files should be located in a subdirectory of the [[$FG_ROOT]]/AI/Aircraft directory. For example, the traffic definition for a Boeing 737 would be located in a XML file in [[$FG_ROOT]]/AI/Aircraft/737, and traffic for a Boeing 747 would be located in a XML file in [[$FG_ROOT]]/AI/Aircraft/747.


Since traffic files for FlightGear 1.9.0 are, strictly speaking, no longer tied to one particular aircraft, or aircraft type, the traffic files were moved to a different directory, namely [[$FG_ROOT]]/AI/Traffic. Again, the actual traffic files should be stored in a subdirectory one level below /AI/Traffic. In the demo that is provided with FlightGear 1.9.0, all traffic is organized by airline, and stored in a single letter directory. For example, KLM traffic can be found in [[$FG_ROOT]]/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in [[$FG_ROOT]]/AI/Traffic/U/UAL.xml. Although currently no formal definition exists for military or general aviation traffic, a similar scheme could be adapted. For instance, military traffic could be placed in [[$FG_ROOT]]/AI/Traffic/mil/USAF.xml
The name of the file is the ICAO of the operator (aircraft owner) which is normally the same that the one found in the <airline> tag in the file itself but not alway. For example Compass Airlines in Minneapolis, has the ICAO code CPZ but operates flights for both American Airlines (AAL) and Delta Airlines (DAL). In this scenario the traffic file will be stored as [[$FG_ROOT]]/AI/Traffic/C/CPZ.xml and will contain a series of aircrafts with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.


== Tools ==
== Tools ==
One major motivation for introducing the Traffic Manager II file format is to make it easier for FlightGear users to contribute to the traffic database. To further motivate this, some tools are currently in development that aim to make user interaction even easier. Although most of these tools are not ready for public use yet, it is probably worth mentioning some of these developments. First of all, the custom scenery project is working on extending their scenemodel database to store traffic. A web based front end will allow users to enter their favorite flight, and thus collect an extensive amount of traffic data. Users will be able to download the collected results and place the downloaded files in their traffic directory or get it via Terrasync.
The author of the traffic manager code has written some scripts, mainly for private use, that will allow one to input the flight data into a simple text format and then convert the resulting text file to XML. The most important of these scripts can be found in the FlightGear source package under scripts/perl/traffic/. https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/scripts/perl/traffic/
 
Secondly, the author of the traffic manager code has written some scripts, mainly for private use, that will allow one to input the flight data into a simple text format and then convert the resulting text file to XML. The most important of these scripts can be found in the FlightGear source package under scripts/perl/traffic/.  


Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malaysian project):
Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malaysian project):
86

edits

Navigation menu