AI Traffic: Difference between revisions

segments to link the startup location and the taxiways together. Parking spaces and  

In addition, each parking space has a number of additional parameters:

* '''type:''' specifies what type of aircraft can use this parking space. See the description of the '''<flighttype>''' parameter in the traffic pattern description above for a comparison. Valid values for this parameter are:  

* '''heading:''' The heading at which the aircraft are parked in this space.

* '''radius:''' A value used to determine whether the aircraft will fit in this space: 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.

* '''holdPointType''' Describes whether the current point should be considered a holding point. This parameter can have the following values:

** '''PushBack''' A push back hold point type. Each parking space can be connected to one and only one push back point, connected through a series of push back routes. Note that a push back point is optional, but that there can be only one connected to each gate or parking space.  

* '''begin''' The id of the parking space or AINode where this segment starts

* '''end''' The id of the parking space or AINode where this segment ends

* '''IsPushBackRoute''' a logical value. Should be 1 if the current segment is part of a route connecting a gate to a push back hold point, or 0 otherwise.

Although currently no officially released version of [[TaxiDraw]] 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. The ground network module, however, 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, they do regular exports while editing, to prevent loss of work.  

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 of the airport 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 GoogleEarth 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 and 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!

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 whether 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 imported.

[Scenery v2]: For 850 Airports, a python script is available, to automatically create a basic ground net out of WED's earth.wed file. It converts Yellow Markings and Park Positions into a ground net which can be read, and refined by Taxidraw. Note that both Centerline and borders are converted (remove border nodes once in Taxidraw) See [http://forum.flightgear.org/viewtopic.php?f=23&t=17990 HERE]  

Next, start editing all the relevant startup location parameters. Parking heading can be changed by dragging the little red circular heading indicator. The parking space's radius can be changed by clicking anywhere on the big red circle. Then you can change the parking space'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 [ctrl-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.  

Create a second branch from the existing route, which goes to another runway. To do so, press [ctrl-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 [ctrl-a] to deselect all objects. Then select a gate by pressing [shift-left mouse button], and start drawing until 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.  

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).  

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 well, 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 down 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.

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 parking spaces may never have more than one push back route. The formal criteria for a valid push back route is that each gate should have a maximum of one push back 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 push back 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, 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.  

* '''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 aforementioned automatic geometry function.

* '''Routing''' One of the most persistent headache causing problems is that of a disconnected parking space 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 space 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.  

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 fairly small, and most aircraft won't fit into the assigned space. Therefore, you need to edit the parking space parameters. In addition, you also need to give each parking space a name, and a heading, and probably an airline code. 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 startup 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 text editor. Once you save the project, this will be done in a file [filename].tpj (TaxiDraw project). The ground network will be saved in a file named [filename]-groundnet.xml, which will be in the same folder as where you saved the project.

Finally, once you have finished creating a groundnet project, you can test it in FlightGear. Create a directory in your <tt>[[$FG_SCENERY]]/Airports/[I]/[C]/[A]/</tt> directory, with the three first letters of the ICAO code of your airport. For example <tt>[[$FG_SCENERY]]/Airports/E/H/A/</tt>. Next, locate the file [filename]-groundnetwork.xml and copy this to the directory you just created. Finally, rename the file you just copied to <tt>[ICAO].groundnet.xml</tt>.

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 that can't be placed at one of the parking locations will be placed at a default location.  

As of Sep 2015 Flightgear has 90 airports that were made with Taxidraw.

900 airports have a complete groundnet, the rest have only parking positions. They (and those 90 airports that were made with TaxiDraw) are distributed via Terrasync since January 2016.