Difference between revisions of "AI Traffic"
Revision as of 09:48, 30 June 2010
Interactive Traffic, or AI-Traffic (Artificial Intelligence) has come to life with FlightGear version 0.9.5. Since then FlightGear has an interactive traffic system that is based on the AI-Models subsystem, and which is currently under active development. This page aims to provide the required documentation needed to set up some traffic.
In essence, setting-up the AI controlled traffic system involves three steps:
- Create Traffic files,
- Build ground networks for the Airports containing traffic.
- Create the appropriate Departure / Arrival procedures for each airport involved.
Notice that the "Download all AI aircraft" is no longer necessary, because most, if not all, AI aircraft are now part of the base package.
- 1 Building Traffic Files
- 2 Some Details: TrafficManager, Aircraft, and Flights
- 3 An example of a traffic file
- 4 Disecting the traffic file
- 5 General Layout
- 6 Defining the aircraft
- 7 Defining a flight
- 8 Putting it all together: Including a traffic file
- 9 Tools
- 10 Ground networks
- 10.1 A technical perspective
- 10.2 Creating a ground network, a practical approach
- 10.3 TaxiDraw
- 10.3.1 Obtaining TaxiDraw
- 10.3.2 Getting good reference material
- 10.3.3 Creating the network
- 10.4 Editing the startup location parameters
- 10.5 Copying the ground network into FlightGear's data directory
- 10.6 Testing the network
- 11 SIDs / STARs
- 12 Appendix: Special Notes
Building Traffic Files
Traffic patterns are stored in data files in extended markup language (.xml) format. The actual location of these files are version dependent. For FlightGear 0.9.x, traffic files are stored in a sudirectory called Traffic in FlightGear's main data directory, hereafter referred to with it's technical name:
In FlightGear 1.0, the traffic files can be found in a subdirectory of:
For example, traffic belonging to a united airlines 737 would be located in: $FG_ROOT/AI/Aircraft/737/737-UnitedAirlines-traffic.xml
FlightGear 1.9.0 has seen yet another move. In this version, the traffic files can be located in:
For FlightGear 1.9.0 and later, a new traffic file format was introduced (henceforth referred to as "traffic manager II" format (TM-II), in which aircraft and flights are no longer directly coupled, leading to more flexibility.
Each traffic pattern is built around two entities: Aircraft and Flights. Before discussing the details, lets start by exploring these two concepts a little further.
Some Details: TrafficManager, Aircraft, and Flights
As in real life, AI traffic in FlightGear is centered around aircraft. In real life, a commercial airliner is put to use by operating on a series of scheduled flights, on a daily or weekly basis. Take for example the long haul routes that are flown by McDonnell Douglas MD11 aircraft. For instance, the MD11's operated by KLM fly regularly between Amsterdam and various distant destinations, such as San Fransisco or Minneapolis in the United States, Vancouver or Montreal in Canada, Accra and Lagos in Africa, or New Delhi in India. Some of these routes are too long to complete a return flight in one day, such as the trip between Amsterdam and San Fransisco, which is basically an 11-hour flight one-way. So it would take 22 hours of just the flying time, and at least an additional two hour turn-around time at each airport. Therefore, in real-life, it is necessary to operate this aircraft on a series of routes, because other routes are considerably shorter than the trip to San Fransisco. Therefore, the time lost on one route can be gained on another, averaging out to approximately one round-trip a day.
In FlightGear, we wouldn't have to be so strictly considerate about the turnaround times as a real-world airline would, but in the not-so distant future, we also want to be able to see realisticly crowded terminals at our simulated airports, so considering the turnaround time in the schedules is a good thing. Therefore, most of the long-haul aircraft will need to be scheduled to fly more than one route. Hence, each AI aircraft has one or more routes assigned to it, which repeat on a weekly, daily, or hourly basis.
The FlightGear traffic manager system, periodically checks the approximate position of a each aircraft in its database. This database was originally constructed on the basis of a fixed routing table that was assigned to each aircraft. As in the real-world, when a route ends at one airport the next one has to start from the same airport as well. An important difference between the real world and these FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remained the same, unless a major update to the database were to take place. Real aircraft require maintenance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintenance in this respect.
There were still some significant drawbacks to this approach, nevertheless. Consider the MD11 a little further. In real life, KLM operates this aircraft on many routes that are serviced at relatively irregular intervals. For example, many flights to the Carribean are served only two or three times a week, making it extremely complicated to build completely accurate traffic files for these routes.
To circumvent these problems, a new database format was introduced in FlightGear 1.9.0. In this new format, flights are no longer directly and rigidly assigned to specific aircraft. Instead, a more generic description of a fleet is given, along with a series of flights that need to be carried out. The routing is then taken care of by FlightGear itself.
An example of a traffic file
Below is a complete and working example of a traffic manager II file, as it can be used with FlightGear 1.9.0 and later:
<?xml version="1.0"?> <trafficlist> <aircraft> <model>Aircraft/MD11/Models/KLMmd11.xml</model> <livery>KLM</livery> <airline>KLM</airline> <home-port>EHAM</home-port> <required-aircraft>MD11KLM</required-aircraft> <actype>MD11/P</actype> <offset>25</offset> <radius>39</radius> <flighttype>gate</flighttype> <performance-class>jet_transport</performance-class> <registration>PH-KCA</registration> <heavy>true</heavy> </aircraft> <aircraft> <model>Aircraft/MD11/Models/KLMmd11.xml</model> <livery>KLM</livery> <airline>KLM</airline> <home-port>EHAM</home-port> <required-aircraft>MD11KLM</required-aircraft> <actype>MD11/P</actype> <offset>25</offset> <radius>39</radius> <flighttype>gate</flighttype> <performance-class>jet_transport</performance-class> <registration>PH-KCB</registration> <heavy>true</heavy> </aircraft> <flight> <callsign>KLM0765</callsign> <required-aircraft>MD11KLM</required-aircraft> <fltrules>IFR</fltrules> <departure> <port>EHAM</port> </departure> <cruise-alt>330</cruise-alt> <arrival> <port>TNCM</port> </arrival> <repeat>WEEK</repeat> </flight> <flight> <callsign>KLM0769</callsign> <required-aircraft>MD11KLM</required-aircraft> <fltrules>IFR</fltrules> <departure> <port>TNCM</port> </departure> <cruise-alt>330</cruise-alt> <arrival> <port>EHAM</port> </arrival> <repeat>WEEK</repeat> </flight> </trafficlist>
Disecting the traffic file
Here I will discuss the general structure of a traffic file in more detail. As discussed, the traffic patterns are centered around aircraft and flights. Therefore, a minimal traffic file will consist of two sections: the aircraft definition and the flights section. In the next two sections, I will discuss each of these sections.
The general layout of each file should look like the above example.
<?xml version="1.0"?> <trafficlist> </trafficlist>
The general layout of each file should look like the above example. The first line contains a generic xml header, which is followed on the second line with a <trafficlist> statement. Also, the last line in the file should close off the trafficlist section using the </trafficlist> statement. As will be illustrated below, between these two statements can be one or more aircraft definitions.
Defining the aircraft
<?xml version="1.0"?> <trafficlist> <aircraft> <model>Aircraft/MD11/Models/KLMmd11.xml</model> <livery>KLM</livery> <airline>KLM</airline> <home-port>EHAM</home-port> <required-aircraft>MD11KLM</required-aircraft> <actype>MD11/P</actype> <offset>25</offset> <radius>39</radius> <flighttype>gate</flighttype> <performance-class>jet_transport</performance-class> <registration>PH-KCA</registration> <heavy>true</heavy> </aircraft> <aircraft> ... </aircraft> </trafficlist>
The first lines inside the <aircraft> definition specify some of the aircraft's performance characteristics.
- <model> Here is a path specified to the 3D model that should be used in FlightGear.
- <livery> This line is currently unused, and will likely remain unused. The original idea was to combine this with the <model> line (see above) to load a specific combination of aircraftype and paint scheme, but I abandoned that idea, because it didn't turn out to be very combatible with the existing FlightGear model loading code.
- <airline> This line refers to the airline operating the aircraft. This information is currently used by FlightGear to handle gate/parking assignments. Use the official 3-letter ICAO airline code here, in case of commercial traffic. This keyword is unlikely to be used for general aviation and military traffic.
- <home-port> Each FlightGear aircraft is assigned to a home airport. Internally, this is used to ensure that routes are setup that will eventually lead back to the home airport. This is done to maintain some sensibility into the routing algorithm. [New for traffic manager II]
- <required-aircraft> This value is a key that binds aircraft and flights together. In case of this example, the key MD11KLM. Indicates that this aircraft will only carry out flights containing the same key. Usually, a combination of aircraft type, and airline will suffice for this key. In some cases, in particular, when specific aircraft / airlines are distributed across multiple hubs (i.e. home ports), it may be necessary to specify a key containing the home airport as well. For example, Delta Airlines operates 767's out of Atlanta, as well as out of New York. To separate between these two cases, it would be advisable to use two keys; one for KATL (e.g. 767DALKATL), and one for KJFK (e.g., 767DALKJFK). [NEW for traffic manager II]
- <actype> A description of the aircraft type reserved for future use in ATC.
- <offset> Ground offset of the 3D model. Not all aircraft 3D models are build using the same convention. Use this parameter to align the wheels with the ground. Notice that this parameter will probably become obsolete in the near future, because model view point references can also be done in the xml file that the <model> keyword refers to.
- <radius> An estimate of the aircraft's size. This is mainly used at airports for gate assignments.
- <flighttype> In the near future, this keyword will be used for runway assignments, so that general aviation, commercial, and military traffic will use different runways if that is part of the airport's operational procedures. This line is also used for gate assignments and should be one of the following:
- ga (general aviation),
- cargo (cargo)
- gate (commercial passenger traffic)
- mil-fighter (military fighter)
- mil-cargo (military transport)
- <performance-class> This line is used to determine the performance characteristics of AI aircraft. This should match one of the performance classes that are predefined in FlightGear. Currently, the following performance classes are supported:
- light_aircraft (prop driven single or twin),
- ww2_fighter (world war two fighter),
- jet_transport (modern commercial jet),
- jet_fighter (modern fighter aircraft)
- tanker (tanker aircraft), or.
- ufo (allows extreme accel/decel capabilities).
- <registration> The aircraft's tail number. Future versions of FlightGear will use this registration in ATC for general aviation traffic. For commercial traffic the registration number will likely remain unused.
- <heavy> Can be true or false. Reserved for future use by ATC, to determine whether the postfix "Heavy" should be appended to the aircraft's callsign.
Defining a flight
The original traffic file format contained a series of flights enclosed within the <aircraft> section, e.g.,
<aircraft> ... <flight> </flight> </aircraft>
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:
<aircraft> ... <required-aircraft>MD11KLM</required-aircraft> ... </aircraft> <flight> ... <required-aircraft> MD11KLM </required-aircraft> ... </flight>
Each flight is defined between the <flight> and </flight> statements. For example, let's have a look at a randomly selected flight from our KLM.xml example.
<flight> <callsign>KLM0769</callsign> <required-aircraft>MD11KLM</required-aircraft> <fltrules>IFR</fltrules> <departure> <port>EHAM</port> </departure> <cruise-alt>330</cruise-alt> <arrival> <port>TNCB</port> </arrival> <repeat>WEEK</repeat> </flight>
The <flights> section is slightly more complex than the aircraft definition itself, because it has a few nested levels, however, these should mostly be self-explanatory. The following keywords should be specified:
- <flight> All the relevant parameter should be specified between the <flight></flight> keywords.
- <callsign> The airline callsign used for ATC. If this is an airline flight it should be combination of the airline callsign (e.g. KLM for KLM, or Springbok for South African Airways), and the flight number (e.g. KLM0605, or Springbok0033).
- <required-aircraft> The key that links this flight to a particular aircraft. The see explanation in the aircraft section.
- <fltrules> Can be IFR or VFR. This is required for use in ATC, but currently not used. This is likely to change, however.
- <departure> Definition of the departure airport. This section should contain the <port> and keywords.
- <cruise-alt> Cruising altitude for this flight. This is a bit of a simplification from the real world, where aircraft usually don't stay at the same cruise altitude throughout the flight. This behavior will probably also change in future versions.
- <arrival> Same as <departure>, but now defining the port of arrival.
- <repeat> Repeat period. This can be either the keyword WEEK, or a number followed by Hr. WEEK means that the whole schedule repeats itself on a weekly basis. Hr means that the whole schedule repeats after the number of hours specified directly before it (e.g. 24Hr means that the schedule repeats after 24 hours). With traffic manager II, it is generally recommended not to mix schedules that rotate on different frequencies. In general, the best results are obtained when using only weekly rotating flights. For flights that are in reality operated on a daily basis, it is recommended to just specify multiple entries, i.e. one separate flight for every weekday.
- <port> This should be the international ICAO airport code. This keyword should be specified only within the <departure> or <arrival> sections. As far as I know, here it should still be in upper case, although the FlightGear command line currently also supports lower case ICAO codes.
- Used to specify the <departure> or <arrival> time. The format of this string is hour:minute:second. Notice that departure day is optional and is specifically intended to be used in combination with a weekly repeating schedule. When used in combination with other schedules, results may be unpredicatble. Times should be in UTC. Weekdays start at sunday (0) and end at saturday (6).
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 this. 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.
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 mechanims, however, in order to separate between the traffic manager 1 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 data/AI/Aircraft directory. For example, traffic for a Boeing 737 could be located in in an xml file in data/AI/Aircraft/737, and traffic for a 747 should be located in data/AI/Aircraft/747.
Since traffic files for FlightGear 1.9.0 are stricktly speaking no longer tied to one particular aircraft, or aircraft type, the traffic files were moved to a different directory, namely data/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 data/AI/Traffic/K/KLM.xml, and United Airlines traffic is stored in data/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 data/AI/Traffic/mil/USAF.xml
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 custrom scenery project is working on extending their scene model 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.
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 is now available for download trafficdata.zip. This zip archive contains a collection of traffic configuration files, along with a perl script to convert these scripts to xml.
Creating AI traffic files this way is easy. First, you need to define the aircraft for each fleet (data taken from the June 2010 Malayasian project):
###HOMEP RegNo TypeCode Type AirLine Livery Offset Radius FltType Perf.Class Heavy Model ############################################################################################################################################ AC WMKK TF-ARN 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml AC WMKK TF-ARJ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml AC WMKK TF-ATZ 747 747-2F6B MAS MAS 19 39 gate jet_transport true Aircraft/747-400/747-400-Malaysian.xml
Then, you need to define all the flights according to the following layout:
########Flt.No Flt.Rules Days Departure Arrival FltLev. A/C type ################### ######### ####### ############### ############### ################# # London Heathrow (EGLL; UTC+1 ) to Kuala Lumpur (WMKK +8:00) vv. FLIGHT Malaysian0001 IFR 0123456 21:00 EGLL 09:25 WMKK 360 747MAS FLIGHT Malaysian0002 IFR 0123456 15:40 WMKK 04:50 EGLL 360 747MAS FLIGHT Malaysian0003 IFR 0123456 11:00 EGLL 23:25 WMKK 360 747MAS FLIGHT Malaysian0004 IFR 0123456 09:05 WMKK 08:15 EGLL 360 747MAS # Frankfurt (EDDF; UTC+2 ) to Kuala Lumpur (WMKK +8:00) vv. FLIGHT Malaysian0005 IFR 0.2.456 10:30 EDDF 22:25 WMKK 360 777MAS FLIGHT Malaysian0006 IFR .1.3456 15:50 WMKK 04:25 EDDF 360 777MAS
Note that the flight information laid out above resembles that of a standard airline schedule table as close as possible, with a few known exceptions: - Weekdays are in the range 0 to 6, but do follow standard airline conventions (0 = monday; 6 is sunday) - All times in the table are in UTC; to convert from local time, as given in the airline table, subtract the airport in question's UTC offset). - The last entry in each line (A/C type) should correspond to the combination of the TypeCode and Airline entries in the aircraft sections.
The resulting table can now easily be converted to xml output by running the conf2xml.pl (conv2xml.pl - check) script.
For unix based operating systems, simply run conf2xml.pl from the directory where you unpacked the trafficdata.zip archive:
will give the output:
Writing to ADR.xml Writing to AFL.xml ... Writing to VLG.xml Writing to VLM.xml
When the script encounters an error, it will stop prematurely.
The next major aspect of the AI traffic system contains taxiway information. Although the physical layout of each airport is contained in FlightGear's airport database, this information is not sufficient to provide taxiway information. Therefore AI aircraft pickup this type of routing information from an xml file inside the data/AI/Airports directory/. Currently, this information is provided on a one file per airport basis, that can be found in a file called data/AI/Airports/[ICAO]/parking.xml, where ICAO stands for the 4 letter ICAO code for the airport in question.
For example, see the ground network for EHAM, which is found in data/Airports/AI/EHAM/parking.xml. See the end of this page for a small excerpt from this file. It should be noted that current development work is planned that aims to move these files from the base package to the scenery repository, so that ground network information and the physical layout of the airport can be updated in parallel. Once this is done, the new location / name for the file will be [fg-scenery]/Airports/[ICAO1]/[ICAO2]/[ICA03]/[ICAO].groundnet.xml. Here [ICAO] stands for the 4 letter ICAO code of the airport in question, and [ICAO1], [ICAO2], and [ICAO3] for the first to third letter of this code.
NOTE: Taxidraw versions with a build date of Feb. 5, or later, 2009 support the new naming convention. To make use of this new functionality, make sure to set the FlightGear scenery directory in TaxiDraw (tab 4 in the preferences menu). The directory specified here should be the top level directory, i.e. the one that contains the "Airports", "Objects", and "Terrain" subdirectory. Note that support for this naming convention was introduced somewhat earlier, but versions of TaxiDraw before Feb 5 contain a potentially fatal bug that might ruin your work.
In addition, FlightGear cvs of approximately the same date also has support for reading the ground networks from the scenery directory. This feature is not enabled by default. To enable, make sure the property /sim/traffic-manager/use-custom-scenery-data is set to true. This can be done by editing preferences.xml or specifying this property on the command line.
A technical perspective
A ground network file consists of 4 major sections. The first section is optional, although recent versions of TaxiDraw add this section automatically. This section contains a list of all the radio frequencies for the airport in question. FlightGear currently (as of 1.9.0) uses these frequencies to display some ATC messages. As of FlightGear 1.9.0, only startup approval requests are implemented. You can "hear" these by tuning to the first ground frequency listed in the frequencies section.
The second section of the file contains the parameters of the airport's parking locations. The third section contains a list of all the nodes in the ground network, and the fourth and final section contains a list of segments, or "arcs" as David Luff called them initially, which basically describe which node is connected to which other node.
Each parking and AI node has a unique index number, which is used by the segments to link the startup location and the taxiways together. Parkings and AI nodes have the following parameters:
- index (unique, consecutively numbered id)
- lat (position in latitude)
- lon (position in longitude)
- name (name as found on airport charts: e.g. D23, or C1).
In addition, each parking has a number of additional parameters:
- type: specifies what type of aircraft can use this parking bay. See the description of the <flighttype> parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:
- ga (general aviation),
- cargo (cargo)
- gate (commercial passenger traffic)
- mil-fighter (military fighter)
- mil-cargo (military transport)
- number: Currently used in combination with the <name> parameter to determine the full name of the gate.
- heading: The heading at which the aircraft are parked in this bay.
- radius: A value used to determine whether the aircaft will fit in this bay: see also the description of the <radius> parameter in the traffic pattern description above. FlightGear uses a standard list of aircraft radii for gate assignment.
- airlineCodes: a comma-separated list of ICAO airline codes used to indicate which airlines should park here. Leave this field blank if you want any aircraft to park here.
- pushBackRoute: A number that refers to another node in the network. In a correctly configured network, the AI aircraft will taxi to this node in reverse, thus simulating being pushed back. See the documentation for the PushBack hold point type below.
Taxiway nodes contain two additional parameters:
- isOnRunway' A logical value that is 1 when the node is on the runway, or 0 otherwise
- holdPointType Describes wether the current point should be considered a holding point. This parameter can have the following values:
- none No holding point
- normal A regular holding point. This point should be placed just before the runway entrance / exit points, so that traffic will not enter the runway before receiving clearance to enter the runway. Note that support for this type of holding point is not implemented yet, but should appear sometime during 2009.
- CAT II/III A special holding point for IFR conditions. Currently not supported yet.
- PushBack A push back hold point type. Each parking can be connected to maximally one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can maximally only be one connected to each gate.
Finally, the taxiway segments contain three parameters.
- begin The id of the parking or AINode where this segment starts
- end The id of the parking or AINode where this segment ends
- IsPushBackRoute a logical value. Should be one if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise.
- name Name of the taxiway.
Creating a ground network, a practical approach
Having finished the technical description of the parking file format, the good news is that one probably doesn't need to know too much about the technical side of the file structure to create a ground network. Advanced editing capabilities are currently available in TaxiDraw, a separately available utility for airport layout, and ground network editing. The current document describes the functionality of the NEW_GUI_CODE version of TaxiDraw.
Although currently no officially released version of TaxiDraw (http://TaxiDraw.sourceforge.net/) exists with the ground editing capability, the current CVS version is capable of doing so. Network editing capabilities in TaxiDraw are currently about as stable as the other editing features, however, the ground network module is still somewhat separate from the rest of the airport project code, and ground networks will 'not' automatically be saved together with the airport project. Therefore, do regular exports while editing, to prevent loss of work.
Until an official release has been done, linux users can try to check out a version of TaxiDraw from CVS by following the instructions on http://TaxiDraw.sourceforge.net/#download
Windows users can also do this either by using the free winCVS program or using the free cygwin environment. Another possibility is to look on - here you can find the last build of Taxidraw.
Getting good reference material
The first step in preparation of creating a ground network consists of getting some reference material. Ideally, You'd like to find a good satellite or aerial image. If you can't find that, using a schematic diagram might also work. For airports in the United States, you can simply load USGS imagery by clicking the "USGS" button, however, for the rest of the world, this service is not available. Perhaps the best way to get a decent reference image is to use the standalone GoogleEarth program. GoogleEarth lets you zoom in to any location of the world. Center your view on the airport, and zoom to encompass the entire area. Then, save a jpg snapshot of the screen. This image can be imported in TaxiDraw. After importing, right click, goto the "lock layers" submenu and unselect the background image. Next, select the background image, right click and select the "calibrate background image". Typically, the "Uniform scale / rotation option" works best.
Although a google earth snapshot will usually give a good reference for the actual location of airport parkings, it still doesn't give much information about some of the logical aspects of the parking infrastructure. In particular, information about gate names / airline operations is not provided. Typically, this information is hard to find, but can be compiled from various sources, including wikipedia, random airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!
Creating the network
The current documentation describes the procedure for the TaxiDraw NEW_GUI_CODE branch, which is rather drastically different from the procedure used by the original TaxiDraw, previously documented here. This section describes some of the general procedures involved in building a ground network.
Note: export your work regularly: Although ground network editing capabilities have improved dramatically, this part of TaxiDraw is still somewhat separate from the rest of the code, and ground networks are not automatically saved together with the project. When exporting, TaxiDraw asks wether the ground network should be saved directly into FlightGear's data directory. Usually, this is okay, so just clicking "yes" takes care of saving the file in the correct location. Likewise, while importing an existing network, TaxiDraw first looks in FlightGear's data directory, to check for an existing default file to be inported.
Set up a rough outline
To make best use of the background image, right click, choose the "view" menu, and unselect "taxiways", this way, all network drawing can be based on the real airport location. First, select the "Insert startup location" edit mode. This way, each left mouse click will place a startup location at the position of the mouse cursor. Once the major startup locations have been placed, switch back to "selection" mode, by clicking the little arrow button.
Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking's radius can be changed by clicking anywhere on the big red circle allows one to change the parking's radius by dragging the mouse. Although this usually works for setting up a rough draft, these parameters can directly be changed in the properties dialog. If the properties dialog is not visible, press [cntrl-p] to bring it up. It is possible to select multiple startup locations by pressing the shift key while selecting, and the parameters for each selected startup location can be changed at the same time. This is a powerful feature for editing the parameters of a whole series of parking locations, and also for equating and orienting gate radius and heading.
With the startup locations in place, select one of them. The next step will be to connect this parking area to each runway end. After selecting the parking, click on the "insert bidirectionally connected network nodes" (the two green dots icon), and start drawing. Place nodes at strategic locations, such as intersections, corners, and arcs. finally, place one node at the centerline of one of the runways. Once this is finished, one gate is connected to one end of one runway. The next job is to extend the network by connecting more gates and more runways.
Create a second branch from the existing route, which goes to another runway. To do so, press [cntrl-a] to deselect all objects. Then, select the point where you want to branch off from. Select this point using a left mouse click, while holding down the shift key. Since TaxiDraw is still in node connect mode, simply left-clicking would have resulted in placing a new node. With this node selected, continue drawing. Repeat this procedure until all runways are connected.
Then, start adding the additional gates to the network. Press [cntrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse, and start drawing unil the the gate in question is one segment away from being connected. Then, [shift left-click] the network node that this route segment should be connected to, and make sure that the correct node is selected. Then, right click, and select "connect nodes bidirectionally" from the AI nodes menu.
Repeat this procedure until all parking locations are connected to each runway.
Refining the network: Mark points on the runway as such
With the basic infrastructure in place, the next step is to fine-tune the network. The first step in this process is to mark the network nodes that are located on a runway. This is important for a number of reasons: Taxidraw needs these OnRunway points for it's network verification tool. Secondly, the use of the type of runway marking will be used in future versions of FlightGear for runway entrance / exit calculations, in addition to a host of other possible uses in routing (such as blocking a certain node then a crossing runway is in use, etc, etc).
It should be noted that there is no reason why TaxiDraw should not be able to mark the runway points as such automatically. After all, the geometry information of both runways and AI nodes is available. Although this automatic feature is planned, the TaxiDraw developers have as of yet not found the opportunity to implement this feature. Until that time, on runway marking has to be done by hand.
Refining the network: Set Holding points
Holding points are nodes in the network that do something special. They can be used by FlightGear to make traffic wait at certain specific locations. As a matter of fact, the 'normal' and 'Cat II/III' hold points are not yet used by FlightGear, but are part of the development plan. Currently, hold points are implicitly assigned by the FlightGear AI code. For instance, traffic waiting for takeoff clearance is holding at the first point before the runway. Likewise, traffic can receive a hold position instruction just before an intersection in the taxiway system, when traffic is approaching at the other leg. While these implicit hold points work reasonably, there are some limitations. Consider for example runway 07 at CYYC (Calgary Intl, Canada). In the FlightGear rendition of this airport, there are no taxiways leading to this runway, so departing aircraft should back track the runway from an entrance point at the middle of the runway. Currently that point will also become the runway entrance holding point. This is clearly undesirable, because it means that traffic is actually waiting on the runway in order to get clearance to enter it. For this reason, airport ground network designers should have a means to have explicit control over holding points. The normal hold point is meant for just that.
The Cat II/III hold point type is meant as an extension to this scheme for special IFR conditions. Support for these types in FlightGear is planned for a later stage of development though.
Refining the network: Pushback routes
With the above-mentioned refinements, the ground network should be fully working, with one notable exception. Aircraft will be driving forward when leaving the gate, making a sharp turn (while probably destroying themselves and the terminal building in the process). To prevent this, a push back route should be created. A push back route consists of at least one or more taxiway segments that have the "PushBack Route" property set to true. The last of these segments should be terminated by a PushBack HoldPoint network node.
Notice that a push back route is optional, but that parkings may never have more than one push back route. The formal criterium for a valid push back route is that each gate should have a maximum of one pushback node associated with it, which can be reached using one route only. From an editing point of view, it is sufficient to just mark a number of taxiway segments as push back, and mark the ending node as such as well.
It is important to note that the "Verify Ground network" process should be run in order to get a correctly working push back system, because this function runs some internal consistency checks. Push back routes can be very simple, from just one route segment, to fairly complex, as illustrated below. Shown here are 3 examples from the EHAM ground network. 1) Shows a fairly complex example, where all aircraft from one side of the E terminal are being linked to one shared push back point. In the example, the push back route of an aircraft departing from gate E20 is illustrated. 2) Shows a simple example, where one aircraft is being pushed back, and makes a left turn. In essence, 3) shows a similar example, but now in a slightly more crowded space, where pushback nodes are overlapping. The current push back system allows for fairly complicated behavior. To get a full understanding of it's workings, it is advisable to play with some of the existing ground networks. EHAM and KFSO currently provide the most complex setups.
Finally, please notice that you need a version of TaxiDraw with a build date of February 5, 2009, or later, for this to work correctly. Earlier version did not export the pushBackRoute attribute correctly. Support for this functionality was introduced late January 2009, but versions earlier than February 4 contain a potentially fatal bug, that may seriously damage your work.
Verifying the network
Finally, with a network complete, it is important to verify it! The verification function not only detects obvious problems with the network, it also updates some internal states that FlightGear relies. on. Presumably, an automatic verification process will be added to the export function, but until that is the case, make sure to do this manually. The verify network function can be found in the "Tools" menu.
Notice that TaxiDraw does not automatically fix problems. It is left to the user to fix the problems manually. TaxiDraw does select the offending node(s) / segments(s) for easier identification. Also note that TaxiDraw stops verifying at the first problem encountered, so it is worthwhile to continue checking until no further errors are found. Currently, the following checks are performed.
- On runway points Added on January 24, 2009, this check is most likely not yet available in any distributed version. This is currently just a very lame check to see if any point in the network has been marked as such. This check is not exhaustive, but simply meant as a reminder to the editor that the OnRunway points should still be marked. Ultimately, this check should be replaced by the aformentioned automatic geometry function.
- Duplicate Taxiway Segments It's easy to connect two network nodes twice. While this doesn't really hurt, it does add dead weight, so checking for duplicates is not a bad thing.
- Routing One of the most persisting problems, headache causing problems is that of a disconnected parking in the network. FlightGear will happily place an aircraft there, but bail out when that aircraft cannot reach the runway. The routing check attempts to prevent this. Notice that it is of utmost importance that the OnRunway points are set correctly, because TaxiDraw relies on these points for it's route finding algorithm. Because the route finding algorithm is rather computationally intensive, some progress information is currently written to the console (a proper progress bar would be nice). When a disconnected parking is found, TaxiDraw selects both the parking and the runway node. It is still left to the user to trace a route between these two points and find where the two pieces are disconnected.
- Check and set pushback nodes this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.
Editing the startup location parameters
Once you have created a ground network, you'll find that it probably won't work yet in FlightGear. The main reason for this is that the default gate size is set to a fairly small size, and most aircraft won't fit into the gate. Therefore, you'd need to edit the parking parameters. In addition, you'd also need to give each parking a name, and a heading, and probably airlines codes. Changing name, and heading can be done in TaxiDraw, by right clicking on the startup location. This will bring up a dialog, in which you can change latitude, longitude, heading, and name. Once you're done editing, click okay to accept the new values, or cancel to discard.
Editing the starup location radius, type, airlineCodes, and pushBack parameters is not yet possible in TaxiDraw. So changing these requires saving the project and editing these using a texteditor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The groundnetwork will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.
You can edit the remaining parameters by loading this groundnet.xml file into a text editor. Once you are done editing make sure you import these changes into TaxiDraw immediately. Do this by going to [File| Import FlightGear AI Network]. This will open a file selection dialog. Choose the file you just edited and click okay. TaxiDraw will ask for confirmation to overwrite existing ground network data and confirm this by clicking on "yes".
Copying the ground network into FlightGear's data directory
Finally, once you have finished creating a groundnet work you can test it in FlightGear. Create a directory in FlightGear's data/Airports/AI directory, with the name of the ICAO code of your airport. For example $FG_ROOT/Airports/AI/EHAM. Next. locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to "parking.xml".
Testing the network
Startup flightGear at the airport for which you have just created the network, and make sure you have traffic for that aircraft. FlightGear will check the network and report errors on the console. Aircraft than can't be placed at one of the parking locations will be placed at a default location.
If the FlightGear AI system can't find a valid route between startup location and runway, it will list which nodes are not connected and exit.
SIDs / STARs
SID is an acronym for Standard Instrument Departure. Likewise, STAR is an acronym for Standard Terminal Arrival Route. Directly after takeoff, in particular at busy airports, aircraft follow a standard flightpath, that will keep them safely separated from arriving traffic, avoid ground obstructions, and also keeps traffic away from populated areas as much as possible. Currently, steps are in progress to allow FlightGear traffic to follow SIDs. Ultimately, the plan is to provide SID and star data in a format that can also be used by the user controlled Aircraft's Flight Management Computer. Currently, some sample data exist in the form of a PropertyList formatted xml file that contains a list of waypoints.
This section of the AI Traffic documentation is meant as a stub that keeps track of the current development. At the moment of writing, some proof-of-principle data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of these data. Note that these data are meant to be just that; a proof of principle. User contributions will be accepted as soon as the format has stabilized.
Appendix: Special Notes
With FGFS 1.0.0, the AI Interactive Traffic needs a lot of CPU-power. With the current CVS-versions, however, we now have much better performance so realistic density of traffic is currently possible, even for slower computers. For those who are still afraid, there is an, as of yet, unpublished feature: Set a new property "/sim/traffic-manager/proportion" to any value between 0 and 1 in your preferences.xml. During program start up, the traffic manager draws a random number (between 0 and 1) for each aircraft, and if that random number is smaller than the value specified in /sim/traffic-manager/proportion, the aircraft is added, otherwise it is discarded. In essence, only the specified proportion of aircraft will be loaded.
Unfortunately you can't change this at runtime yet, so you need a little bit trial and error! However, it should allow the combination of slower computers and dense traffic files.