AI Traffic: Difference between revisions
(Place a little heads up to notify the unsuspecting reader that the traffic file format has changed.) |
|||
| Line 461: | Line 461: | ||
linux users can try to check out a version of taxidraw from CVS by following | linux users can try to check out a version of taxidraw from CVS by following | ||
the instructions on http://taxidraw.sourceforge.net/#download | the instructions on http://taxidraw.sourceforge.net/#download | ||
[[Ubuntu]] or [[Debian]] users may look at the [[Ubuntu_fg_tools]] page to have taxidraw installed in a easy way. | |||
Windows users can also do this either by using the free winCVS program or | Windows users can also do this either by using the free winCVS program or | ||
Revision as of 19:22, 6 January 2009
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,
- Download and install the required AI Aircraft
- Build ground networks for the Airports containing traffic.
NOTE: As of version 1.9.0, the internal format to the traffic files has changed, to allow for greater flexibility. An update of the documention is expected soon
Building Traffic Files
Traffic patterns are stored in data files in extended markup language (.xml) format. Depending on version, these files are either stored in a sudirectory called Traffic in FlightGear's main data directory, hereafter referred to with it's technical name:
${FGROOT}/Traffic
or in the AI Aircraft's directory. Current FlightGear CVS (as of late December 2007) has its traffic files in the aircraft directories (e.g., in data/AI/Aircraft/737/, and older versions as well as the current PLIB built version of FlightGear have this file in ${FGROOT}/Traffic. 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 is constructed on the basis of a routing table 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 the FlightGear traffic patterns is that while in the real world aircraft schedules are frequently rotated the FlightGear routes remain the same, unless the database is updated. Real aircraft require mainanance, and are therefore taken out of service periodically, FlightGear aircraft have the advantage that they do not require maintanance in this respect.
Realistic
With FGFS 1.0.0 Interactive Traffic also reacts on other Non-AI Aicrafts. The A320 ( and maybe some others) has working flaps and gears.
An example of a traffic file
NOTE: As of version 1.9.0, the internal format to the traffic files has changed, to allow for greater flexibility. An update of the documention is expected soon
<?xml version="1.0"?>
<trafficlist>
<aircraft>
<model>Aircraft/MD11/Models/KLMmd11-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<heavy>true</heavy>
<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0589</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>DGAA</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0590</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DGAA</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0681</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>CYVR</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0682</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYVR</port>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0871</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>VIDP</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0872</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>VIDP</port>
</departure>
<cruise-alt>350</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0587</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>DNMM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0588</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>DNMM</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0671</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>CYUL</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0672</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>CYUL</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0667</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KMSP</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0668</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KMSP</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
</aircraft>
</trafficlist>
Disecting the traffic file
Here I will discuss the general structure of a traffic file in more detail. As discussed in the introduction, 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.
General Layout
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-ai.xml</model>
<livery>KLM</livery>
<airline>KLM</airline>
<actype>MD11</actype>
<offset>19</offset>
<radius>39</radius>
<flighttype>gate</flighttype>
<performance-class>jet_transport</performance-class>
<registration>PH-KCA</registration>
<flight>
...
</flight>
...
</aircraft>
</trafficlist>
The first lines inside the <aircraft> clause define 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.
- <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)
- In addtion, it is expected that a mil value will be valid sometime soon.
- <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.
Defining a flight
The next series of lines within the <aircraft> section define the flights. Again, each flight is defined between the <flight> and </flight> statements. For example, let's have a look at the first two flights specified in our PH-KCA example.
<flight>
<callsign>KLM0605</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>EHAM</port>
</departure>
<cruise-alt>330</cruise-alt>
<arrival>
<port>KSFO</port>
</arrival>
<repeat>WEEK</repeat>
</flight>
<flight>
<callsign>KLM0606</callsign>
<fltrules>IFR</fltrules>
<departure>
<port>KSFO</port>
</departure>
<cruise-alt>340</cruise-alt>
<arrival>
<port>EHAM</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. 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).
- <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).
- <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 the next few sections, I will explain how to do this.
fgtraffic.xml
If you use a current version of FlightGear cvs HEAD/ OpenSceneGraph, activating traffic is easy: Just copy the traffic file into the same directory as where the AI aircraft file resides (for example: data/AI/Aircraft/737). If you use an older version, or if you use the PLIB based version of FlightGear, traffic can be activated according to the following instructions.
At startup, FlightGear (older versions, or CVS PLIB) reads a file called fgtraffic.xml. In order to let FlightGear use our newly built traffic file, all we need to do is add a reference to the new file. Suppose we saved our file as PH-KCA.xml, all that would be required would be to add the following line:
<traffic include="<path>/PH-KCA.xml",
where <path> is the directory where the file is located, relative to the main Traffic directory. For example, fgtraffic could look like this:
<?xml version="1.0"?> <trafficlist> <traffic include="KLM/KLM.xml"/> <traffic include="UAL/UAL.xml"/> <traffic include="general/KSFO/c172.xml"/> </trafficlist>
Organizing by airline
Although the example above works and is perfectly legal, I would prefer to see the individual files grouped together by airline and aircraft type. One way to do this is to organize files by airline and within each airline by aircraft type. For example, we could group all KLM flights together. Then we bundle these into a file called \verb|KLM.xml|, which would look like the following:
<?xml version="1.0"?> <trafficlist> <airline include="KLM/MD11/MD11.xml"/> </trafficlist>
This file currently contains only one line, which includes the MD11.xml group, but more could be added easily.
Organizing by aircraft type
Finally, the MD11.xml file could look like this.
<trafficlist> <traffic include="KLM/MD11/PH-KCA.xml"/> <traffic include="KLM/MD11/PH-KCB.xml"/> <traffic include="KLM/MD11/PH-KCC.xml"/> <traffic include="KLM/MD11/PH-KCD.xml"/> <traffic include="KLM/MD11/PH-KCE.xml"/> <traffic include="KLM/MD11/PH-KCF.xml"/> <traffic include="KLM/MD11/PH-KCG.xml"/> </trafficlist>
One final note on the organization of the schedules is that I'm consisdering changing the organization. In order to make the whole system more plug-and-play compatible, I'd like to add in the ability to drop traffic files right in a dedicated AI directory that FLightGear would automatically scan for new traffic files. Until those ideas are finally fleshed out, the current organisation is probably likely to stay in place.
Ground networks: A technical perspective
AI aircraft pickup taxiway information from an xml file that resides in FlightGear's data directory. This is done on an airport by airport basis. the precise location of this file is data/Airports/AI/[ICAO-id]/parking.xml. For an 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.
The first section of the file contains the parameters of the airport's parking locations. This section is followed by a list of all the nodes in the ground network, and the 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).
Name is currently not used, Parking names will be used in future ATC, but AINode names will probably not be used except for some specific internal functions. airlineCodes= list any (comma separated) ICAO airline codes here to specify which airlines are allowed here. -pushBack (used to determine whether departing aircraft can make left or right turns after pushback
In addition, each parking has a number of additional parameters:
- type: specifies what type of aircraft can use this parking bay: Valid values for this parameter are: cargo, gate (=usually intermediate to heavy airline traffic), ramp (=usually smaller regional jets and commuter aircraft), ga (=general aviation), and mil (=military). See the description of the <flighttype> parameter in the traffic pattern description above for a comparison.
- number: Currently unused, and likely to be removed.
- heading: the heading the aircraft 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.
- pushBack: Currently unused.
Finally, the taxiway segments contain three parameters.
- begin (= the id of the parking or AINode this segment starts)
- end (= the id of the parking or AINode this segment ends)
- name (= name of the taxiway. Currently still unused)
Creating a ground network, a practical approach
Okay that finishes 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.
TaxiDraw
The CVS version of TaxiDraw (http://taxidraw.sourceforge.net/) has ground network editing capabilities, and will in the short to intermediate term probably be the best option to create a ground network for FlightGear. Notice that the ground editing facilities in TaxiDRaw are still rather new, and although the stability of this feature has increased dramatically over the last few weeks, there are still a few issues related to the undo function, so be prepared for a bit of frustration, and make regular backups.
Obtaining TaxiDraw
I'm hoping that we can do a release of taxidraw fairly soon, so that the groundnet editing capabilities will become easily accesible. Until that time, linux users can try to check out a version of taxidraw from CVS by following the instructions on http://taxidraw.sourceforge.net/#download
Ubuntu or Debian users may look at the Ubuntu_fg_tools page to have taxidraw installed in a easy way.
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 [1]- 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 arial image. If you can't find that, using a schematic diagram might also work. In most cases, using http://maps.google.com, and selecting the satellite imagery will work pretty well as reference. You can't save the google images, so importing them as a background image in taxidraw won't work. However, using these images as a reference and placing the parking notes at the approximate location indicated by the map will (at least for an initial version) give reasonable results.
Creating the network
Startup locations
Once you have the reference material, it's time to start building the ground network. I typically start by placing all the parkings first. There are two ways to do this.
- Using the mouse, choose [insert|Startup Location] from the main menu. This will create a new startup location. Then left-click on it and drag it to its desired location.
- Move the mouse to the location where you want to place the startup location and press the 's' key on the keyboard. This places the startup location directly where the mouse is located.
AI Network Nodes
Next you want to insert the AINodes, without connecting them yet. The procedure is basically the same as placing the startup locations. Either select [Insert| Add AI Network Node ] from the menu, or move the mouse to the location where you want to place the node. Press the 'n' key to actually add the node.
Connecting the nodes: Drawing the network
Once you are finished adding all the nodes, and startup locations, it's time to connect the nodes . This is the time to save your work and MAKE A BACKUP, as the nodes connection code is not entirely stable yet.
Connecting nodes can be done by switching the editor to arcing mode, by pressing the 'm' key. The edit mode of taxidraw is indicated in the lower right corner of the status bar. After pressing 'm' it should read ARC. If you need to switch back to the standard edit mode press 'm' again.
Making sure we are still in "ARC" mode, select the first node or parking you want to connect to the network by clicking on it. The node you have clicked will be selected, and a red line with an arrow symbol will be drawn between this node and the mouse cursor. Now, select the second node that you wish to connect this node to. Click it with the mouse, and the red line will now be drawn between the the two nodes. You have created a taxiroute. Now repeat this process for all the nodes you want to connect.
Note that taxi segments are unidirectional. If you want to create bidirectional taxiways, make sure you not only connect node "1" to node "2" but also to connect node "2" to node "1".
Second, notice also that once you have connected two nodes to each other, and want to create a second taxiway that starts at the node that the previous node ended, you have to select this node again, to become the first node in the next taxiway.
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 data/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.
Appendix:
An below is an example section from data/Airports/AI/EHAM/parking.xml
<?xml version="1.0"?>
<groundnet>
<parkinglist>
<Parking index="0"
type="cargo"
name="R02"
number="1"
lat="N52 17.664"
lon="E04 44.527"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
<Parking index="1"
type="cargo"
name="R04"
number="1"
lat="N52 17.682"
lon="E04 44.572"
heading="328.8"
radius="43"
airlineCodes="NONE"
pushBack="left"/>
[SNIP]
<Parking index="198"
type="gate"
name="J80"
number="1"
lat="N52 18.678"
lon="E04 44.659"
heading="0"
radius="15"
airlineCodes="NONE"
pushBack="left"/>
</parkinglist>
<TaxiNodes>
<node index="199" lat="N52 20.778" lon="E04 42.626" name="AI waypointnode"/>
<node index="200" lat="N52 20.622" lon="E04 42.771" name="AI waypointnode"/>
<node index="201" lat="N52 20.478" lon="E04 42.592" name="AI waypointnode"/>
<node index="202" lat="N52 20.394" lon="E04 42.685" name="AI waypointnode"/>
<node index="203" lat="N52 20.406" lon="E04 42.754" name="AI waypointnode"/>
<node index="204" lat="N52 20.310" lon="E04 42.740" name="AI waypointnode"/>
<node index="205" lat="N52 20.148" lon="E04 42.565" name="AI waypointnode"/>
[SNIP]...
<node index="597" lat="N52 18.666" lon="E04 45.372" name="AI waypointnode"/>
<node index="598" lat="N52 18.678" lon="E04 45.358" name="AI waypointnode"/>
<node index="599" lat="N52 18.678" lon="E04 45.377" name="AI waypointnode"/>
</TaxiNodes>
<TaxiWaySegments>
<arc begin="237" end="234" name="Route"/>
<arc begin="234" end="239" name="Route"/>
<arc begin="239" end="242" name="Route"/>
<arc begin="242" end="245" name="Route"/>
<arc begin="369" end="374" name="Route"/>
<arc begin="374" end="369" name="Route"/>
<arc begin="370" end="373" name="Route"/>
<arc begin="373" end="370" name="Route"/>
</TaxiWaySegments>
</groundnet>
Perfomance
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. ;-)