https://wiki.flightgear.org/w/api.php?action=feedcontributions&feedformat=atom&user=PortreekidFlightGear wiki - User contributions [en]2026-05-27T10:35:04ZUser contributionsMediaWiki 1.39.6https://wiki.flightgear.org/w/index.php?title=Catalog_metadata&diff=142861Catalog metadata2025-11-02T20:36:59Z<p>Portreekid: Changed URL</p>
<hr />
<div>Tags with '''catalog metadata''' can be added to aircraft to help searching and filtering them, for example in the launcher or future versions of the [[Aircraft Center|aircraft center]], so that a user can quicker find the aircraft of interest.<br />
<br />
{{Package Management}}<br />
<br />
== Status/news ==<br />
Now that James has merged the preview and [[splash screen]] changes, he wants to start a concerted effort to improve the metadata of all the aircraft in FGaddon. This means: <br />
<br />
* Ensuring there is a suitable "long" description <br />
* Adding or updating ratings <br />
* Ensuring variant or primary info is correct <br />
* Ideally adapting to the new preview/splash system (but not required) <br />
* Adding metadata tags, for better searching/usability the future <br />
<br />
All of these are intended to help users browsing the aircraft, via the launcher or other methods. The proposal by James is to post about this on the forum, and ask for volunteers to pick aircraft, and submit patches or updates to myself and some other willing reviewers (Stuart has also volunteered as reviewer, but more people are welcome). Aside form ensuring high quality, we also need to ensure that aircraft maintainers are given the opportunity to update their own aircraft. Any co-volunteers to manage the process, and especially suggestions on how to manage this in a way that is friendly towards aircraft maintainers, but also gives a reasonable chance that 90% of aircraft in FGaddon have up to date metatdata by the next release, are welcome. I am sure we will have the usual debate on subjectivity of ratings, but, that’s another thing the reviewers will have to deal with. (James Turner suggested there is some criteria on the wiki from the last time we did this?) (There is a task on me to link the tagging system into the aircraft search, so that searching on "fighter" or "glass-cockpit" brings up appropriate matches. This tends to work out anyway when aircraft have a long-description text, but it is still very beneficial to the launcher to have some meta-data about how aircraft are used).<ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/message/35688820/ <br />
|title = <nowiki>[Flightgear-devel] Improving FGaddon aircraft meta-data </nowiki><br />
|author = <nowiki> James Turner </nowiki> <br />
|date = Feb 26th, 2017 <br />
|added = Feb 26th, 2017 <br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
== Catalogs ==<br />
The overall aim is to support a decentralized development system with the only central point being the aircraft package manager for end users.<ref>{{cite web <br />
|url = http://sourceforge.net/p/flightgear/mailman/message/33413096/<br />
|title = <nowiki>Re: [Flightgear-devel] FGDATA split without Aircraft. Addon in SVN. (re)Suggesting a Submodule approach. (Re)Proposing a</nowiki><br />
|author = <nowiki>James Turner</nowiki><br />
|date = <nowiki>2015-02-13</nowiki><br />
}}</ref>. Users can simply add a hangar URL for FGUK, Lake of Constance or similar, and browse those aircraft within the launcher. <br />
<br />
Most importantly we can improve the end-user browsing and discovery experience by enforcing some required meta-data, images and similar in the catalogs, and we can manage the install process so that users don’t get confused about where to move an aircraft file.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/<br />
|title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins </nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2015-03-11</nowiki><br />
}}</ref><br />
<br />
FGMeta contains a <code>create_catalog.py</code> script which runs over FGAddon but could be used against another aircraft store containing multiple aircraft to generate a catalog used by the launcher in combination with a webhost to publish aircraft to users.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33550567/<br />
| title=<nowiki>Re: [Flightgear-devel] FGData size reduction </nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2015-03-06</nowiki><br />
}}</ref><br />
<br />
The catalog is just an XML file, and the other files needed are the thumbnail images for each package, and the package Zip files themselves; The system is deliberately designed to be able to be hosted statically on any web provider. The <code>create_catalog.py</code> gives one example of creating a suitable catalog XML file, but any other approach is also valid.<ref>{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33586444/<br />
|title=<nowiki>Re: [Flightgear-devel] FGDATA and Jenkins</nowiki><br />
|author=<nowiki>James Turner</nowiki><br />
|date=<nowiki>2015-03-11</nowiki><br />
}}</ref><br />
<br />
== Supported Tags ==<br />
{{Note|Please do not extend this list without discussion and agreement.}}<br />
<br />
The tags are translation and search keys, not human-readable strings. Any additions or changes mean updated translation files. The catalog-generator script will reject aircraft with non-standard tags!<br />
<br />
The definitive list of tags can be found here: https://gitlab.com/flightgear/fgmeta-python/-/blob/next/src/flightgear/meta/aircraft_catalogs/catalogTags.py?ref_type=heads<br />
Tags are designed to be inclusive, not exclusive, to give the broadest range of search results. If multiple tags apply, use them. The DC-3 for example have had multiple civilian and military roles.<br />
<br />
=== Aircraft types ===<br />
<br />
* <code>aerobatic</code><br />
* <code>airship</code><br />
* <code>balloon</code><br />
* <code>bizjet</code><br />
* <code>bomber</code><br />
* <code>cargo</code><br />
* <code>carrier</code><br />
* <code>fighter</code><br />
* <code>ga</code><br />
* <code>glider</code><br />
* <code>groundvehicle</code><br />
* <code>helicopter</code><br />
* <code>interceptor</code><br />
* <code>passenger</code><br />
* <code>racer</code><br />
* <code>spaceship</code><br />
* <code>tanker</code><br />
* <code>trainer</code><br />
* <code>transport</code><br />
* <code>ultralight</code><br />
* <code>unpowered</code><br />
* <code>uav</code><br />
* <code>reconnaissance</code><br />
* <code>seacraft</code><br />
* <code>crop-duster</code><br />
* <code>bush-plane</code><br />
<br />
=== Manufacturers ===<br />
The intention here is to provide logical groupings, not to track corporate history. For example the MD-80 and MD-11 would get the <code>douglas</code> tag, which will likely translate to "Douglas / McDonell-Douglas" in the user interface. The Boeing 717 could get the <code>boeing</code> and <code>douglas</code> tags. Also it is not supposed to be an exhaustive list. This is so we for example can search for "all glass-cockpit Boeing and Airbus aircraft". It might be worth actively lying in the tags, in essence group all Hawker-Siddley/BAC/Avro aircraft under the <code>vickers</code> tag.<br />
<br />
* <code>airbus</code><br />
* <code>antonov</code><br />
* <code>arado</code><br />
* <code>atr</code><br />
* <code>avro</code><br />
* <code>bae</code><br />
* <code>bell</code><br />
* <code>bleriot</code><br />
* <code>boeing</code><br />
* <code>bombardier</code><br />
* <code>caudron</code><br />
* <code>cessna</code><br />
* <code>consolidated</code><br />
* <code>dassault</code><br />
* <code>diamond</code><br />
* <code>dornier</code><br />
* <code>douglas</code><br />
* <code>embraer</code><br />
* <code>eurocopter</code><br />
* <code>fairchild</code><br />
* <code>fairey</code><br />
* <code>focke-wulf</code><br />
* <code>fokker</code><br />
* <code>general-dynamics</code><br />
* <code>gotha</code><br />
* <code>grumman</code><br />
* <code>handley-page</code><br />
* <code>hawker</code><br />
* <code>heinkel</code><br />
* <code>ilyushin</code><br />
* <code>junkers</code><br />
* <code>kawasaki</code><br />
* <code>lockheed</code><br />
* <code>mc-donnell-douglas</code><br />
* <code>messerschmitt</code><br />
* <code>mikoyan-gurevich</code><br />
* <code>mitsubishi</code><br />
* <code>north-american</code><br />
* <code>northrop</code><br />
* <code>pilatus</code><br />
* <code>piper</code><br />
* <code>republic</code><br />
* <code>robin</code><br />
* <code>rockwell</code><br />
* <code>saab</code><br />
* <code>short</code><br />
* <code>sopwith</code><br />
* <code>spad</code><br />
* <code>sukhoi</code><br />
* <code>supermarine</code><br />
* <code>tupolev</code><br />
* <code>vickers</code><br />
* <code>vought</code><br />
* <code>wright</code><br />
* <code>yakovlev</code><br />
<br />
<br />
=== Eras ===<br />
Logical groupings, not historical accuracy. Some aircraft are going to have a lot of these, for example the B-52. Again the goal is intelligent searches: "show me all WW2 fighters". Wee would like to avoid this getting political too and comments on that are welcome.<br />
<br />
* <code>1910s</code><br />
* <code>1920s</code><br />
* <code>1930s</code><br />
* <code>1940s</code><br />
* <code>1950s</code><br />
* <code>1960s</code><br />
* <code>1970s</code><br />
* <code>1980s</code><br />
* <code>1990s</code><br />
* <code>2000s</code><br />
* <code>2010s</code><br />
* <code>2020s</code><br />
* <code>coldwar</code><br />
* <code>early-pioneers</code><br />
* <code>golden-age</code><br />
* <code>gulfwar1</code><br />
* <code>gulfwar2</code><br />
* <code>vietnam</code><br />
* <code>ww1</code><br />
* <code>ww2</code><br />
<br />
=== Aircraft Features ===<br />
This could get long, as always trying to focus on tags people might search for, for example: "show me all the VTOL aircraft" or "show me all the biplanes". Some will be very useful in improving the user experience; If the plane is tagged with seaplane we might be able to force a water start (but not for amphibious aircraft obviously).<br />
<br />
* <code>aerobatic</code><br />
* <code>airship</code><br />
* <code>amphibious</code><br />
* <code>biplane</code><br />
* <code>canard</code> - Canard planform<br />
* <code>castering-wheel</code><br />
* <code>combat</code><br />
* <code>delta</code> - Delta planform; Vulcan, Concorde, Space Shuttle<br />
* <code>etops</code> - ETOPS capable aircraft, presumably implies twin-engined<br />
* <code>experimental</code> - For X1 and similar X-planes<br />
* <code>fictional</code><br />
* <code>fixed-gear</code><br />
* <code>floats</code><br />
* <code>glass-cockpit</code><br />
* <code>low-wing</code><br />
* <code>mid-wing</code><br />
* <code>high-wing</code><br />
* <code>h-tail</code><br />
* <code>hud</code><br />
* <code>ifr</code> - Panel and equipment (radios, lighting) suitable for IFR flight<br />
* <code>lifting-body</code><br />
* <code>pressurised</code> - Pressurised cabin<br />
* <code>prototype</code><br />
* <code>refuel</code> - Supports air-to-air refeuling<br />
* <code>retractable-gear</code><br />
* <code>seaplane</code> - Flying boat or float plane<br />
* <code>skis</code><br />
* <code>stol</code> - For short-takeoff<br />
* <code>supersonic</code><br />
* <code>supercharger</code><br />
* <code>t-tail</code><br />
* <code>tail-dragger</code><br />
* <code>tricycle</code><br />
* <code>tail-hook</code><br />
* <code>triplane</code><br />
* <code>twin-boom</code><br />
* <code>v-tail</code><br />
* <code>variable-geometry</code> - For Tomcats and the like<br />
* <code>vtol</code> - For the Harrier, F-35, and the Osprey<br />
* <code>wing-fold</code> - usually for carrier aircraft<br />
* <code>water-drop</code><br />
<br />
=== FlightGear Features ===<br />
* <code>combat</code> - Support this various MP combat / bomb-able options<br />
* <code>dual-controls</code> - Supports copilot over MP<br />
* <code>tow</code> - Supports glider [[towing]] over MP<br />
* <code>rembrandt</code> - Supports Rembrandt, obviously<br />
<br />
=== Propulsion ===<br />
* <code>afterburner</code><br />
* <code>diesel</code><br />
* <code>electric</code> - For power-assisted gliders, mostly.<br />
* <code>jet</code><br />
* <code>propeller</code><br />
* <code>piston</code><br />
* <code>radial</code> - Radial piston engined<br />
* <code>rocket</code><br />
* <code>single-engine</code><br />
* <code>supercharged</code><br />
* <code>turboprop</code> - For pistons with a turbo-charger<br />
* <code>twin-engine</code><br />
* <code>four-engine</code><br />
* <code>variable-pitch</code><br />
* <code>fixed-pitch</code><br />
<br />
== Examples ==<br />
* B-52 would have: <code>bomber</code>, <code>jet</code>, <code>boeing</code>, <code>coldwar</code>, <code>1960s</code>, <code>vietnam</code>, <code>1970s</code>, <code>1980s</code>, <code>gulfwar1</code>, <code>nato</code>, <code>refuel</code>, <code>retractable-gear</code> and <code>ifr</code>.<br />
* Citation would have: <code>cessna</code>, <code>bizjet</code>, <code>jet</code>, <code>2-engine</code>, <code>glass-cockpit</code>, <code>ifr</code> and <code>retractable-gear</code>.<br />
* Cub would have: <code>piper</code>, <code>piston</code>, <code>1-engine</code>, <code>ga</code>, <code>trainer</code>, <code>fixed-gear</code>, <code>1930s</code>, <code>ww2</code> and <code>tail-dragger</code>.<br />
<br />
== Adding metadata to aircraft ==<br />
The tags are added to or included into the <code><nowiki><sim></nowiki></code> section of the [[Aircraft-set.xml]] file(s), like for example below:<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<br />
<PropertyList><br />
<br />
<!-- ... --><br />
<br />
<sim><br />
<br />
<!-- ... --><br />
<br />
<tags><br />
<tag>passenger</tag><br />
<tag>boeing</tag><br />
<tag>jet</tag><br />
<tag>twin-engine</tag><br />
<tag>retractable-gear</tag><br />
<tag>etops</tag><br />
<tag>glass-cockpit</tag><br />
<tag>ifr</tag><br />
</tags><br />
<br />
<!-- ... --><br />
<br />
</sim><br />
<br />
<!-- ... --><br />
<br />
</PropertyList><br />
<br />
</syntaxhighlight><br />
<br />
== References ==<br />
<references /><br />
<br />
== Related content ==<br />
=== Wiki articles ===<br />
* [[Aircraft rating system]]<br />
* [[Aircraft-set.xml]]<br />
* [[FlightGear hangars#Third party sites]] - List of third-party hangars, of which some have an <code>catalog.xml</code> file.<br />
* [[Hangar catalog]]<br />
* [[Simplifying Aircraft Deployment]]<br />
<br />
=== Forum topics ===<br />
* {{forum link|t=31915|text=Help tag aircraft}} (March-June 2017)<br />
<br />
=== Developer mailing list threads ===<br />
* {{cite web |url=http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/D4E91618-5AE0-4073-98B3-43711E70871A%40mac.com/#msg32375981 |title=<nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> 24 days from freeze: what happened to...}}<br />
<br />
=== Source code ===<br />
* {{fgmeta source|path=catalog/catalogTags.py}}<br />
<br />
[[Category:Core development projects]]<br />
[[Category:Aircraft enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=GitLab&diff=142095GitLab2025-07-14T18:56:20Z<p>Portreekid: Added pre-commit</p>
<hr />
<div>'''GitLab''' is an open source hosting infrastructure provider. Since January 2025, it hosts several [[Git]] version control repositories of [[FlightGear]] that were previously hosted on [[SourceForge]].<br />
<br />
====Development====<br />
<br />
=====pre-commit=====<br />
When opening a PR in GitLab a pre-commit hook is run. You can test your changes locally with<br />
git diff --name-only next HEAD | xargs pre-commit -files<br />
This changes/fixes your local repo so you can commit, check oder reset the changes.<br />
<br />
<syntaxhighlight lang="bash"><br />
fix end of files.........................................................Failed<br />
- hook id: end-of-file-fixer<br />
- exit code: 1<br />
- files were modified by this hook<br />
<br />
Fixing src/AIModel/AIConstants.hxx<br />
Fixing src/ATC/ATCController.hxx<br />
<br />
trim trailing whitespace.................................................Failed<br />
- hook id: trailing-whitespace<br />
- exit code: 1<br />
- files were modified by this hook<br />
<br />
Fixing src/Airports/groundnetwork.cxx<br />
Fixing src/AIModel/AIAircraft.cxx<br />
Fixing src/AIModel/AIConstants.hxx<br />
Fixing src/ATC/ATCController.cxx<br />
Fixing src/ATC/trafficcontrol.cxx<br />
Fixing src/ATC/ATCController.hxx<br />
Fixing src/AIModel/AIFlightPlanCreate.cxx<br />
Fixing src/ATC/GroundController.cxx<br />
<br />
codespell................................................................Failed<br />
- hook id: codespell<br />
- exit code: 65<br />
<br />
src/AIModel/AIFlightPlan.hxx:53: nam ==> name<br />
src/AIModel/AIFlightPlan.hxx:53: nam ==> name<br />
src/ATC/ApproachController.cxx:91: exsists ==> exists<br />
src/Airports/groundnetwork.cxx:183: backard ==> backward<br />
src/ATC/ATCController.hxx:43: acknowlegde ==> acknowledge<br />
src/ATC/trafficcontrol.cxx:76: existant ==> existent<br />
src/ATC/trafficcontrol.cxx:105: paramater ==> parameter<br />
src/ATC/trafficcontrol.cxx:213: paramater ==> parameter<br />
src/ATC/GroundController.cxx:158: acknowlegde ==> acknowledge<br />
src/ATC/GroundController.cxx:537: maintanance ==> maintenance<br />
<br />
yamlfmt..............................................(no files to check)Skipped<br />
clang-format.............................................................Failed<br />
- hook id: clang-format<br />
- files were modified by this hook<br />
reuse lint-file..........................................................Failed<br />
- hook id: reuse-lint-file<br />
- exit code: 1<br />
<br />
src/ATC/ApproachController.cxx: no license identifier<br />
src/ATC/trafficcontrol.hxx: no license identifier<br />
src/ATC/TowerController.cxx: no license identifier<br />
src/ATC/trafficcontrol.hxx: no copyright notice<br />
src/ATC/trafficcontrol.cxx: no license identifier<br />
test_suite/unit_tests/AI/TestSuite.cxx: no license identifier<br />
src/ATC/GroundController.cxx: no license identifier<br />
src/ATC/atc_mgr.cxx: no license identifier<br />
src/ATC/atc_mgr.cxx: no copyright notice<br />
<br />
</syntaxhighlight><br />
==References==<br />
<br />
*[https://gitlab.com/flightgear FlightGear GitLab website]<br />
*{{wikipedia |Gitlab |GitLab wikipedia article}}<br />
<br />
[[Category:Hosting infrastructure]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=Geographic_Coordinate_Systems&diff=141833Geographic Coordinate Systems2025-05-07T19:20:03Z<p>Portreekid: Changed link https://www.edwilliams.org/avform147.htm</p>
<hr />
<div>[[FlightGear]] uses a set of different coordinate systems to express geographic locations.<br />
All these coordinates are based on the [[WGS84]] [[Ellipsoid]].<br />
<br />
Scenery layout, airports, runways, navaids, aircraft positions, and all that sort of stuff is all based on WGS84. There are some additional coordinate systems that FlightGear uses internally, but that is typically hidden deep inside the code.<br />
<br />
== Geocentric and Geodetic Coordinates ==<br />
<br />
Both geocentric and geodetic coordinates are expressed as a triple of latitude, longitude and altitude.<br />
In both cases, '''altitude''' is the height of the respective point above the surface of the [[Ellipsoid]] and '''longitude''' is the angle between the planes parallel to the earth axis and passing through the Greenwich Meridian respectively the point designated by the coordinates.<br />
<br />
The difference between geocentric and geodetic coordinates lies in the definition of '''latitude''':<br />
<br />
* In '''geocentric coordinates''' latitude is the angle between the equatorial plane and the line crossing through the earth's center and the point designated by the coordinates.<br />
* In '''geodetic coordinates''' latitude is the angle between the equatorial plane and the '''normal''' at the designated point, i.e. the vector standing perpendicular on the [[Ellipsoid]] at the designated point.<br />
<br />
''Note'': The position-properties under /position in the [[property tree]] are '''geodetic coordinates'''.<br />
<br />
== Cartesian Geocentric Coordinates ==<br />
<br />
Cartesian geocentric coordinates are defined in terms of a cartesian coordinate system with<br />
<br />
* the center of the earth being the origin,<br />
* the z-axis aligned with the earth axis pointing north,<br />
* the x-axis going through the Greenwich Meridian at its intersection with the equator, and<br />
* the y-axis going through the intersection of the meridian at 90 degrees east and the equator.<br />
<br />
This is also call the [https://en.wikipedia.org/wiki/ECEF Earth-Centered Earth-Fixed] coordinate system.<br />
<br />
== Conversion ==<br />
<br />
The essential maths required to convert coordinates are covered at: https://www.edwilliams.org/avform147.htm<br />
<br />
The [[SimGear]] library provides static methods for conversion in the class <code>SGGeodesy</code>, to be found in <code>simgear/math/SGGeodesy.hxx</code>:<br />
<br />
* <code>SGGeodesy::SGCartToGeod(const SGVec3<double>& cart, SGGeod& geod)</code> converts a cartesian point to geodetic coordinates.<br />
* <code>SGGeodesy::SGGeodToCart(const SGGeod& geod, SGVec3<double>& cart)</code> converts a geodetic point to cartesian coordinates.<br />
* <code>SGGeodesy::SGCartToGeoc(const SGVec3<double>& cart, SGGeoc& geoc)</code> converts a cartesian point to geocentric coordinates.<br />
* <code>SGGeodesy::SGGeocToCart(const SGGeoc& geoc, SGVec3<double>& cart)</code> converts a geocentric point to cartesian coordinates.<br />
<br />
Further, the classes <code>SGGeod</code> and <code>SGGeoc</code> (found in <code>simgear/math/SGGeod.hxx</code> and <code>simgear/math/SGGeoc.hxx</code>, respectively) provide static conversion methods for convenience, which use the methods listed above.<br />
<br />
Note that most of these conversions are expensive to compute - check the external links to see how it works.<br />
== External links ==<br />
* [http://www.cage.curtin.edu.au/~sten/pubs/feaw2008.pdf Closed-form transformation between geodetic and ellipsoidal coordinates]<br />
<br />
{{Terra}}<br />
<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=TerraMaster&diff=141332TerraMaster2025-02-09T21:09:56Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
|title = TerraMaster<br />
|logo =<br />
|image = TerraMaster r32 - Global view.png<br />
|developedby = reeed, portree kid<br />
|initialrelease = July 18, 2011<br />
|latestrelease = February 9, 2025 (v3.03)<br />
|writtenin = Java<br />
|os =<br />
|platform = Cross-platform<br />
|developmentstatus =<br />
|type = Scenery manager<br />
|license = [[GNU GPL]] v2<br />
|website = https://portree-kid.github.io/terramaster/<br />
}}<br />
<br />
'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the [[FlightGear Scenery Database]]. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.<br />
<br />
== Overview ==<br />
=== Map ===<br />
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.<br />
<br />
=== Icons ===<br />
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:<br />
* ''Status field''. Shows the name of the tile that was last selected.<br />
<br />
* ''Sync icon''. Syncs the tiles currently selected.<br />
* ''Clock icon''. Syncs old tiles.<br />
* ''Flight icon''. Opens a dialog to help selecting a route.<br />
* ''Trash can icon''. Deletes the currently selected tiles.<br />
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.<br />
* ''Stop button''. Currently does not work.<br />
<br />
* ''Empty paper''. Hides all shown airports.<br />
* ''Globe icon''. Zooms out to the global view.<br />
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.<br />
<br />
* ''Search field''. Used to search for airports.<br />
<br />
* ''Sync progress bar''. Only visible during syncing.<br />
<br />
=== Tile border colours ===<br />
The tiles are colour coded to represent the state of the tiles:<br />
<br />
* '''Green''' tiles have both terrain and objects.<br />
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)<br />
* '''Red''' tiles are currently selected for synchronisation.<br />
* '''Blue''' tiles are currently being synchronised.<br />
<br />
The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.<br />
<br />
== Using ==<br />
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]<br />
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]<br />
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]<br />
<br />
=== Zooming and panning ===<br />
TerraMaster with the global view. Left-clicking will zoom you in on an area.<br />
<br />
'''Zoom''' using the scroll wheel.<br />
<br />
'''Pan''' around by dragging the map while pressing the right mouse button.<br />
<br />
Get '''back to global view''' by clicking the "globe" icon.<br />
<br />
=== Showing tile information ===<br />
To get some information about a downloaded tile, hold the mouse pointer over it.<br />
<br />
A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.<br />
<br />
=== Syncing tiles ===<br />
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles. <br />
<br />
To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.<br />
<br />
'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.<br />
<br />
=== Syncing old tiles ===<br />
<br />
'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.<br />
<br />
=== Deleting tiles ===<br />
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.<br />
<br />
=== Showing all airports in a tile ===<br />
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.<br />
<br />
=== Searching for an airport ===<br />
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.<br />
<br />
Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.<br />
<br />
== Video tutorial ==<br />
Here is a short video tutorial:<br />
{{#ev:youtube|YxWV4wk_dHw}}<br />
<br />
== Tips ==<br />
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].<br />
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.<br />
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.<br />
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.<br />
<br />
== Installing ==<br />
Before installing, make sure you have Java 6 or higher, as it is needed. NB: On Ubuntu 22.04 (Jammy) OpenJDK 8+ works.<br />
<br />
# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].<br />
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code><br />
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.<br />
# Done!<br />
<br />
== External link ==<br />
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}<br />
<br />
[[Category:Scenery software]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=AI_Traffic&diff=141265AI Traffic2025-01-22T15:15:22Z<p>Portreekid: /* Nearness rose */</p>
<hr />
<div>{{AI Navbar}}<br />
<br />
'''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic.<br />
<br />
In essence, the AI controlled traffic system is comprised of four elements: <br />
# AI Aircraft models: Are part of the base package under <tt>$DATA/AI/Aircraft</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. <br />
# AI traffic schedules: Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircraft should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> <br />
# Groundnets: Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircraft on the ground from gates to runways and vice versa, at each individual airport (one per airport). The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.<br />
# Runway Use Configurations (RWYUSE): Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and condition which runway(s) are for AI take off and landings based on the time of the day and wind conditions.<br />
<br />
<br />
<br />
= Traffic Schedules =<br />
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.<br />
<br />
In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircraft available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircraft will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.<br />
AI aircraft provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.<br />
<br />
To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.<br />
<br />
Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircraft do not time travel no teleport). <br />
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.<br />
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.<br />
<br />
It is recommended the traffic schedules follow as much as possible reality and so they should include turnaround time at each airport even if an AI aircraft does not require cleaning and refuelling.<br />
<br />
To facilitate scheduling, a new database format was introduced in FlightGear 1.9.0 and flights are no longer directly and rigidly assigned to a specific aircraft (Unique registration). 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.<br />
<br />
<br />
== An example of a traffic file ==<br />
<br />
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:<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCB</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<br />
<flight><br />
<callsign>KLM0765</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>0/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCM</port><br />
<time>0/21:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
<br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>TNCM</port><br />
<time>3/01:25:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>EHAM</port><br />
<time>3/10:50:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</trafficlist><br />
</syntaxhighlight><br />
<br />
== Dissecting the traffic file ==<br />
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.<br />
<br />
=== General layout ===<br />
The general layout of each file should look like the above example.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<br />
</trafficlist><br />
</syntaxhighlight><br />
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.<br />
<br />
=== Defining the aircraft ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
...<br />
</aircraft><br />
</trafficlist><br />
</syntaxhighlight><br />
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.<br />
<br />
* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.<br />
* '''<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 aircraft type ('''<actype>''') and paint scheme, but I abandoned that idea, because it didn't turn out to be very compatible with the existing FlightGear model loading code. <br />
* '''<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. <br />
* '''<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 in the routing algorithm. '''[New for Traffic Manager II]'''<br />
* '''<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]'''<br />
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].<br />
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are built 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.<br />
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.<br />
* '''<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:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''<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:<br />
** '''light_aircraft''' (General aviation prop driven single or twin),<br />
** '''turboprop_transport''' (Commercial Turboprop),<br />
** '''jet_transport''' (Commercial jet)<br />
** '''heavy_jet''' (Commercial jet w/ MTOW > 136tons)<br />
** '''ww2_fighter''' (world war two fighter),<br />
** '''jet_fighter''' (modern fighter aircraft)<br />
** '''tanker''' (tanker aircraft), or.<br />
** '''ufo''' (allows extreme accel/decel capabilities).<br />
* '''<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.<br />
* '''<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.<br />
<br />
=== Defining a flight ===<br />
The Traffic Manager II file formats contains separate sections for both aircraft 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:<br />
<syntaxhighlight lang="xml"><br />
<aircraft> <br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</aircraft><br />
<br />
<flight><br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</flight><br />
</syntaxhighlight><br />
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. <br />
<syntaxhighlight lang="xml"><br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>2/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCB</port><br />
<time>2/22:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</syntaxhighlight><br />
The '''<flight>''' 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:<br />
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.<br />
* '''<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''').<br />
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section. <br />
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.<br />
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<nowiki><time></nowiki>''' keywords.<br />
* '''<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. Values are in [https://en.wikipedia.org/wiki/Flight_level flightlevels]<br />
* '''<arrival>''' Same as '''<departure>''', but now defining the '''<port>''' and '''<nowiki><time></nowiki>''' of arrival.<br />
* '''<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.<br />
* '''<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. <br />
* '''<nowiki><time></nowiki>''' 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 unpredictable. Times should be in UTC. Weekdays start on Sunday (0) and end on Saturday (6).<br />
<br />
== Putting it all together: Including a traffic file ==<br />
Traffic files are found under [[$FG_ROOT]]/AI/Traffic. The actual traffic files should be stored in a subdirectory one level below /AI/Traffic.<br />
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.<br />
<br />
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 aircraft with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.<br />
<br />
= Ground networks =<br />
<br />
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircraft can park precisely at the Terminal gates]]<br />
<br />
Using the traffic files information above, the AI Traffic Manager knows which AI aircraft should land at (and take off from) each airport and when. It will automatically place the relevant aircraft models in the scenery and animate them so they navigate from the runways to the gates and vice versa, according to their individual schedule.<br />
<br />
Although the physical layout of each airport is stored in FlightGear's APT.DAT master file, the information is not accurate enough to determine which specific routes AI models can use; Instead, Traffic manager will rely on a dedicated file containing a simple wireframe/network of taxiways and gates AI aircraft can follow whilst on the ground ie a GroundNet. A groundnet is made of 3 different elements: Parking Positions, Nodes and Segments (to join nodes and Parking together). <br />
<br />
This routing information is aggregated, per airport, in a XML, stored and distributed by Terrasync as '''/Terrasync/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml''' where ICAO stands for the 4 letter ICAO code of the relevant airport.<br />
<br />
Similarly to Terrain and Objects, Terrasync groundnets can be overridden by placing a personalized version in your custom scenery folder, using the same path structure: /Custom Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.<br />
<br />
Groundnets are not mandatory but, in absence of this routing information, AI Aircraft cannot park anywhere; they will still try to stick to their schedule, appearing magically at the centre of the airport and taxiing directly to the runways’ thresholds, over grass, buildings and static objects, on time.<br />
<br />
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking. <br />
<br />
== A technical perspective ==<br />
A ground network xml file consists of four tables:<br />
* '''<frequencies>''' The Airport’s radio frequencies (Optional). As of v1.9.0, FlightGear uses these to display some ATC messages like start-up approval requests. You can "hear" them by tuning to the first ground frequency listed in the section.<br />
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircraft can use them.<br />
* '''<TaxiNodes>''' The list of all the nodes in the ground network.<br />
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.<br />
<br />
Each Parking and Node element in the groundnet has a unique index number, allowing routes be formed (from one ID to the next via a segment/arc) between parking positions and runways <br />
<br />
''Parking Positions Parameters:''<br />
* '''index''' Unique ID, internal to the file structure<br />
* '''lat''' latitude in decimal minutes format, for example <code>N50 56.988</code>)<br />
* '''lon''' longitude in decimal minutes format, for example <code>W01 21.756</code>)<br />
* '''name & number ''' (gate identification as found on airport charts, for example <code>D23</code> or <code>C1</code>). <br />
* '''type:''' The type of aircraft which can use this space. Matched to the <flighttype> parameter found in traffic files:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo/freighter)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''heading:''' The heading at which the aircraft parks in this space.<br />
* '''radius:''' The size of the parking spot. Matched to the aircraft <radius> parameter in traffic files to determine if a given AI Aircraft model will fit the position. See [[aircraft radii]]<br />
* '''airlineCodes:''' a comma-separated list of ICAO airline codes allowed to park at this gate. Matched to the aircraft <airline> parameter of traffic files. Leave blank for all airline to be able to use the gate.<br />
* '''pushBackRoute:''' The ID of the next node in the network along a pushback route. 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.<br />
<br />
''Nodes parameters:''<br />
<br />
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircraft waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear<br />
* '''holdPointType''' can have the following values:<br />
** '''None''' Not a holding point (normal taxi-through node) <br />
** '''PushBack''' The node marks the end of a pushback route, where the aircraft stops rolling backward and start rolling forward upon clearance. A pushback Holding Point can be part of more than one pushback route. See Pushback below. <br />
** '''Normal''' (Not yet supported): a regular taxiway holding point.<br />
** '''CAT II/III''' (Not yet supported): a special holding point for IFR conditions.<br />
<br />
''segments parameters:''<br />
<br />
* '''begin''' The id of the parking space or AINode where this segment starts<br />
* '''end''' The id of the parking space or AINode where this segment ends<br />
* '''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.<br />
* '''name''' Name of the taxiway.<br />
<br />
== Tools & Source Material ==<br />
Groundnets can be built using either FG Airports (v0.032 or later) or Taxidraw (legacy) <br />
<br />
[[FGAirports]] is the current tool of choice. Its philosophy is airport centered rather than file specific and allows you to visualize at a glance all of the existing groundnets as well as editing them and submitting them to Terrasync. It leverages Open Street Map data, APT.DAT and scenery xmls to provide a visual representation of the airport layout as well as thresholds and tower positions. <br />
<br />
FGA automatically checks the validity of groundnet files before submission and assess their adequacy by comparing the number of gates set against the volume of AI traffic at a particular airport.<br />
<br />
[[TaxiDraw]] pre dates WED and allowed the creation of airport layouts from basic geometrical shapes. Its ground network module is somewhat separate from the rest of the airport project code but allows the creation and local export of simple groundnets.<br />
<br />
See the [[TaxiDraw]] and [[FGAirports]] articles for instructions on how to obtain the tools and operating instructions.<br />
<br />
Most Civil Aviation authorities make electronic versions of their Aeronautical Information Publication available on the web (Lookup 'eAIP' or go to https://www.eurocontrol.int/articles/ais-online). AIPs contain precise Airport Charts but also lists of parking stands with their exact Latitude/Longitude as well as usage (Cargo, Gate) and the category (radii) of aircraft they can accommodate.<br />
<br />
Gates Numbers and Airlines operating them can often be found on Airports website. Most flight tracking sites/apps will also allow you to monitor a flight all to the way to its gate to identify who parks where.<br />
<br />
In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!<br />
<br />
== Ground traffic rendering ==<br />
''19th November 2021.''<br />
<br />
=== Performance ===<br />
<br />
* CPU: Currently having a lot of nodes in the OSG scene-graph will rapidly make FlightGear CPU bound. A lot of separately animated ground traffic objects mean a lot of nodes. Static objects (i.e. non-animated objects) can be put into one mesh - meaning one scenegraph node with the current system.<br />
* GPU: Having fewer draw calls is fast. Having fewer state changes is fast. <br />
* The fast path for both CPU and GPU is creating a way to combine multiple animated objects in one mesh - this is how modern 3d applications do lots of objects with animations fast.<br />
<br />
=== The fast way to do moving objects is to let the vertex shader look at information in buffers and position each object ===<br />
<br />
* Have all the different path segments stored in one buffer that can be read by the vertex shader. This buffer can be generated at runtime for each airport, maybe using NASAL scripts, and not updated.It's also possible to store the 1st buffer in TerraSync. <br />
* Have a second buffer store all per-object data in an array. The array is indexed by the object ID. This includes things like vehicle animation state, which path segment each object is on, the starting time, and a speed scaling factor. The second buffer is updated regularly by the CPU.<br />
* Two approaches to packing different types of objects in a 1 or few meshes <br />
**'''a).''' Every type of object is combined in one vertex buffer and rendered with the same shaders, texture atlas or array. Every vehicle is packed one after the other in the vertex buffers. Multiple types of vehicles are contained in the same mesh. Multiple instances of the same vehicle take up extra space. <br />
*** All material parameters or uniform values that change between objects, or within objects, like specularity are added as vertex attributes or textures. A vertex shader that can handle all object animations is used. <br />
*** The entire set of objects takes up one scene graph node, and is rendered in one draw call. It's possible to do ground vehicles and AI aircraft as two meshes.<br />
*** The object ID (an integer) can be added to each vertex as an vertex attribute. This is used to lookup per-object info in the 2nd buffer, including the paths from the first buffer.<br />
** '''b).''' Each different type of object (different ground vehicle) is instanced and takes up one scene-graph node. This can allow different shaders and textures per object type. There is less vertex data taking up RAM and VRAM. There are more scenegraph nodes, and draw calls.<br />
*** The object ID (an integer) can be added as a per-instance vertex attribute.<br />
* The vertex shader can trivially look at the object ID, then find the path segment, the starting time, speed scaling factor, and current time to position each object. If the current time is past the end of the current path, the object will stay at the end position.<br />
* The buffers can be a uniform array (minimum of points in each path segment and more smoothing), Uniform Buffer Object (UBO - not available until Vulkan due to Macs not supporting it), a Texture Buffer Object (TBO - Mac support unknown), or a texture looked up in a vertex shader (maybe slower).<br />
* Data format: Each path segment is x,y,z position at regular times - a time-series of positions - e.g. [10m, 20m, 0m elevation] at t = 1s. [20m, 25m, 0m] at t=2s . [30m, 30m, 0m] at t= 3s. 16 bit integers are enough, but 32 but floats can also be used at the cost of 2x the occupancy. 16 bit implementation: If a texture is used it can be 16bit RGB - R=x, G=y, B=z. 2 consecutive 8 bit values can also be read from a texture.16 bit integers can cover an ground traffic area of ~65km with a spacing of 1m. 16bits can give a ~13km ground traffic area with an accuracy of 20cm. The accuracy of the positions doesn't matter too much - the vertex shader can look at 2-3+ path positions and create a smooth interpolation (a smooth curve joining the points). The time steps can also be large. <br />
* If a path has a slowly moving segment, it will take up more points. If a path segment takes a short amount of time, it can have a special xyz numner to indicate path has ended - otherwise the path start/end time information can be stored as uniforms or in a UBO. Vehicles that move faster can have a higher speed scaling. There can be different path segment variations, for example if vehicles have a different acceleration pattern - e.g. speeding up and braking hard, or sharper turns, in an emergency.<br />
* Both ground vehicles, and taxiing aircraft can be done this way. It's possible to replace a conventional AI aircraft model, with a fast rendering ground traffic model once an aircraft starts taxiing.<br />
* If models use animations, they should ideally use a vertex shader that can handle all these animations - so having multiple draw calls per model and CPU-side animation is avoided.<br />
* It's possible to split of different parts of craft into separate meshes for parts that are very dissimilar - at the cost of more scenegraph nodes and draw calls. For example, a separate mesh for lights of various types - these lights will follow the same paths as the vechiles and position themselves correctly.<br />
* <br />
<br />
<br />
<br />
The way animation is handled (animation meaning moving objects, and parts of moving objects) in modern 3d application is to store the animation data in arrays/buffers on the GPU side and render multiple objects in one draw call.<br />
<br />
From a quick google search - a 2010 blog about whether UBOs or TBOs are more suited for different tasks:<br />
<br />
''"Personally I use them [UBOs] for instanced rendering by storing the model-view matrix and related information of each and every instance in a common uniform buffer and use the instance id as an index to this combined data structure. This usage performs very well on my system.''<br />
<br />
''Also uniform buffers can be used to store the matrices of bones and use them for implementing skeletal animation, however, I personally prefer using normal 2D textures for this purpose to take advantage of the free interpolation thanks to the dedicated texture fetching units but that’s another story.''<br />
<br />
''[..] Personally I use texture buffers for different geometry deformation techniques, to resolve batching issues when the size limitation of uniform buffers is a blocking factor, and for some inverse kinematics effects." - Rastergrid blog, 2010 [https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/][https://web.archive.org/web/20211119134448/https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/]''<br />
<br />
This is from a 2010 blog - this general approach has been the way to do lots of animated objects for a long time. <br />
<br />
Even really complicated animations like moving bodies and cloth physics are handled by moving animation data into buffers - this approach would be needed if FlightGear ever did a simulation of crowds at an airport - not just for boarding one plane which probably won't be too cripplingly slow. But for crowds boarding lots of planes, and moving about large airports. For animating humans, there are will be standard animation formats compatible with output of tools in blender or make human[http://www.makehumancommunity.org/]. This approach may also be worth while for rendering lots of seated passengers with really simple movements - and a few walking about with a simple walk cycle. It may also be justified for large amounts of ground personnel at big airports (not just a few relevant for the users plane).<br />
<br />
== Warnings and Limitations ==<br />
The complexity of building a fully functional groundnet (and the time spent on it) grows exponentially with the size of the airport but very small airports, on Pacific Islands for example, pose even larger challenges. An ideal project to start with is a Metropolitan airport with one or two runways, and two dozen of parking positions. <br />
<br />
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:<br />
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]<br />
* TM does not space landing aircraft. You will most likely see packs of landing aircraft hitting your runways at once, sometimes from both ends. Departures are spaced properly though <br />
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route. <br />
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied. <br />
* AI Aircraft cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight) <br />
<br />
* Groundnets, terrain and scenery objects are independent. If you see your AI aircraft rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.<br />
<br />
Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.<br />
<br />
Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircraft are handled. <br />
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.<br />
<br />
On the bright side, both Taxidraw and FG Airports contain a validation tool which will allow you to detect any structural problem with your groundnet. You will also find a lot of resources and tips in the AI section of the Flightgear forums.<br />
<br />
Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.<br />
[[File:Gate Definition in FG Airports.png|300px|thumb|FG Airports UI for Parking Position]]<br />
== Creating the base network == <br />
<br />
Objective:<br />
* You have enough gates for all AI aircraft using the airport<br />
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet<br />
* Each Runway(s) threshold has a unique link to the rest of the groundnet<br />
* Departing Aircraft can reach any threshold, from any parking position <br />
* Arriving Aircraft can reach any suitable parking position from any threshold<br />
<br />
<br />
'''Step 1 : Place and configure the Parking Positions'''<br />
<br />
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.<br />
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]] <br />
AI Aircraft will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.<br />
<br />
Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters. <br />
Military and General Aviation can also be used if you are running personalized traffic files on your machine.<br />
<br />
Adjust the heading and radius for each of your gates according to the maximum wingspan the stand can accommodate. See [[aircraft radii]]. <br />
Set a unique name for the gate.<br />
Leave the AIRLINE field empty at this point.<br />
<br />
'''Step 2 : Place and configure the Runway accesses'''<br />
<br />
AI aircraft need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.<br />
<br />
At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).<br />
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.<br />
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircraft will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.<br />
<br />
Backtracking: Certain airports do not have taxiways along the runway and aircraft will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].<br />
<br />
Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.<br />
[[File:Multiple Route leading to a single Threshold.png|thumb|Runway access routes must be unique]]<br />
Your access route must be unique: Traffic manager does not handle intersections (nodes with 4 routes) very well. Your take off points should not be connected to more than one route (case of taxiways on both sides of the runway feeding a single take off point from both sides as shown on the right.<br />
<br />
Select each of the nodes placed on the physical runway (not the ones leading to it) and mark them "On Runway" with the toggle in their properties panel <br />
<br />
'''Step 3 : Connect ParPos and Runway Access routes to form the groundnet.''' <br />
<br />
Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.<br />
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircraft as many routing options as possible.<br />
<br />
Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.<br />
<br />
Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircraft park straight and leave their parking straight (rolling forward or pushing back).<br />
<br />
Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircraft. In essence draw just enough routes so that all gates and runways are connected.<br />
<br />
'''Step 4 : Visual Check'''<br />
Once your base groundnet complete, Check visually that your parking positions do not overlap, that nodes placed on physical runways are marked as such and that intersections are formed properly (no node unless the aircraft can turn here)<br />
<br />
'''Step 5 : Structural Check and Test'''<br />
<br />
Run the verification tool (available in both Taxidraw and FGAirports). Both programs will ensure at this stage that routes are valid and that nodes on runway are marked as such. <br />
Taxidraw does not check the routes structures individually but rather that a route solution exist: If an aircraft can use different path/routes to go from its ParkPos to a given runway threshold and even if one of these routes is "broken" (unconnected segments) no error will be reported, because the aircraft could use another (unbroken) route to get to the threshold and hence still has a routing solution.<br />
<br />
FGAirports will do the same routing check but will also signal any unconnected node (broken routes). <br />
Correct the errors found and re run the verification tools until no more problems are found.<br />
<br />
Time to test with 'real' traffic. Save your groundnet and export it to a custom scenery folder (NOT to the Terrasync Folder), usually something like F:\My Sceneries\Airports\S\B\SBGR.groundnet.xml.<br />
Startup Flightgear and add your custom scenery folder path (the parent of \Airports) to your extra sceneries list in the Add On screen. Select your Airport as Startup Location. Run <br />
<br />
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]] <br />
* Parked aircraft will start appearing on the parking stands you have set. Departing aircraft will light up (red/green nav lights on wing tips, flashing beacon on top)<br />
* Upon ATC clearance (automatic) Departing aircraft will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.<br />
* Departing Aircraft will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off<br />
* Arriving aircraft will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off<br />
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircraft following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.<br />
* Aircraft will taxi from both directions on single taxiways, eventually passing through each other<br />
* On larger airports where AI aircraft can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier. <br />
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)<br />
* No aircraft (no AI traffic at this airport or not activated in FG options)<br />
* Aircraft queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)<br />
<br />
<br />
=== Refining the network: Routing Flow & Baggage Carousels Belts === <br />
<br />
Objective:<br />
* All Objectives in the "Creating the base Network" section<br />
* No clogging at intersections<br />
* No Head on crashes of aircraft sharing a single taxiway<br />
<br />
The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircraft will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.<br />
<br />
You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes: <br />
* AI traffic cannot make decisions: Typically, where presented with multiple routing options (an X intersection with 4 or more valid routes), AI traffic will consistently freeze/clog after some time if not immediately.<br />
* AI traffic does not stand bullying: If presented with no alternative at all (too many unidirectional routes) AI traffic will move away from your groundnet taxiways and start mowing the lawns. <br />
<br />
<br />
[[File:Groundnet Routing Flow Example.png|border|right|950px|Groundnet Routing Flow Example]]<br />
Keeping these two constraints in mind, the clogging and head on collisions noted in your previous tests can be addressed by setting up a ‘Routing Flow’. The purpose of said routing is to guide each aircraft to their final destination (Parking or Threshold), by ensuring it uses a single route and never crosses any other aircraft path.<br />
To achieve this we only have and need two tools: The ability to force the direction of traffic on any given segment (by making it “unidirectional”) and the ability of Traffic manager to handle priorities and queues formation at routes merging points (Y shaped intersections).<br />
<br />
The complexity of Routing Flow will increase exponentially with the number of gates, thresholds and traffic files handled: A single groundnet flow must accommodate indifferently a cargo flight arriving on RWY 1 in the evening or a commuter departing from RWY 2 in the morning.<br />
<br />
To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel. <br />
That is all bags (Aircraft) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).<br />
<br />
An advantage AI aircraft have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.<br />
<br />
Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.<br />
<br />
[[File:Apron Belt at Bahrein Intl.png|left|thumb|Using the Belt technique to feed the OBBI apron]] <br />
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.<br />
<br />
The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircraft to move from one belt to the other.<br />
<br />
You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.<br />
<br />
Certain smaller airports do not have enough taxiways to allow the formation of a proper global belt but the technique can be used on individual aprons to ensure proper flow in and out of parking areas and simplify the design of pushback routes (next section) as shown on the image on the left, at Bahrein Intl.<br />
<br />
Testing : Once your routing flows in place you should re-test you groundnet. The expected behaviour is the same then the one described in the “Base Network, Step 5” section, with the exception of head on collisions and clogged intersections which should no longer exist<br />
<br />
<br />
=== Refining the network: Pushback routes ===<br />
<br />
'''THIS SECTION IS WIP'''<br />
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. Pushback routes are optional (if you like the terminal crashing scenario described above).<br />
<br />
'''Examples of simple valid pushback routes''' (Left: If the taxiway is bidirectional | Centre: If the taxiway is not bidirectional | Right: With shared Pushback Holding point)<br />
<br />
[[File:MultiDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid AI Groudnet pushback for multi directional taxiway]] <br />
[[File:UniDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid Pushback Route on Un directional taxiway]]<br />
[[File:Shared Pushback Holding Point in Taxidraw.jpg|400px|Shared Pushback Holding Point]] <br />
<br />
[[File:Roll Forward Gate in Taxidraw.jpg|thumb|Invalid Park Pos Exist route : at and angle with Parking Position]]<br />
===== Pushback Holding Points must be unique per Parking Position =====<br />
<br />
Each Parking space (ParkPos) can't have more than one push back route and one pushback holding point at the end of the route. Nevertheless, multiple Parkpos can share part of their pushback routes and a single Pushback Holding Point.<br />
<br />
The formal criteria for a valid push back route is that each gate should have a maximum of one push back holding point associated with it, which can be reached using one route only.<br />
From an editing point of view, mark all segments between your parking position and its final holding point as "push back", do not forget to mark the ending node as Pushback Holding Point.<br />
<br />
===== The AI code does not handle sharp angles =====<br />
<br />
Add nodes to smoothen your routes so that no consecutive segments form an angle of less than 90 degrees. <br />
This rule applies to both pushback and roll forward / taxiways routes <br />
<br />
===== The Inbound route and the outbound routes are parallel ===== <br />
[[File:On Taxiway Pushback Holding Point in Taxidraw.jpg|thumb|Invalid Groudnet Pushback : Holding Point on Taxiway]]<br />
<br />
The last segment of the pushback route will condition the aircraft heading:<br />
<br />
1. During its travel along the pushback route <br />
<br />
2. At the Pushback Holding point (whilst waiting for clearance)<br />
<br />
3. On departing the pushback holding point, rolling forward to the runway.<br />
<br />
<br />
You can not control/force an AI aircraft to leave a Pushback Holding point at a different angle/heading than the one it came onto its final holding node at, whatever the number of routes you add.<br />
<br />
As a result, the last segment of the pushback route must align with the segment you expect the aircraft to use when starting to roll forward after clearance. The simpler set up is to have this final pushback segment overlapping the first segment of the roll forward route.<br />
<br />
Alternatively, the last segment of the pushback route can -itself- be the first segment of the roll forward route but this means Traffic Manager will consider this segment 'reserved' whilst the aircraft is pushing back and no other aircraft will be able to use the taxiway.<br />
<br />
For the same reason the Pushback Holding point should NOT be directly placed on the taxiway as shown in the image on the right 'On Taxiway Pushback Holding Point in Taxidraw'.<br />
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to. <br />
<br />
The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircraft which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI <br />
<br />
<br />
It is important to note that the Taxidraw "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 with all aircraft from one side of the E terminal are being linked to one shared push back point. <br />
<br />
Given the current push back system allows for fairly complicated behavior it is advisable to test extensively your groundnet and play with various configurations before sharing it to the community. <br />
<br />
Taxidraw note: TaxiDraw versions prior to February 5, 2009 did export the pushBackRoute attribute correctly. <br />
<br />
[[File:TaxiDraw2.png|thumb]]<br />
<br />
==== Verifying the network ====<br />
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. <br />
<br />
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.<br />
<br />
* '''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.<br />
* '''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. <br />
* '''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. <br />
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.<br />
<br />
=== Copying the ground network into FlightGear's scenery directory ===<br />
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>.<br />
<br />
In Taxidraw menu select File, Export AI Network and save the file in the above folde as ICAO.groundnet.xml. Please note that the File / Save project menu applies only to the airport layout and does NOT save your groundnet.<br />
<br />
=== Testing the network ===<br />
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. <br />
<br />
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.<br />
<br />
=== Airports with ground networks ===<br />
<br />
== Collision Detection == <br />
<br />
Version 2024.1.X and all version prior use an avoidance strategy based on the ground network. This means there are lots of Dijkstra calls to determine the possible route to the runway. Another implication is that the designer of the ground network must ensure the separation. This is of course not possible in pushback or even with the user aircraft. <br />
The next version will get real detection of nearness and integration with ATC. This is based on a Quadtree and just reacts on the current snapshot and not on "future" plans of an aircraft. <br />
<br />
=== Nearness rose ===<br />
[[File:Ai-windrose.png|thumb|A diagram showing an aircraft and different szenarios based on heading|none]]<br />
<br />
This diagram shows some possible angles of approach with the aircraft pointing away. <br />
<br />
* In this case all aircraft within the arc from -89° to +89° are considered blocking aircraft. <br />
* Speed must be adjusted to the speed of the other aircraft if it's positive<br />
<br />
[[File:Ai-windrose-approach.png|thumb|A diagram showing an aircraft and different szenarios based on heading|none]]<br />
<br />
====== Moving forward. ======<br />
<br />
* In this case all aircraft within the arc from -89° to +89° are considered blocking aircraft. <br />
* Aircraft must stop<br />
<br />
====== Moving in reverse ======<br />
<br />
* Speed must be adjusted to the speed of the other aircraft if it's negative<br />
<br />
=== Braking ===<br />
[[File:Following slowdown.png|thumb|A diagram showing the braking of a following aircraft|none]]<br />
<br />
When following aircraft must brake in a plausible way.<br />
<br />
= Runway Usage Configuration = <br />
<br />
ICAO.rwyuse.XML dictates which runway(s) should be used for AI take off and which ones accept AI landings. These instructions are organised in multiple sets (or configurations) and ordered by preference of use.<br />
<br />
Schedules can be defined so different runway configurations can be used at different time of the day. Different Sets can also be applied to the General Aviation and Commercial traffic.<br />
<br />
Each set of runway configuration is tested against the wind conditions and applies only if the crosswind and tailwind are within tolerance. If not, the next set in the order of preference, will be picked.<br />
<br />
Examples below taken from the Amsterdam Schiphol EHAM.rwyuse.xml file.<br />
<br />
Wind conditions are stored at the beginning of the file and indicate the maximum values of Crosswind and Tailwind acceptable to authorize take off and landing at the airport.<br />
<br />
<syntaxhighlight lang="xml"><br />
<wind tail="7"<br />
cross="20" /><br />
</syntaxhighlight><br />
<br />
{{quote|As well as aircraft, airports have operational crosswind and tailwind limits. [] The values vary but crosswind limits are normally 15-25 kts and tailwinds are normally no more than 10 kts.|ICAO|AMOFSG/10-SN No. 14}}<br />
<br />
The < time > table defines the hours of activation for a particular Schedule. Each schedule contains a 'Pattern' ie a fixed number of runways allocated to either take off or landing).<br />
<br />
For instance, at EHAM, the commercial "inbound" schedule is active from 06:20 to 08h30 UTC, at a time where there is more inbound than outbound traffic and the airport needs to allocate more runways to landing than to take off.<br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "06:20"<br />
end = "08:30"<br />
schedule = "inbound"/><br />
</syntaxhighlight><br />
<br />
In most cases, a single schedule can apply 24h every day. <br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "00:00"<br />
end = "24:00"<br />
schedule = "Day"/><br />
</syntaxhighlight><br />
<br />
<br />
The different sets of runways allocation are listed in each < schedule > table by order of preference and can be read/deciphered vertically as ”columns” delimited by commas.<br />
<br />
When wind conditions do not allow the use of a set, the next one will apply (next “column”).<br />
<br />
Still using the EHAM.rwyuse.xml file as example, from 06:20 to 08:30 UTC, when the Inbound schedule applies; AI traffic will preferably use runway 36L for take-offs, and both 06 and 36R for landings (first “column” of data).<br />
<br />
<syntaxhighlight lang="xml"><br />
<schedule name="inbound"><br />
<takeoff>36L, 24, 18L, 36L, 24, 24, 18L, 09</takeoff><br />
<landing>06, 18R, 18R, 36R, 27, 18R, 18R, 06</landing><br />
<landing>36R, 18C, 18C, 36C, 18R, 22, 22, 09</landing><br />
</schedule><br />
</syntaxhighlight><br />
<br />
Shall wind conditions prevent the use of this configuration (Tailwind or Crosswind values exeeding the ones defined in <wind> above), the next set (or “column”) will apply ie 24 for take-offs, and 18R + 18C for landings.<br />
<br />
Again, if wind conditions prevent this configuration use, the next set will be used (18L for take-offs, 18R and 18C for landing).<br />
<br />
This test of runway sets against wind values will continue with the rest of the sets in the schedule until a valid one is found and applied.<br />
<br />
It is necessary for each of the <takeoff> and <landing> entries to have an equal number of runway values, per schedule, so each set contains the same number of runways.<br />
<br />
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAMbEsE46ontK4G43zmrEqLEk%3D8ZK5sQ-vxZup%3DNjpaUDgb-ASw%40mail.gmail.com/#msg37166996 Source from Durk post in Devel]<br />
<br />
<br />
= Model Animation =<br />
<br />
To assist with creating realistic aircraft behaviour, some properties are set by the Traffic Manager during particular flight phases as follows<br />
<br />
{| class="wikitable"<br />
|-<br />
! Property !! Description !! Type !! At Gate !! Taxiing !! Take-off !! Cruise !! Approach and Landing<br />
|-<br />
| gear/gear[0..5]/position-norm || Gear Position || double (interpolated over 10 seconds || 1.0 || 1.0 || 0.0 (above 400ft) || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| surface-positions/flap-pos-norm || Flaps position || double (interpolated over 20 seconds || 0.0 || 0.0 || 0.5 (below 2000ft) || 0.0 || 1.0 ( below 2000ft)<br />
|-<br />
| surface-positions/spoiler-pos-norm || Spoiler position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (on runway)<br />
|-<br />
| surface-positions/speedbrake-pos-norm || Speedbrake position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| controls/lighting/beacon || Beacon || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/cabin-lights || Cabin lights || bool || true || true || true || false || false<br />
|-<br />
| controls/lighting/landing-lights || Landing lights || bool || false || false || false || true || true<br />
|-<br />
| controls/lighting/nav-lights || Navigation lights || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/strobe || Strobes || bool || false || false || true || true || true<br />
|-<br />
| controls/lighting/taxi-lights || Taxi lights || bool || false || true || false || false || false<br />
|}<br />
<br />
= SIDs / STARs =<br />
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 flight path, 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 way points. <br />
<br />
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-concept data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of this data. Note that this data is meant to be just that; a proof-of-concept. User contributions will be accepted as soon as the format has stabilized.<br />
<br />
= Appendix: Special Notes =<br />
<br />
<br />
== Performance ==<br />
With recent versions of FlightGear, we have much better performance than before 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. <br />
<br />
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.<br />
<br />
= Related content =<br />
* [[Airports with ground networks]]<br />
* [[FGAirports]] - A groundnet editor<br />
* [[Flightplan XML formats]]<br />
* [[Status of AI in FlightGear]]<br />
<br />
<br />
[[de:Interaktiver Verkehr]]<br />
<br />
[[Category:AI Traffic]]<br />
[[Category:FlightGear feature]]<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=AI_Traffic&diff=141264AI Traffic2025-01-22T14:17:45Z<p>Portreekid: /* Nearness rose */</p>
<hr />
<div>{{AI Navbar}}<br />
<br />
'''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic.<br />
<br />
In essence, the AI controlled traffic system is comprised of four elements: <br />
# AI Aircraft models: Are part of the base package under <tt>$DATA/AI/Aircraft</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. <br />
# AI traffic schedules: Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircraft should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> <br />
# Groundnets: Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircraft on the ground from gates to runways and vice versa, at each individual airport (one per airport). The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.<br />
# Runway Use Configurations (RWYUSE): Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and condition which runway(s) are for AI take off and landings based on the time of the day and wind conditions.<br />
<br />
<br />
<br />
= Traffic Schedules =<br />
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.<br />
<br />
In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircraft available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircraft will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.<br />
AI aircraft provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.<br />
<br />
To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.<br />
<br />
Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircraft do not time travel no teleport). <br />
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.<br />
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.<br />
<br />
It is recommended the traffic schedules follow as much as possible reality and so they should include turnaround time at each airport even if an AI aircraft does not require cleaning and refuelling.<br />
<br />
To facilitate scheduling, a new database format was introduced in FlightGear 1.9.0 and flights are no longer directly and rigidly assigned to a specific aircraft (Unique registration). 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.<br />
<br />
<br />
== An example of a traffic file ==<br />
<br />
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:<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCB</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<br />
<flight><br />
<callsign>KLM0765</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>0/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCM</port><br />
<time>0/21:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
<br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>TNCM</port><br />
<time>3/01:25:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>EHAM</port><br />
<time>3/10:50:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</trafficlist><br />
</syntaxhighlight><br />
<br />
== Dissecting the traffic file ==<br />
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.<br />
<br />
=== General layout ===<br />
The general layout of each file should look like the above example.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<br />
</trafficlist><br />
</syntaxhighlight><br />
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.<br />
<br />
=== Defining the aircraft ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
...<br />
</aircraft><br />
</trafficlist><br />
</syntaxhighlight><br />
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.<br />
<br />
* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.<br />
* '''<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 aircraft type ('''<actype>''') and paint scheme, but I abandoned that idea, because it didn't turn out to be very compatible with the existing FlightGear model loading code. <br />
* '''<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. <br />
* '''<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 in the routing algorithm. '''[New for Traffic Manager II]'''<br />
* '''<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]'''<br />
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].<br />
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are built 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.<br />
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.<br />
* '''<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:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''<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:<br />
** '''light_aircraft''' (General aviation prop driven single or twin),<br />
** '''turboprop_transport''' (Commercial Turboprop),<br />
** '''jet_transport''' (Commercial jet)<br />
** '''heavy_jet''' (Commercial jet w/ MTOW > 136tons)<br />
** '''ww2_fighter''' (world war two fighter),<br />
** '''jet_fighter''' (modern fighter aircraft)<br />
** '''tanker''' (tanker aircraft), or.<br />
** '''ufo''' (allows extreme accel/decel capabilities).<br />
* '''<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.<br />
* '''<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.<br />
<br />
=== Defining a flight ===<br />
The Traffic Manager II file formats contains separate sections for both aircraft 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:<br />
<syntaxhighlight lang="xml"><br />
<aircraft> <br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</aircraft><br />
<br />
<flight><br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</flight><br />
</syntaxhighlight><br />
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. <br />
<syntaxhighlight lang="xml"><br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>2/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCB</port><br />
<time>2/22:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</syntaxhighlight><br />
The '''<flight>''' 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:<br />
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.<br />
* '''<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''').<br />
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section. <br />
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.<br />
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<nowiki><time></nowiki>''' keywords.<br />
* '''<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. Values are in [https://en.wikipedia.org/wiki/Flight_level flightlevels]<br />
* '''<arrival>''' Same as '''<departure>''', but now defining the '''<port>''' and '''<nowiki><time></nowiki>''' of arrival.<br />
* '''<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.<br />
* '''<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. <br />
* '''<nowiki><time></nowiki>''' 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 unpredictable. Times should be in UTC. Weekdays start on Sunday (0) and end on Saturday (6).<br />
<br />
== Putting it all together: Including a traffic file ==<br />
Traffic files are found under [[$FG_ROOT]]/AI/Traffic. The actual traffic files should be stored in a subdirectory one level below /AI/Traffic.<br />
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.<br />
<br />
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 aircraft with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.<br />
<br />
= Ground networks =<br />
<br />
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircraft can park precisely at the Terminal gates]]<br />
<br />
Using the traffic files information above, the AI Traffic Manager knows which AI aircraft should land at (and take off from) each airport and when. It will automatically place the relevant aircraft models in the scenery and animate them so they navigate from the runways to the gates and vice versa, according to their individual schedule.<br />
<br />
Although the physical layout of each airport is stored in FlightGear's APT.DAT master file, the information is not accurate enough to determine which specific routes AI models can use; Instead, Traffic manager will rely on a dedicated file containing a simple wireframe/network of taxiways and gates AI aircraft can follow whilst on the ground ie a GroundNet. A groundnet is made of 3 different elements: Parking Positions, Nodes and Segments (to join nodes and Parking together). <br />
<br />
This routing information is aggregated, per airport, in a XML, stored and distributed by Terrasync as '''/Terrasync/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml''' where ICAO stands for the 4 letter ICAO code of the relevant airport.<br />
<br />
Similarly to Terrain and Objects, Terrasync groundnets can be overridden by placing a personalized version in your custom scenery folder, using the same path structure: /Custom Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.<br />
<br />
Groundnets are not mandatory but, in absence of this routing information, AI Aircraft cannot park anywhere; they will still try to stick to their schedule, appearing magically at the centre of the airport and taxiing directly to the runways’ thresholds, over grass, buildings and static objects, on time.<br />
<br />
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking. <br />
<br />
== A technical perspective ==<br />
A ground network xml file consists of four tables:<br />
* '''<frequencies>''' The Airport’s radio frequencies (Optional). As of v1.9.0, FlightGear uses these to display some ATC messages like start-up approval requests. You can "hear" them by tuning to the first ground frequency listed in the section.<br />
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircraft can use them.<br />
* '''<TaxiNodes>''' The list of all the nodes in the ground network.<br />
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.<br />
<br />
Each Parking and Node element in the groundnet has a unique index number, allowing routes be formed (from one ID to the next via a segment/arc) between parking positions and runways <br />
<br />
''Parking Positions Parameters:''<br />
* '''index''' Unique ID, internal to the file structure<br />
* '''lat''' latitude in decimal minutes format, for example <code>N50 56.988</code>)<br />
* '''lon''' longitude in decimal minutes format, for example <code>W01 21.756</code>)<br />
* '''name & number ''' (gate identification as found on airport charts, for example <code>D23</code> or <code>C1</code>). <br />
* '''type:''' The type of aircraft which can use this space. Matched to the <flighttype> parameter found in traffic files:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo/freighter)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''heading:''' The heading at which the aircraft parks in this space.<br />
* '''radius:''' The size of the parking spot. Matched to the aircraft <radius> parameter in traffic files to determine if a given AI Aircraft model will fit the position. See [[aircraft radii]]<br />
* '''airlineCodes:''' a comma-separated list of ICAO airline codes allowed to park at this gate. Matched to the aircraft <airline> parameter of traffic files. Leave blank for all airline to be able to use the gate.<br />
* '''pushBackRoute:''' The ID of the next node in the network along a pushback route. 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.<br />
<br />
''Nodes parameters:''<br />
<br />
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircraft waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear<br />
* '''holdPointType''' can have the following values:<br />
** '''None''' Not a holding point (normal taxi-through node) <br />
** '''PushBack''' The node marks the end of a pushback route, where the aircraft stops rolling backward and start rolling forward upon clearance. A pushback Holding Point can be part of more than one pushback route. See Pushback below. <br />
** '''Normal''' (Not yet supported): a regular taxiway holding point.<br />
** '''CAT II/III''' (Not yet supported): a special holding point for IFR conditions.<br />
<br />
''segments parameters:''<br />
<br />
* '''begin''' The id of the parking space or AINode where this segment starts<br />
* '''end''' The id of the parking space or AINode where this segment ends<br />
* '''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.<br />
* '''name''' Name of the taxiway.<br />
<br />
== Tools & Source Material ==<br />
Groundnets can be built using either FG Airports (v0.032 or later) or Taxidraw (legacy) <br />
<br />
[[FGAirports]] is the current tool of choice. Its philosophy is airport centered rather than file specific and allows you to visualize at a glance all of the existing groundnets as well as editing them and submitting them to Terrasync. It leverages Open Street Map data, APT.DAT and scenery xmls to provide a visual representation of the airport layout as well as thresholds and tower positions. <br />
<br />
FGA automatically checks the validity of groundnet files before submission and assess their adequacy by comparing the number of gates set against the volume of AI traffic at a particular airport.<br />
<br />
[[TaxiDraw]] pre dates WED and allowed the creation of airport layouts from basic geometrical shapes. Its ground network module is somewhat separate from the rest of the airport project code but allows the creation and local export of simple groundnets.<br />
<br />
See the [[TaxiDraw]] and [[FGAirports]] articles for instructions on how to obtain the tools and operating instructions.<br />
<br />
Most Civil Aviation authorities make electronic versions of their Aeronautical Information Publication available on the web (Lookup 'eAIP' or go to https://www.eurocontrol.int/articles/ais-online). AIPs contain precise Airport Charts but also lists of parking stands with their exact Latitude/Longitude as well as usage (Cargo, Gate) and the category (radii) of aircraft they can accommodate.<br />
<br />
Gates Numbers and Airlines operating them can often be found on Airports website. Most flight tracking sites/apps will also allow you to monitor a flight all to the way to its gate to identify who parks where.<br />
<br />
In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!<br />
<br />
== Ground traffic rendering ==<br />
''19th November 2021.''<br />
<br />
=== Performance ===<br />
<br />
* CPU: Currently having a lot of nodes in the OSG scene-graph will rapidly make FlightGear CPU bound. A lot of separately animated ground traffic objects mean a lot of nodes. Static objects (i.e. non-animated objects) can be put into one mesh - meaning one scenegraph node with the current system.<br />
* GPU: Having fewer draw calls is fast. Having fewer state changes is fast. <br />
* The fast path for both CPU and GPU is creating a way to combine multiple animated objects in one mesh - this is how modern 3d applications do lots of objects with animations fast.<br />
<br />
=== The fast way to do moving objects is to let the vertex shader look at information in buffers and position each object ===<br />
<br />
* Have all the different path segments stored in one buffer that can be read by the vertex shader. This buffer can be generated at runtime for each airport, maybe using NASAL scripts, and not updated.It's also possible to store the 1st buffer in TerraSync. <br />
* Have a second buffer store all per-object data in an array. The array is indexed by the object ID. This includes things like vehicle animation state, which path segment each object is on, the starting time, and a speed scaling factor. The second buffer is updated regularly by the CPU.<br />
* Two approaches to packing different types of objects in a 1 or few meshes <br />
**'''a).''' Every type of object is combined in one vertex buffer and rendered with the same shaders, texture atlas or array. Every vehicle is packed one after the other in the vertex buffers. Multiple types of vehicles are contained in the same mesh. Multiple instances of the same vehicle take up extra space. <br />
*** All material parameters or uniform values that change between objects, or within objects, like specularity are added as vertex attributes or textures. A vertex shader that can handle all object animations is used. <br />
*** The entire set of objects takes up one scene graph node, and is rendered in one draw call. It's possible to do ground vehicles and AI aircraft as two meshes.<br />
*** The object ID (an integer) can be added to each vertex as an vertex attribute. This is used to lookup per-object info in the 2nd buffer, including the paths from the first buffer.<br />
** '''b).''' Each different type of object (different ground vehicle) is instanced and takes up one scene-graph node. This can allow different shaders and textures per object type. There is less vertex data taking up RAM and VRAM. There are more scenegraph nodes, and draw calls.<br />
*** The object ID (an integer) can be added as a per-instance vertex attribute.<br />
* The vertex shader can trivially look at the object ID, then find the path segment, the starting time, speed scaling factor, and current time to position each object. If the current time is past the end of the current path, the object will stay at the end position.<br />
* The buffers can be a uniform array (minimum of points in each path segment and more smoothing), Uniform Buffer Object (UBO - not available until Vulkan due to Macs not supporting it), a Texture Buffer Object (TBO - Mac support unknown), or a texture looked up in a vertex shader (maybe slower).<br />
* Data format: Each path segment is x,y,z position at regular times - a time-series of positions - e.g. [10m, 20m, 0m elevation] at t = 1s. [20m, 25m, 0m] at t=2s . [30m, 30m, 0m] at t= 3s. 16 bit integers are enough, but 32 but floats can also be used at the cost of 2x the occupancy. 16 bit implementation: If a texture is used it can be 16bit RGB - R=x, G=y, B=z. 2 consecutive 8 bit values can also be read from a texture.16 bit integers can cover an ground traffic area of ~65km with a spacing of 1m. 16bits can give a ~13km ground traffic area with an accuracy of 20cm. The accuracy of the positions doesn't matter too much - the vertex shader can look at 2-3+ path positions and create a smooth interpolation (a smooth curve joining the points). The time steps can also be large. <br />
* If a path has a slowly moving segment, it will take up more points. If a path segment takes a short amount of time, it can have a special xyz numner to indicate path has ended - otherwise the path start/end time information can be stored as uniforms or in a UBO. Vehicles that move faster can have a higher speed scaling. There can be different path segment variations, for example if vehicles have a different acceleration pattern - e.g. speeding up and braking hard, or sharper turns, in an emergency.<br />
* Both ground vehicles, and taxiing aircraft can be done this way. It's possible to replace a conventional AI aircraft model, with a fast rendering ground traffic model once an aircraft starts taxiing.<br />
* If models use animations, they should ideally use a vertex shader that can handle all these animations - so having multiple draw calls per model and CPU-side animation is avoided.<br />
* It's possible to split of different parts of craft into separate meshes for parts that are very dissimilar - at the cost of more scenegraph nodes and draw calls. For example, a separate mesh for lights of various types - these lights will follow the same paths as the vechiles and position themselves correctly.<br />
* <br />
<br />
<br />
<br />
The way animation is handled (animation meaning moving objects, and parts of moving objects) in modern 3d application is to store the animation data in arrays/buffers on the GPU side and render multiple objects in one draw call.<br />
<br />
From a quick google search - a 2010 blog about whether UBOs or TBOs are more suited for different tasks:<br />
<br />
''"Personally I use them [UBOs] for instanced rendering by storing the model-view matrix and related information of each and every instance in a common uniform buffer and use the instance id as an index to this combined data structure. This usage performs very well on my system.''<br />
<br />
''Also uniform buffers can be used to store the matrices of bones and use them for implementing skeletal animation, however, I personally prefer using normal 2D textures for this purpose to take advantage of the free interpolation thanks to the dedicated texture fetching units but that’s another story.''<br />
<br />
''[..] Personally I use texture buffers for different geometry deformation techniques, to resolve batching issues when the size limitation of uniform buffers is a blocking factor, and for some inverse kinematics effects." - Rastergrid blog, 2010 [https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/][https://web.archive.org/web/20211119134448/https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/]''<br />
<br />
This is from a 2010 blog - this general approach has been the way to do lots of animated objects for a long time. <br />
<br />
Even really complicated animations like moving bodies and cloth physics are handled by moving animation data into buffers - this approach would be needed if FlightGear ever did a simulation of crowds at an airport - not just for boarding one plane which probably won't be too cripplingly slow. But for crowds boarding lots of planes, and moving about large airports. For animating humans, there are will be standard animation formats compatible with output of tools in blender or make human[http://www.makehumancommunity.org/]. This approach may also be worth while for rendering lots of seated passengers with really simple movements - and a few walking about with a simple walk cycle. It may also be justified for large amounts of ground personnel at big airports (not just a few relevant for the users plane).<br />
<br />
== Warnings and Limitations ==<br />
The complexity of building a fully functional groundnet (and the time spent on it) grows exponentially with the size of the airport but very small airports, on Pacific Islands for example, pose even larger challenges. An ideal project to start with is a Metropolitan airport with one or two runways, and two dozen of parking positions. <br />
<br />
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:<br />
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]<br />
* TM does not space landing aircraft. You will most likely see packs of landing aircraft hitting your runways at once, sometimes from both ends. Departures are spaced properly though <br />
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route. <br />
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied. <br />
* AI Aircraft cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight) <br />
<br />
* Groundnets, terrain and scenery objects are independent. If you see your AI aircraft rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.<br />
<br />
Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.<br />
<br />
Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircraft are handled. <br />
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.<br />
<br />
On the bright side, both Taxidraw and FG Airports contain a validation tool which will allow you to detect any structural problem with your groundnet. You will also find a lot of resources and tips in the AI section of the Flightgear forums.<br />
<br />
Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.<br />
[[File:Gate Definition in FG Airports.png|300px|thumb|FG Airports UI for Parking Position]]<br />
== Creating the base network == <br />
<br />
Objective:<br />
* You have enough gates for all AI aircraft using the airport<br />
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet<br />
* Each Runway(s) threshold has a unique link to the rest of the groundnet<br />
* Departing Aircraft can reach any threshold, from any parking position <br />
* Arriving Aircraft can reach any suitable parking position from any threshold<br />
<br />
<br />
'''Step 1 : Place and configure the Parking Positions'''<br />
<br />
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.<br />
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]] <br />
AI Aircraft will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.<br />
<br />
Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters. <br />
Military and General Aviation can also be used if you are running personalized traffic files on your machine.<br />
<br />
Adjust the heading and radius for each of your gates according to the maximum wingspan the stand can accommodate. See [[aircraft radii]]. <br />
Set a unique name for the gate.<br />
Leave the AIRLINE field empty at this point.<br />
<br />
'''Step 2 : Place and configure the Runway accesses'''<br />
<br />
AI aircraft need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.<br />
<br />
At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).<br />
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.<br />
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircraft will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.<br />
<br />
Backtracking: Certain airports do not have taxiways along the runway and aircraft will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].<br />
<br />
Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.<br />
[[File:Multiple Route leading to a single Threshold.png|thumb|Runway access routes must be unique]]<br />
Your access route must be unique: Traffic manager does not handle intersections (nodes with 4 routes) very well. Your take off points should not be connected to more than one route (case of taxiways on both sides of the runway feeding a single take off point from both sides as shown on the right.<br />
<br />
Select each of the nodes placed on the physical runway (not the ones leading to it) and mark them "On Runway" with the toggle in their properties panel <br />
<br />
'''Step 3 : Connect ParPos and Runway Access routes to form the groundnet.''' <br />
<br />
Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.<br />
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircraft as many routing options as possible.<br />
<br />
Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.<br />
<br />
Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircraft park straight and leave their parking straight (rolling forward or pushing back).<br />
<br />
Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircraft. In essence draw just enough routes so that all gates and runways are connected.<br />
<br />
'''Step 4 : Visual Check'''<br />
Once your base groundnet complete, Check visually that your parking positions do not overlap, that nodes placed on physical runways are marked as such and that intersections are formed properly (no node unless the aircraft can turn here)<br />
<br />
'''Step 5 : Structural Check and Test'''<br />
<br />
Run the verification tool (available in both Taxidraw and FGAirports). Both programs will ensure at this stage that routes are valid and that nodes on runway are marked as such. <br />
Taxidraw does not check the routes structures individually but rather that a route solution exist: If an aircraft can use different path/routes to go from its ParkPos to a given runway threshold and even if one of these routes is "broken" (unconnected segments) no error will be reported, because the aircraft could use another (unbroken) route to get to the threshold and hence still has a routing solution.<br />
<br />
FGAirports will do the same routing check but will also signal any unconnected node (broken routes). <br />
Correct the errors found and re run the verification tools until no more problems are found.<br />
<br />
Time to test with 'real' traffic. Save your groundnet and export it to a custom scenery folder (NOT to the Terrasync Folder), usually something like F:\My Sceneries\Airports\S\B\SBGR.groundnet.xml.<br />
Startup Flightgear and add your custom scenery folder path (the parent of \Airports) to your extra sceneries list in the Add On screen. Select your Airport as Startup Location. Run <br />
<br />
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]] <br />
* Parked aircraft will start appearing on the parking stands you have set. Departing aircraft will light up (red/green nav lights on wing tips, flashing beacon on top)<br />
* Upon ATC clearance (automatic) Departing aircraft will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.<br />
* Departing Aircraft will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off<br />
* Arriving aircraft will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off<br />
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircraft following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.<br />
* Aircraft will taxi from both directions on single taxiways, eventually passing through each other<br />
* On larger airports where AI aircraft can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier. <br />
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)<br />
* No aircraft (no AI traffic at this airport or not activated in FG options)<br />
* Aircraft queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)<br />
<br />
<br />
=== Refining the network: Routing Flow & Baggage Carousels Belts === <br />
<br />
Objective:<br />
* All Objectives in the "Creating the base Network" section<br />
* No clogging at intersections<br />
* No Head on crashes of aircraft sharing a single taxiway<br />
<br />
The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircraft will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.<br />
<br />
You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes: <br />
* AI traffic cannot make decisions: Typically, where presented with multiple routing options (an X intersection with 4 or more valid routes), AI traffic will consistently freeze/clog after some time if not immediately.<br />
* AI traffic does not stand bullying: If presented with no alternative at all (too many unidirectional routes) AI traffic will move away from your groundnet taxiways and start mowing the lawns. <br />
<br />
<br />
[[File:Groundnet Routing Flow Example.png|border|right|950px|Groundnet Routing Flow Example]]<br />
Keeping these two constraints in mind, the clogging and head on collisions noted in your previous tests can be addressed by setting up a ‘Routing Flow’. The purpose of said routing is to guide each aircraft to their final destination (Parking or Threshold), by ensuring it uses a single route and never crosses any other aircraft path.<br />
To achieve this we only have and need two tools: The ability to force the direction of traffic on any given segment (by making it “unidirectional”) and the ability of Traffic manager to handle priorities and queues formation at routes merging points (Y shaped intersections).<br />
<br />
The complexity of Routing Flow will increase exponentially with the number of gates, thresholds and traffic files handled: A single groundnet flow must accommodate indifferently a cargo flight arriving on RWY 1 in the evening or a commuter departing from RWY 2 in the morning.<br />
<br />
To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel. <br />
That is all bags (Aircraft) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).<br />
<br />
An advantage AI aircraft have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.<br />
<br />
Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.<br />
<br />
[[File:Apron Belt at Bahrein Intl.png|left|thumb|Using the Belt technique to feed the OBBI apron]] <br />
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.<br />
<br />
The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircraft to move from one belt to the other.<br />
<br />
You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.<br />
<br />
Certain smaller airports do not have enough taxiways to allow the formation of a proper global belt but the technique can be used on individual aprons to ensure proper flow in and out of parking areas and simplify the design of pushback routes (next section) as shown on the image on the left, at Bahrein Intl.<br />
<br />
Testing : Once your routing flows in place you should re-test you groundnet. The expected behaviour is the same then the one described in the “Base Network, Step 5” section, with the exception of head on collisions and clogged intersections which should no longer exist<br />
<br />
<br />
=== Refining the network: Pushback routes ===<br />
<br />
'''THIS SECTION IS WIP'''<br />
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. Pushback routes are optional (if you like the terminal crashing scenario described above).<br />
<br />
'''Examples of simple valid pushback routes''' (Left: If the taxiway is bidirectional | Centre: If the taxiway is not bidirectional | Right: With shared Pushback Holding point)<br />
<br />
[[File:MultiDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid AI Groudnet pushback for multi directional taxiway]] <br />
[[File:UniDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid Pushback Route on Un directional taxiway]]<br />
[[File:Shared Pushback Holding Point in Taxidraw.jpg|400px|Shared Pushback Holding Point]] <br />
<br />
[[File:Roll Forward Gate in Taxidraw.jpg|thumb|Invalid Park Pos Exist route : at and angle with Parking Position]]<br />
===== Pushback Holding Points must be unique per Parking Position =====<br />
<br />
Each Parking space (ParkPos) can't have more than one push back route and one pushback holding point at the end of the route. Nevertheless, multiple Parkpos can share part of their pushback routes and a single Pushback Holding Point.<br />
<br />
The formal criteria for a valid push back route is that each gate should have a maximum of one push back holding point associated with it, which can be reached using one route only.<br />
From an editing point of view, mark all segments between your parking position and its final holding point as "push back", do not forget to mark the ending node as Pushback Holding Point.<br />
<br />
===== The AI code does not handle sharp angles =====<br />
<br />
Add nodes to smoothen your routes so that no consecutive segments form an angle of less than 90 degrees. <br />
This rule applies to both pushback and roll forward / taxiways routes <br />
<br />
===== The Inbound route and the outbound routes are parallel ===== <br />
[[File:On Taxiway Pushback Holding Point in Taxidraw.jpg|thumb|Invalid Groudnet Pushback : Holding Point on Taxiway]]<br />
<br />
The last segment of the pushback route will condition the aircraft heading:<br />
<br />
1. During its travel along the pushback route <br />
<br />
2. At the Pushback Holding point (whilst waiting for clearance)<br />
<br />
3. On departing the pushback holding point, rolling forward to the runway.<br />
<br />
<br />
You can not control/force an AI aircraft to leave a Pushback Holding point at a different angle/heading than the one it came onto its final holding node at, whatever the number of routes you add.<br />
<br />
As a result, the last segment of the pushback route must align with the segment you expect the aircraft to use when starting to roll forward after clearance. The simpler set up is to have this final pushback segment overlapping the first segment of the roll forward route.<br />
<br />
Alternatively, the last segment of the pushback route can -itself- be the first segment of the roll forward route but this means Traffic Manager will consider this segment 'reserved' whilst the aircraft is pushing back and no other aircraft will be able to use the taxiway.<br />
<br />
For the same reason the Pushback Holding point should NOT be directly placed on the taxiway as shown in the image on the right 'On Taxiway Pushback Holding Point in Taxidraw'.<br />
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to. <br />
<br />
The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircraft which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI <br />
<br />
<br />
It is important to note that the Taxidraw "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 with all aircraft from one side of the E terminal are being linked to one shared push back point. <br />
<br />
Given the current push back system allows for fairly complicated behavior it is advisable to test extensively your groundnet and play with various configurations before sharing it to the community. <br />
<br />
Taxidraw note: TaxiDraw versions prior to February 5, 2009 did export the pushBackRoute attribute correctly. <br />
<br />
[[File:TaxiDraw2.png|thumb]]<br />
<br />
==== Verifying the network ====<br />
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. <br />
<br />
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.<br />
<br />
* '''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.<br />
* '''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. <br />
* '''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. <br />
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.<br />
<br />
=== Copying the ground network into FlightGear's scenery directory ===<br />
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>.<br />
<br />
In Taxidraw menu select File, Export AI Network and save the file in the above folde as ICAO.groundnet.xml. Please note that the File / Save project menu applies only to the airport layout and does NOT save your groundnet.<br />
<br />
=== Testing the network ===<br />
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. <br />
<br />
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.<br />
<br />
=== Airports with ground networks ===<br />
<br />
== Collision Detection == <br />
<br />
Version 2024.1.X and all version prior use an avoidance strategy based on the ground network. This means there are lots of Dijkstra calls to determine the possible route to the runway. Another implication is that the designer of the ground network must ensure the separation. This is of course not possible in pushback or even with the user aircraft. <br />
The next version will get real detection of nearness and integration with ATC. This is based on a Quadtree and just reacts on the current snapshot and not on "future" plans of an aircraft. <br />
<br />
=== Nearness rose ===<br />
[[File:Ai-windrose.png|thumb|A diagram showing an aircraft and different szenarios based on heading|none]]<br />
<br />
This diagram shows some possible angles of approach with the aircraft pointing away.<br />
<br />
[[File:Ai-windrose-approach.png|thumb|A diagram showing an aircraft and different szenarios based on heading]]<br />
<br />
This diagram shows some possible angles of approach with the aircraft pointing towards.<br />
<br />
=== Braking ===<br />
[[File:Following slowdown.png|thumb|A diagram showing the braking of a following aircraft|none]]<br />
<br />
When following aircraft must brake in a plausible way.<br />
<br />
= Runway Usage Configuration = <br />
<br />
ICAO.rwyuse.XML dictates which runway(s) should be used for AI take off and which ones accept AI landings. These instructions are organised in multiple sets (or configurations) and ordered by preference of use.<br />
<br />
Schedules can be defined so different runway configurations can be used at different time of the day. Different Sets can also be applied to the General Aviation and Commercial traffic.<br />
<br />
Each set of runway configuration is tested against the wind conditions and applies only if the crosswind and tailwind are within tolerance. If not, the next set in the order of preference, will be picked.<br />
<br />
Examples below taken from the Amsterdam Schiphol EHAM.rwyuse.xml file.<br />
<br />
Wind conditions are stored at the beginning of the file and indicate the maximum values of Crosswind and Tailwind acceptable to authorize take off and landing at the airport.<br />
<br />
<syntaxhighlight lang="xml"><br />
<wind tail="7"<br />
cross="20" /><br />
</syntaxhighlight><br />
<br />
{{quote|As well as aircraft, airports have operational crosswind and tailwind limits. [] The values vary but crosswind limits are normally 15-25 kts and tailwinds are normally no more than 10 kts.|ICAO|AMOFSG/10-SN No. 14}}<br />
<br />
The < time > table defines the hours of activation for a particular Schedule. Each schedule contains a 'Pattern' ie a fixed number of runways allocated to either take off or landing).<br />
<br />
For instance, at EHAM, the commercial "inbound" schedule is active from 06:20 to 08h30 UTC, at a time where there is more inbound than outbound traffic and the airport needs to allocate more runways to landing than to take off.<br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "06:20"<br />
end = "08:30"<br />
schedule = "inbound"/><br />
</syntaxhighlight><br />
<br />
In most cases, a single schedule can apply 24h every day. <br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "00:00"<br />
end = "24:00"<br />
schedule = "Day"/><br />
</syntaxhighlight><br />
<br />
<br />
The different sets of runways allocation are listed in each < schedule > table by order of preference and can be read/deciphered vertically as ”columns” delimited by commas.<br />
<br />
When wind conditions do not allow the use of a set, the next one will apply (next “column”).<br />
<br />
Still using the EHAM.rwyuse.xml file as example, from 06:20 to 08:30 UTC, when the Inbound schedule applies; AI traffic will preferably use runway 36L for take-offs, and both 06 and 36R for landings (first “column” of data).<br />
<br />
<syntaxhighlight lang="xml"><br />
<schedule name="inbound"><br />
<takeoff>36L, 24, 18L, 36L, 24, 24, 18L, 09</takeoff><br />
<landing>06, 18R, 18R, 36R, 27, 18R, 18R, 06</landing><br />
<landing>36R, 18C, 18C, 36C, 18R, 22, 22, 09</landing><br />
</schedule><br />
</syntaxhighlight><br />
<br />
Shall wind conditions prevent the use of this configuration (Tailwind or Crosswind values exeeding the ones defined in <wind> above), the next set (or “column”) will apply ie 24 for take-offs, and 18R + 18C for landings.<br />
<br />
Again, if wind conditions prevent this configuration use, the next set will be used (18L for take-offs, 18R and 18C for landing).<br />
<br />
This test of runway sets against wind values will continue with the rest of the sets in the schedule until a valid one is found and applied.<br />
<br />
It is necessary for each of the <takeoff> and <landing> entries to have an equal number of runway values, per schedule, so each set contains the same number of runways.<br />
<br />
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAMbEsE46ontK4G43zmrEqLEk%3D8ZK5sQ-vxZup%3DNjpaUDgb-ASw%40mail.gmail.com/#msg37166996 Source from Durk post in Devel]<br />
<br />
<br />
= Model Animation =<br />
<br />
To assist with creating realistic aircraft behaviour, some properties are set by the Traffic Manager during particular flight phases as follows<br />
<br />
{| class="wikitable"<br />
|-<br />
! Property !! Description !! Type !! At Gate !! Taxiing !! Take-off !! Cruise !! Approach and Landing<br />
|-<br />
| gear/gear[0..5]/position-norm || Gear Position || double (interpolated over 10 seconds || 1.0 || 1.0 || 0.0 (above 400ft) || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| surface-positions/flap-pos-norm || Flaps position || double (interpolated over 20 seconds || 0.0 || 0.0 || 0.5 (below 2000ft) || 0.0 || 1.0 ( below 2000ft)<br />
|-<br />
| surface-positions/spoiler-pos-norm || Spoiler position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (on runway)<br />
|-<br />
| surface-positions/speedbrake-pos-norm || Speedbrake position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| controls/lighting/beacon || Beacon || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/cabin-lights || Cabin lights || bool || true || true || true || false || false<br />
|-<br />
| controls/lighting/landing-lights || Landing lights || bool || false || false || false || true || true<br />
|-<br />
| controls/lighting/nav-lights || Navigation lights || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/strobe || Strobes || bool || false || false || true || true || true<br />
|-<br />
| controls/lighting/taxi-lights || Taxi lights || bool || false || true || false || false || false<br />
|}<br />
<br />
= SIDs / STARs =<br />
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 flight path, 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 way points. <br />
<br />
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-concept data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of this data. Note that this data is meant to be just that; a proof-of-concept. User contributions will be accepted as soon as the format has stabilized.<br />
<br />
= Appendix: Special Notes =<br />
<br />
<br />
== Performance ==<br />
With recent versions of FlightGear, we have much better performance than before 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. <br />
<br />
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.<br />
<br />
= Related content =<br />
* [[Airports with ground networks]]<br />
* [[FGAirports]] - A groundnet editor<br />
* [[Flightplan XML formats]]<br />
* [[Status of AI in FlightGear]]<br />
<br />
<br />
[[de:Interaktiver Verkehr]]<br />
<br />
[[Category:AI Traffic]]<br />
[[Category:FlightGear feature]]<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=File:Ai-windrose-approach.png&diff=141263File:Ai-windrose-approach.png2025-01-22T14:14:57Z<p>Portreekid: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=A diagram showing an aircraft and different szenarios based on heading}}<br />
|date=2025-01-22<br />
|source={{own}}<br />
|author=[[User:Portreekid|Portreekid]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-4.0}}<br />
<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=AI_Traffic&diff=141261AI Traffic2025-01-21T13:34:27Z<p>Portreekid: /* Collision Detection */</p>
<hr />
<div>{{AI Navbar}}<br />
<br />
'''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic.<br />
<br />
In essence, the AI controlled traffic system is comprised of four elements: <br />
# AI Aircraft models: Are part of the base package under <tt>$DATA/AI/Aircraft</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. <br />
# AI traffic schedules: Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircraft should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> <br />
# Groundnets: Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircraft on the ground from gates to runways and vice versa, at each individual airport (one per airport). The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.<br />
# Runway Use Configurations (RWYUSE): Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and condition which runway(s) are for AI take off and landings based on the time of the day and wind conditions.<br />
<br />
<br />
<br />
= Traffic Schedules =<br />
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.<br />
<br />
In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircraft available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircraft will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.<br />
AI aircraft provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.<br />
<br />
To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.<br />
<br />
Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircraft do not time travel no teleport). <br />
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.<br />
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.<br />
<br />
It is recommended the traffic schedules follow as much as possible reality and so they should include turnaround time at each airport even if an AI aircraft does not require cleaning and refuelling.<br />
<br />
To facilitate scheduling, a new database format was introduced in FlightGear 1.9.0 and flights are no longer directly and rigidly assigned to a specific aircraft (Unique registration). 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.<br />
<br />
<br />
== An example of a traffic file ==<br />
<br />
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:<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCB</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<br />
<flight><br />
<callsign>KLM0765</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>0/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCM</port><br />
<time>0/21:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
<br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>TNCM</port><br />
<time>3/01:25:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>EHAM</port><br />
<time>3/10:50:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</trafficlist><br />
</syntaxhighlight><br />
<br />
== Dissecting the traffic file ==<br />
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.<br />
<br />
=== General layout ===<br />
The general layout of each file should look like the above example.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<br />
</trafficlist><br />
</syntaxhighlight><br />
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.<br />
<br />
=== Defining the aircraft ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
...<br />
</aircraft><br />
</trafficlist><br />
</syntaxhighlight><br />
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.<br />
<br />
* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.<br />
* '''<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 aircraft type ('''<actype>''') and paint scheme, but I abandoned that idea, because it didn't turn out to be very compatible with the existing FlightGear model loading code. <br />
* '''<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. <br />
* '''<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 in the routing algorithm. '''[New for Traffic Manager II]'''<br />
* '''<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]'''<br />
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].<br />
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are built 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.<br />
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.<br />
* '''<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:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''<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:<br />
** '''light_aircraft''' (General aviation prop driven single or twin),<br />
** '''turboprop_transport''' (Commercial Turboprop),<br />
** '''jet_transport''' (Commercial jet)<br />
** '''heavy_jet''' (Commercial jet w/ MTOW > 136tons)<br />
** '''ww2_fighter''' (world war two fighter),<br />
** '''jet_fighter''' (modern fighter aircraft)<br />
** '''tanker''' (tanker aircraft), or.<br />
** '''ufo''' (allows extreme accel/decel capabilities).<br />
* '''<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.<br />
* '''<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.<br />
<br />
=== Defining a flight ===<br />
The Traffic Manager II file formats contains separate sections for both aircraft 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:<br />
<syntaxhighlight lang="xml"><br />
<aircraft> <br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</aircraft><br />
<br />
<flight><br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</flight><br />
</syntaxhighlight><br />
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. <br />
<syntaxhighlight lang="xml"><br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>2/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCB</port><br />
<time>2/22:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</syntaxhighlight><br />
The '''<flight>''' 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:<br />
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.<br />
* '''<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''').<br />
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section. <br />
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.<br />
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<nowiki><time></nowiki>''' keywords.<br />
* '''<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. Values are in [https://en.wikipedia.org/wiki/Flight_level flightlevels]<br />
* '''<arrival>''' Same as '''<departure>''', but now defining the '''<port>''' and '''<nowiki><time></nowiki>''' of arrival.<br />
* '''<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.<br />
* '''<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. <br />
* '''<nowiki><time></nowiki>''' 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 unpredictable. Times should be in UTC. Weekdays start on Sunday (0) and end on Saturday (6).<br />
<br />
== Putting it all together: Including a traffic file ==<br />
Traffic files are found under [[$FG_ROOT]]/AI/Traffic. The actual traffic files should be stored in a subdirectory one level below /AI/Traffic.<br />
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.<br />
<br />
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 aircraft with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.<br />
<br />
= Ground networks =<br />
<br />
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircraft can park precisely at the Terminal gates]]<br />
<br />
Using the traffic files information above, the AI Traffic Manager knows which AI aircraft should land at (and take off from) each airport and when. It will automatically place the relevant aircraft models in the scenery and animate them so they navigate from the runways to the gates and vice versa, according to their individual schedule.<br />
<br />
Although the physical layout of each airport is stored in FlightGear's APT.DAT master file, the information is not accurate enough to determine which specific routes AI models can use; Instead, Traffic manager will rely on a dedicated file containing a simple wireframe/network of taxiways and gates AI aircraft can follow whilst on the ground ie a GroundNet. A groundnet is made of 3 different elements: Parking Positions, Nodes and Segments (to join nodes and Parking together). <br />
<br />
This routing information is aggregated, per airport, in a XML, stored and distributed by Terrasync as '''/Terrasync/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml''' where ICAO stands for the 4 letter ICAO code of the relevant airport.<br />
<br />
Similarly to Terrain and Objects, Terrasync groundnets can be overridden by placing a personalized version in your custom scenery folder, using the same path structure: /Custom Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.<br />
<br />
Groundnets are not mandatory but, in absence of this routing information, AI Aircraft cannot park anywhere; they will still try to stick to their schedule, appearing magically at the centre of the airport and taxiing directly to the runways’ thresholds, over grass, buildings and static objects, on time.<br />
<br />
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking. <br />
<br />
== A technical perspective ==<br />
A ground network xml file consists of four tables:<br />
* '''<frequencies>''' The Airport’s radio frequencies (Optional). As of v1.9.0, FlightGear uses these to display some ATC messages like start-up approval requests. You can "hear" them by tuning to the first ground frequency listed in the section.<br />
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircraft can use them.<br />
* '''<TaxiNodes>''' The list of all the nodes in the ground network.<br />
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.<br />
<br />
Each Parking and Node element in the groundnet has a unique index number, allowing routes be formed (from one ID to the next via a segment/arc) between parking positions and runways <br />
<br />
''Parking Positions Parameters:''<br />
* '''index''' Unique ID, internal to the file structure<br />
* '''lat''' latitude in decimal minutes format, for example <code>N50 56.988</code>)<br />
* '''lon''' longitude in decimal minutes format, for example <code>W01 21.756</code>)<br />
* '''name & number ''' (gate identification as found on airport charts, for example <code>D23</code> or <code>C1</code>). <br />
* '''type:''' The type of aircraft which can use this space. Matched to the <flighttype> parameter found in traffic files:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo/freighter)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''heading:''' The heading at which the aircraft parks in this space.<br />
* '''radius:''' The size of the parking spot. Matched to the aircraft <radius> parameter in traffic files to determine if a given AI Aircraft model will fit the position. See [[aircraft radii]]<br />
* '''airlineCodes:''' a comma-separated list of ICAO airline codes allowed to park at this gate. Matched to the aircraft <airline> parameter of traffic files. Leave blank for all airline to be able to use the gate.<br />
* '''pushBackRoute:''' The ID of the next node in the network along a pushback route. 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.<br />
<br />
''Nodes parameters:''<br />
<br />
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircraft waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear<br />
* '''holdPointType''' can have the following values:<br />
** '''None''' Not a holding point (normal taxi-through node) <br />
** '''PushBack''' The node marks the end of a pushback route, where the aircraft stops rolling backward and start rolling forward upon clearance. A pushback Holding Point can be part of more than one pushback route. See Pushback below. <br />
** '''Normal''' (Not yet supported): a regular taxiway holding point.<br />
** '''CAT II/III''' (Not yet supported): a special holding point for IFR conditions.<br />
<br />
''segments parameters:''<br />
<br />
* '''begin''' The id of the parking space or AINode where this segment starts<br />
* '''end''' The id of the parking space or AINode where this segment ends<br />
* '''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.<br />
* '''name''' Name of the taxiway.<br />
<br />
== Tools & Source Material ==<br />
Groundnets can be built using either FG Airports (v0.032 or later) or Taxidraw (legacy) <br />
<br />
[[FGAirports]] is the current tool of choice. Its philosophy is airport centered rather than file specific and allows you to visualize at a glance all of the existing groundnets as well as editing them and submitting them to Terrasync. It leverages Open Street Map data, APT.DAT and scenery xmls to provide a visual representation of the airport layout as well as thresholds and tower positions. <br />
<br />
FGA automatically checks the validity of groundnet files before submission and assess their adequacy by comparing the number of gates set against the volume of AI traffic at a particular airport.<br />
<br />
[[TaxiDraw]] pre dates WED and allowed the creation of airport layouts from basic geometrical shapes. Its ground network module is somewhat separate from the rest of the airport project code but allows the creation and local export of simple groundnets.<br />
<br />
See the [[TaxiDraw]] and [[FGAirports]] articles for instructions on how to obtain the tools and operating instructions.<br />
<br />
Most Civil Aviation authorities make electronic versions of their Aeronautical Information Publication available on the web (Lookup 'eAIP' or go to https://www.eurocontrol.int/articles/ais-online). AIPs contain precise Airport Charts but also lists of parking stands with their exact Latitude/Longitude as well as usage (Cargo, Gate) and the category (radii) of aircraft they can accommodate.<br />
<br />
Gates Numbers and Airlines operating them can often be found on Airports website. Most flight tracking sites/apps will also allow you to monitor a flight all to the way to its gate to identify who parks where.<br />
<br />
In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!<br />
<br />
== Ground traffic rendering ==<br />
''19th November 2021.''<br />
<br />
=== Performance ===<br />
<br />
* CPU: Currently having a lot of nodes in the OSG scene-graph will rapidly make FlightGear CPU bound. A lot of separately animated ground traffic objects mean a lot of nodes. Static objects (i.e. non-animated objects) can be put into one mesh - meaning one scenegraph node with the current system.<br />
* GPU: Having fewer draw calls is fast. Having fewer state changes is fast. <br />
* The fast path for both CPU and GPU is creating a way to combine multiple animated objects in one mesh - this is how modern 3d applications do lots of objects with animations fast.<br />
<br />
=== The fast way to do moving objects is to let the vertex shader look at information in buffers and position each object ===<br />
<br />
* Have all the different path segments stored in one buffer that can be read by the vertex shader. This buffer can be generated at runtime for each airport, maybe using NASAL scripts, and not updated.It's also possible to store the 1st buffer in TerraSync. <br />
* Have a second buffer store all per-object data in an array. The array is indexed by the object ID. This includes things like vehicle animation state, which path segment each object is on, the starting time, and a speed scaling factor. The second buffer is updated regularly by the CPU.<br />
* Two approaches to packing different types of objects in a 1 or few meshes <br />
**'''a).''' Every type of object is combined in one vertex buffer and rendered with the same shaders, texture atlas or array. Every vehicle is packed one after the other in the vertex buffers. Multiple types of vehicles are contained in the same mesh. Multiple instances of the same vehicle take up extra space. <br />
*** All material parameters or uniform values that change between objects, or within objects, like specularity are added as vertex attributes or textures. A vertex shader that can handle all object animations is used. <br />
*** The entire set of objects takes up one scene graph node, and is rendered in one draw call. It's possible to do ground vehicles and AI aircraft as two meshes.<br />
*** The object ID (an integer) can be added to each vertex as an vertex attribute. This is used to lookup per-object info in the 2nd buffer, including the paths from the first buffer.<br />
** '''b).''' Each different type of object (different ground vehicle) is instanced and takes up one scene-graph node. This can allow different shaders and textures per object type. There is less vertex data taking up RAM and VRAM. There are more scenegraph nodes, and draw calls.<br />
*** The object ID (an integer) can be added as a per-instance vertex attribute.<br />
* The vertex shader can trivially look at the object ID, then find the path segment, the starting time, speed scaling factor, and current time to position each object. If the current time is past the end of the current path, the object will stay at the end position.<br />
* The buffers can be a uniform array (minimum of points in each path segment and more smoothing), Uniform Buffer Object (UBO - not available until Vulkan due to Macs not supporting it), a Texture Buffer Object (TBO - Mac support unknown), or a texture looked up in a vertex shader (maybe slower).<br />
* Data format: Each path segment is x,y,z position at regular times - a time-series of positions - e.g. [10m, 20m, 0m elevation] at t = 1s. [20m, 25m, 0m] at t=2s . [30m, 30m, 0m] at t= 3s. 16 bit integers are enough, but 32 but floats can also be used at the cost of 2x the occupancy. 16 bit implementation: If a texture is used it can be 16bit RGB - R=x, G=y, B=z. 2 consecutive 8 bit values can also be read from a texture.16 bit integers can cover an ground traffic area of ~65km with a spacing of 1m. 16bits can give a ~13km ground traffic area with an accuracy of 20cm. The accuracy of the positions doesn't matter too much - the vertex shader can look at 2-3+ path positions and create a smooth interpolation (a smooth curve joining the points). The time steps can also be large. <br />
* If a path has a slowly moving segment, it will take up more points. If a path segment takes a short amount of time, it can have a special xyz numner to indicate path has ended - otherwise the path start/end time information can be stored as uniforms or in a UBO. Vehicles that move faster can have a higher speed scaling. There can be different path segment variations, for example if vehicles have a different acceleration pattern - e.g. speeding up and braking hard, or sharper turns, in an emergency.<br />
* Both ground vehicles, and taxiing aircraft can be done this way. It's possible to replace a conventional AI aircraft model, with a fast rendering ground traffic model once an aircraft starts taxiing.<br />
* If models use animations, they should ideally use a vertex shader that can handle all these animations - so having multiple draw calls per model and CPU-side animation is avoided.<br />
* It's possible to split of different parts of craft into separate meshes for parts that are very dissimilar - at the cost of more scenegraph nodes and draw calls. For example, a separate mesh for lights of various types - these lights will follow the same paths as the vechiles and position themselves correctly.<br />
* <br />
<br />
<br />
<br />
The way animation is handled (animation meaning moving objects, and parts of moving objects) in modern 3d application is to store the animation data in arrays/buffers on the GPU side and render multiple objects in one draw call.<br />
<br />
From a quick google search - a 2010 blog about whether UBOs or TBOs are more suited for different tasks:<br />
<br />
''"Personally I use them [UBOs] for instanced rendering by storing the model-view matrix and related information of each and every instance in a common uniform buffer and use the instance id as an index to this combined data structure. This usage performs very well on my system.''<br />
<br />
''Also uniform buffers can be used to store the matrices of bones and use them for implementing skeletal animation, however, I personally prefer using normal 2D textures for this purpose to take advantage of the free interpolation thanks to the dedicated texture fetching units but that’s another story.''<br />
<br />
''[..] Personally I use texture buffers for different geometry deformation techniques, to resolve batching issues when the size limitation of uniform buffers is a blocking factor, and for some inverse kinematics effects." - Rastergrid blog, 2010 [https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/][https://web.archive.org/web/20211119134448/https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/]''<br />
<br />
This is from a 2010 blog - this general approach has been the way to do lots of animated objects for a long time. <br />
<br />
Even really complicated animations like moving bodies and cloth physics are handled by moving animation data into buffers - this approach would be needed if FlightGear ever did a simulation of crowds at an airport - not just for boarding one plane which probably won't be too cripplingly slow. But for crowds boarding lots of planes, and moving about large airports. For animating humans, there are will be standard animation formats compatible with output of tools in blender or make human[http://www.makehumancommunity.org/]. This approach may also be worth while for rendering lots of seated passengers with really simple movements - and a few walking about with a simple walk cycle. It may also be justified for large amounts of ground personnel at big airports (not just a few relevant for the users plane).<br />
<br />
== Warnings and Limitations ==<br />
The complexity of building a fully functional groundnet (and the time spent on it) grows exponentially with the size of the airport but very small airports, on Pacific Islands for example, pose even larger challenges. An ideal project to start with is a Metropolitan airport with one or two runways, and two dozen of parking positions. <br />
<br />
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:<br />
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]<br />
* TM does not space landing aircraft. You will most likely see packs of landing aircraft hitting your runways at once, sometimes from both ends. Departures are spaced properly though <br />
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route. <br />
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied. <br />
* AI Aircraft cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight) <br />
<br />
* Groundnets, terrain and scenery objects are independent. If you see your AI aircraft rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.<br />
<br />
Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.<br />
<br />
Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircraft are handled. <br />
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.<br />
<br />
On the bright side, both Taxidraw and FG Airports contain a validation tool which will allow you to detect any structural problem with your groundnet. You will also find a lot of resources and tips in the AI section of the Flightgear forums.<br />
<br />
Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.<br />
[[File:Gate Definition in FG Airports.png|300px|thumb|FG Airports UI for Parking Position]]<br />
== Creating the base network == <br />
<br />
Objective:<br />
* You have enough gates for all AI aircraft using the airport<br />
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet<br />
* Each Runway(s) threshold has a unique link to the rest of the groundnet<br />
* Departing Aircraft can reach any threshold, from any parking position <br />
* Arriving Aircraft can reach any suitable parking position from any threshold<br />
<br />
<br />
'''Step 1 : Place and configure the Parking Positions'''<br />
<br />
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.<br />
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]] <br />
AI Aircraft will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.<br />
<br />
Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters. <br />
Military and General Aviation can also be used if you are running personalized traffic files on your machine.<br />
<br />
Adjust the heading and radius for each of your gates according to the maximum wingspan the stand can accommodate. See [[aircraft radii]]. <br />
Set a unique name for the gate.<br />
Leave the AIRLINE field empty at this point.<br />
<br />
'''Step 2 : Place and configure the Runway accesses'''<br />
<br />
AI aircraft need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.<br />
<br />
At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).<br />
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.<br />
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircraft will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.<br />
<br />
Backtracking: Certain airports do not have taxiways along the runway and aircraft will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].<br />
<br />
Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.<br />
[[File:Multiple Route leading to a single Threshold.png|thumb|Runway access routes must be unique]]<br />
Your access route must be unique: Traffic manager does not handle intersections (nodes with 4 routes) very well. Your take off points should not be connected to more than one route (case of taxiways on both sides of the runway feeding a single take off point from both sides as shown on the right.<br />
<br />
Select each of the nodes placed on the physical runway (not the ones leading to it) and mark them "On Runway" with the toggle in their properties panel <br />
<br />
'''Step 3 : Connect ParPos and Runway Access routes to form the groundnet.''' <br />
<br />
Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.<br />
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircraft as many routing options as possible.<br />
<br />
Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.<br />
<br />
Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircraft park straight and leave their parking straight (rolling forward or pushing back).<br />
<br />
Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircraft. In essence draw just enough routes so that all gates and runways are connected.<br />
<br />
'''Step 4 : Visual Check'''<br />
Once your base groundnet complete, Check visually that your parking positions do not overlap, that nodes placed on physical runways are marked as such and that intersections are formed properly (no node unless the aircraft can turn here)<br />
<br />
'''Step 5 : Structural Check and Test'''<br />
<br />
Run the verification tool (available in both Taxidraw and FGAirports). Both programs will ensure at this stage that routes are valid and that nodes on runway are marked as such. <br />
Taxidraw does not check the routes structures individually but rather that a route solution exist: If an aircraft can use different path/routes to go from its ParkPos to a given runway threshold and even if one of these routes is "broken" (unconnected segments) no error will be reported, because the aircraft could use another (unbroken) route to get to the threshold and hence still has a routing solution.<br />
<br />
FGAirports will do the same routing check but will also signal any unconnected node (broken routes). <br />
Correct the errors found and re run the verification tools until no more problems are found.<br />
<br />
Time to test with 'real' traffic. Save your groundnet and export it to a custom scenery folder (NOT to the Terrasync Folder), usually something like F:\My Sceneries\Airports\S\B\SBGR.groundnet.xml.<br />
Startup Flightgear and add your custom scenery folder path (the parent of \Airports) to your extra sceneries list in the Add On screen. Select your Airport as Startup Location. Run <br />
<br />
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]] <br />
* Parked aircraft will start appearing on the parking stands you have set. Departing aircraft will light up (red/green nav lights on wing tips, flashing beacon on top)<br />
* Upon ATC clearance (automatic) Departing aircraft will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.<br />
* Departing Aircraft will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off<br />
* Arriving aircraft will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off<br />
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircraft following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.<br />
* Aircraft will taxi from both directions on single taxiways, eventually passing through each other<br />
* On larger airports where AI aircraft can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier. <br />
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)<br />
* No aircraft (no AI traffic at this airport or not activated in FG options)<br />
* Aircraft queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)<br />
<br />
<br />
=== Refining the network: Routing Flow & Baggage Carousels Belts === <br />
<br />
Objective:<br />
* All Objectives in the "Creating the base Network" section<br />
* No clogging at intersections<br />
* No Head on crashes of aircraft sharing a single taxiway<br />
<br />
The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircraft will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.<br />
<br />
You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes: <br />
* AI traffic cannot make decisions: Typically, where presented with multiple routing options (an X intersection with 4 or more valid routes), AI traffic will consistently freeze/clog after some time if not immediately.<br />
* AI traffic does not stand bullying: If presented with no alternative at all (too many unidirectional routes) AI traffic will move away from your groundnet taxiways and start mowing the lawns. <br />
<br />
<br />
[[File:Groundnet Routing Flow Example.png|border|right|950px|Groundnet Routing Flow Example]]<br />
Keeping these two constraints in mind, the clogging and head on collisions noted in your previous tests can be addressed by setting up a ‘Routing Flow’. The purpose of said routing is to guide each aircraft to their final destination (Parking or Threshold), by ensuring it uses a single route and never crosses any other aircraft path.<br />
To achieve this we only have and need two tools: The ability to force the direction of traffic on any given segment (by making it “unidirectional”) and the ability of Traffic manager to handle priorities and queues formation at routes merging points (Y shaped intersections).<br />
<br />
The complexity of Routing Flow will increase exponentially with the number of gates, thresholds and traffic files handled: A single groundnet flow must accommodate indifferently a cargo flight arriving on RWY 1 in the evening or a commuter departing from RWY 2 in the morning.<br />
<br />
To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel. <br />
That is all bags (Aircraft) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).<br />
<br />
An advantage AI aircraft have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.<br />
<br />
Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.<br />
<br />
[[File:Apron Belt at Bahrein Intl.png|left|thumb|Using the Belt technique to feed the OBBI apron]] <br />
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.<br />
<br />
The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircraft to move from one belt to the other.<br />
<br />
You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.<br />
<br />
Certain smaller airports do not have enough taxiways to allow the formation of a proper global belt but the technique can be used on individual aprons to ensure proper flow in and out of parking areas and simplify the design of pushback routes (next section) as shown on the image on the left, at Bahrein Intl.<br />
<br />
Testing : Once your routing flows in place you should re-test you groundnet. The expected behaviour is the same then the one described in the “Base Network, Step 5” section, with the exception of head on collisions and clogged intersections which should no longer exist<br />
<br />
<br />
=== Refining the network: Pushback routes ===<br />
<br />
'''THIS SECTION IS WIP'''<br />
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. Pushback routes are optional (if you like the terminal crashing scenario described above).<br />
<br />
'''Examples of simple valid pushback routes''' (Left: If the taxiway is bidirectional | Centre: If the taxiway is not bidirectional | Right: With shared Pushback Holding point)<br />
<br />
[[File:MultiDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid AI Groudnet pushback for multi directional taxiway]] <br />
[[File:UniDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid Pushback Route on Un directional taxiway]]<br />
[[File:Shared Pushback Holding Point in Taxidraw.jpg|400px|Shared Pushback Holding Point]] <br />
<br />
[[File:Roll Forward Gate in Taxidraw.jpg|thumb|Invalid Park Pos Exist route : at and angle with Parking Position]]<br />
===== Pushback Holding Points must be unique per Parking Position =====<br />
<br />
Each Parking space (ParkPos) can't have more than one push back route and one pushback holding point at the end of the route. Nevertheless, multiple Parkpos can share part of their pushback routes and a single Pushback Holding Point.<br />
<br />
The formal criteria for a valid push back route is that each gate should have a maximum of one push back holding point associated with it, which can be reached using one route only.<br />
From an editing point of view, mark all segments between your parking position and its final holding point as "push back", do not forget to mark the ending node as Pushback Holding Point.<br />
<br />
===== The AI code does not handle sharp angles =====<br />
<br />
Add nodes to smoothen your routes so that no consecutive segments form an angle of less than 90 degrees. <br />
This rule applies to both pushback and roll forward / taxiways routes <br />
<br />
===== The Inbound route and the outbound routes are parallel ===== <br />
[[File:On Taxiway Pushback Holding Point in Taxidraw.jpg|thumb|Invalid Groudnet Pushback : Holding Point on Taxiway]]<br />
<br />
The last segment of the pushback route will condition the aircraft heading:<br />
<br />
1. During its travel along the pushback route <br />
<br />
2. At the Pushback Holding point (whilst waiting for clearance)<br />
<br />
3. On departing the pushback holding point, rolling forward to the runway.<br />
<br />
<br />
You can not control/force an AI aircraft to leave a Pushback Holding point at a different angle/heading than the one it came onto its final holding node at, whatever the number of routes you add.<br />
<br />
As a result, the last segment of the pushback route must align with the segment you expect the aircraft to use when starting to roll forward after clearance. The simpler set up is to have this final pushback segment overlapping the first segment of the roll forward route.<br />
<br />
Alternatively, the last segment of the pushback route can -itself- be the first segment of the roll forward route but this means Traffic Manager will consider this segment 'reserved' whilst the aircraft is pushing back and no other aircraft will be able to use the taxiway.<br />
<br />
For the same reason the Pushback Holding point should NOT be directly placed on the taxiway as shown in the image on the right 'On Taxiway Pushback Holding Point in Taxidraw'.<br />
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to. <br />
<br />
The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircraft which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI <br />
<br />
<br />
It is important to note that the Taxidraw "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 with all aircraft from one side of the E terminal are being linked to one shared push back point. <br />
<br />
Given the current push back system allows for fairly complicated behavior it is advisable to test extensively your groundnet and play with various configurations before sharing it to the community. <br />
<br />
Taxidraw note: TaxiDraw versions prior to February 5, 2009 did export the pushBackRoute attribute correctly. <br />
<br />
[[File:TaxiDraw2.png|thumb]]<br />
<br />
==== Verifying the network ====<br />
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. <br />
<br />
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.<br />
<br />
* '''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.<br />
* '''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. <br />
* '''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. <br />
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.<br />
<br />
=== Copying the ground network into FlightGear's scenery directory ===<br />
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>.<br />
<br />
In Taxidraw menu select File, Export AI Network and save the file in the above folde as ICAO.groundnet.xml. Please note that the File / Save project menu applies only to the airport layout and does NOT save your groundnet.<br />
<br />
=== Testing the network ===<br />
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. <br />
<br />
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.<br />
<br />
=== Airports with ground networks ===<br />
<br />
== Collision Detection == <br />
<br />
Version 2024.1.X and all version prior use an avoidance strategy based on the ground network. This means there are lots of Dijkstra calls to determine the possible route to the runway. Another implication is that the designer of the ground network must ensure the separation. This is of course not possible in pushback or even with the user aircraft. <br />
The next version will get real detection of nearness and integration with ATC. This is based on a Quadtree and just reacts on the current snapshot and not on "future" plans of an aircraft. <br />
<br />
=== Nearness rose ===<br />
[[File:Ai-windrose.png|thumb|A diagram showing an aircraft and different szenarios based on heading|none]]<br />
<br />
This diagram shows some possible angles of approach.<br />
<br />
=== Braking ===<br />
[[File:Following slowdown.png|thumb|A diagram showing the braking of a following aircraft|none]]<br />
<br />
When following aircraft must brake in a plausible way.<br />
<br />
= Runway Usage Configuration = <br />
<br />
ICAO.rwyuse.XML dictates which runway(s) should be used for AI take off and which ones accept AI landings. These instructions are organised in multiple sets (or configurations) and ordered by preference of use.<br />
<br />
Schedules can be defined so different runway configurations can be used at different time of the day. Different Sets can also be applied to the General Aviation and Commercial traffic.<br />
<br />
Each set of runway configuration is tested against the wind conditions and applies only if the crosswind and tailwind are within tolerance. If not, the next set in the order of preference, will be picked.<br />
<br />
Examples below taken from the Amsterdam Schiphol EHAM.rwyuse.xml file.<br />
<br />
Wind conditions are stored at the beginning of the file and indicate the maximum values of Crosswind and Tailwind acceptable to authorize take off and landing at the airport.<br />
<br />
<syntaxhighlight lang="xml"><br />
<wind tail="7"<br />
cross="20" /><br />
</syntaxhighlight><br />
<br />
{{quote|As well as aircraft, airports have operational crosswind and tailwind limits. [] The values vary but crosswind limits are normally 15-25 kts and tailwinds are normally no more than 10 kts.|ICAO|AMOFSG/10-SN No. 14}}<br />
<br />
The < time > table defines the hours of activation for a particular Schedule. Each schedule contains a 'Pattern' ie a fixed number of runways allocated to either take off or landing).<br />
<br />
For instance, at EHAM, the commercial "inbound" schedule is active from 06:20 to 08h30 UTC, at a time where there is more inbound than outbound traffic and the airport needs to allocate more runways to landing than to take off.<br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "06:20"<br />
end = "08:30"<br />
schedule = "inbound"/><br />
</syntaxhighlight><br />
<br />
In most cases, a single schedule can apply 24h every day. <br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "00:00"<br />
end = "24:00"<br />
schedule = "Day"/><br />
</syntaxhighlight><br />
<br />
<br />
The different sets of runways allocation are listed in each < schedule > table by order of preference and can be read/deciphered vertically as ”columns” delimited by commas.<br />
<br />
When wind conditions do not allow the use of a set, the next one will apply (next “column”).<br />
<br />
Still using the EHAM.rwyuse.xml file as example, from 06:20 to 08:30 UTC, when the Inbound schedule applies; AI traffic will preferably use runway 36L for take-offs, and both 06 and 36R for landings (first “column” of data).<br />
<br />
<syntaxhighlight lang="xml"><br />
<schedule name="inbound"><br />
<takeoff>36L, 24, 18L, 36L, 24, 24, 18L, 09</takeoff><br />
<landing>06, 18R, 18R, 36R, 27, 18R, 18R, 06</landing><br />
<landing>36R, 18C, 18C, 36C, 18R, 22, 22, 09</landing><br />
</schedule><br />
</syntaxhighlight><br />
<br />
Shall wind conditions prevent the use of this configuration (Tailwind or Crosswind values exeeding the ones defined in <wind> above), the next set (or “column”) will apply ie 24 for take-offs, and 18R + 18C for landings.<br />
<br />
Again, if wind conditions prevent this configuration use, the next set will be used (18L for take-offs, 18R and 18C for landing).<br />
<br />
This test of runway sets against wind values will continue with the rest of the sets in the schedule until a valid one is found and applied.<br />
<br />
It is necessary for each of the <takeoff> and <landing> entries to have an equal number of runway values, per schedule, so each set contains the same number of runways.<br />
<br />
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAMbEsE46ontK4G43zmrEqLEk%3D8ZK5sQ-vxZup%3DNjpaUDgb-ASw%40mail.gmail.com/#msg37166996 Source from Durk post in Devel]<br />
<br />
<br />
= Model Animation =<br />
<br />
To assist with creating realistic aircraft behaviour, some properties are set by the Traffic Manager during particular flight phases as follows<br />
<br />
{| class="wikitable"<br />
|-<br />
! Property !! Description !! Type !! At Gate !! Taxiing !! Take-off !! Cruise !! Approach and Landing<br />
|-<br />
| gear/gear[0..5]/position-norm || Gear Position || double (interpolated over 10 seconds || 1.0 || 1.0 || 0.0 (above 400ft) || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| surface-positions/flap-pos-norm || Flaps position || double (interpolated over 20 seconds || 0.0 || 0.0 || 0.5 (below 2000ft) || 0.0 || 1.0 ( below 2000ft)<br />
|-<br />
| surface-positions/spoiler-pos-norm || Spoiler position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (on runway)<br />
|-<br />
| surface-positions/speedbrake-pos-norm || Speedbrake position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| controls/lighting/beacon || Beacon || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/cabin-lights || Cabin lights || bool || true || true || true || false || false<br />
|-<br />
| controls/lighting/landing-lights || Landing lights || bool || false || false || false || true || true<br />
|-<br />
| controls/lighting/nav-lights || Navigation lights || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/strobe || Strobes || bool || false || false || true || true || true<br />
|-<br />
| controls/lighting/taxi-lights || Taxi lights || bool || false || true || false || false || false<br />
|}<br />
<br />
= SIDs / STARs =<br />
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 flight path, 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 way points. <br />
<br />
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-concept data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of this data. Note that this data is meant to be just that; a proof-of-concept. User contributions will be accepted as soon as the format has stabilized.<br />
<br />
= Appendix: Special Notes =<br />
<br />
<br />
== Performance ==<br />
With recent versions of FlightGear, we have much better performance than before 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. <br />
<br />
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.<br />
<br />
= Related content =<br />
* [[Airports with ground networks]]<br />
* [[FGAirports]] - A groundnet editor<br />
* [[Flightplan XML formats]]<br />
* [[Status of AI in FlightGear]]<br />
<br />
<br />
[[de:Interaktiver Verkehr]]<br />
<br />
[[Category:AI Traffic]]<br />
[[Category:FlightGear feature]]<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=AI_Traffic&diff=141260AI Traffic2025-01-21T13:33:07Z<p>Portreekid: /* Collision Detection */</p>
<hr />
<div>{{AI Navbar}}<br />
<br />
'''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic.<br />
<br />
In essence, the AI controlled traffic system is comprised of four elements: <br />
# AI Aircraft models: Are part of the base package under <tt>$DATA/AI/Aircraft</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. <br />
# AI traffic schedules: Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircraft should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> <br />
# Groundnets: Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircraft on the ground from gates to runways and vice versa, at each individual airport (one per airport). The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.<br />
# Runway Use Configurations (RWYUSE): Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and condition which runway(s) are for AI take off and landings based on the time of the day and wind conditions.<br />
<br />
<br />
<br />
= Traffic Schedules =<br />
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.<br />
<br />
In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircraft available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircraft will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.<br />
AI aircraft provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.<br />
<br />
To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.<br />
<br />
Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircraft do not time travel no teleport). <br />
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.<br />
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.<br />
<br />
It is recommended the traffic schedules follow as much as possible reality and so they should include turnaround time at each airport even if an AI aircraft does not require cleaning and refuelling.<br />
<br />
To facilitate scheduling, a new database format was introduced in FlightGear 1.9.0 and flights are no longer directly and rigidly assigned to a specific aircraft (Unique registration). 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.<br />
<br />
<br />
== An example of a traffic file ==<br />
<br />
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:<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCB</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<br />
<flight><br />
<callsign>KLM0765</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>0/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCM</port><br />
<time>0/21:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
<br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>TNCM</port><br />
<time>3/01:25:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>EHAM</port><br />
<time>3/10:50:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</trafficlist><br />
</syntaxhighlight><br />
<br />
== Dissecting the traffic file ==<br />
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.<br />
<br />
=== General layout ===<br />
The general layout of each file should look like the above example.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<br />
</trafficlist><br />
</syntaxhighlight><br />
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.<br />
<br />
=== Defining the aircraft ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
...<br />
</aircraft><br />
</trafficlist><br />
</syntaxhighlight><br />
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.<br />
<br />
* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.<br />
* '''<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 aircraft type ('''<actype>''') and paint scheme, but I abandoned that idea, because it didn't turn out to be very compatible with the existing FlightGear model loading code. <br />
* '''<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. <br />
* '''<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 in the routing algorithm. '''[New for Traffic Manager II]'''<br />
* '''<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]'''<br />
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].<br />
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are built 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.<br />
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.<br />
* '''<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:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''<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:<br />
** '''light_aircraft''' (General aviation prop driven single or twin),<br />
** '''turboprop_transport''' (Commercial Turboprop),<br />
** '''jet_transport''' (Commercial jet)<br />
** '''heavy_jet''' (Commercial jet w/ MTOW > 136tons)<br />
** '''ww2_fighter''' (world war two fighter),<br />
** '''jet_fighter''' (modern fighter aircraft)<br />
** '''tanker''' (tanker aircraft), or.<br />
** '''ufo''' (allows extreme accel/decel capabilities).<br />
* '''<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.<br />
* '''<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.<br />
<br />
=== Defining a flight ===<br />
The Traffic Manager II file formats contains separate sections for both aircraft 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:<br />
<syntaxhighlight lang="xml"><br />
<aircraft> <br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</aircraft><br />
<br />
<flight><br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</flight><br />
</syntaxhighlight><br />
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. <br />
<syntaxhighlight lang="xml"><br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>2/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCB</port><br />
<time>2/22:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</syntaxhighlight><br />
The '''<flight>''' 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:<br />
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.<br />
* '''<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''').<br />
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section. <br />
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.<br />
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<nowiki><time></nowiki>''' keywords.<br />
* '''<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. Values are in [https://en.wikipedia.org/wiki/Flight_level flightlevels]<br />
* '''<arrival>''' Same as '''<departure>''', but now defining the '''<port>''' and '''<nowiki><time></nowiki>''' of arrival.<br />
* '''<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.<br />
* '''<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. <br />
* '''<nowiki><time></nowiki>''' 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 unpredictable. Times should be in UTC. Weekdays start on Sunday (0) and end on Saturday (6).<br />
<br />
== Putting it all together: Including a traffic file ==<br />
Traffic files are found under [[$FG_ROOT]]/AI/Traffic. The actual traffic files should be stored in a subdirectory one level below /AI/Traffic.<br />
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.<br />
<br />
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 aircraft with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.<br />
<br />
= Ground networks =<br />
<br />
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircraft can park precisely at the Terminal gates]]<br />
<br />
Using the traffic files information above, the AI Traffic Manager knows which AI aircraft should land at (and take off from) each airport and when. It will automatically place the relevant aircraft models in the scenery and animate them so they navigate from the runways to the gates and vice versa, according to their individual schedule.<br />
<br />
Although the physical layout of each airport is stored in FlightGear's APT.DAT master file, the information is not accurate enough to determine which specific routes AI models can use; Instead, Traffic manager will rely on a dedicated file containing a simple wireframe/network of taxiways and gates AI aircraft can follow whilst on the ground ie a GroundNet. A groundnet is made of 3 different elements: Parking Positions, Nodes and Segments (to join nodes and Parking together). <br />
<br />
This routing information is aggregated, per airport, in a XML, stored and distributed by Terrasync as '''/Terrasync/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml''' where ICAO stands for the 4 letter ICAO code of the relevant airport.<br />
<br />
Similarly to Terrain and Objects, Terrasync groundnets can be overridden by placing a personalized version in your custom scenery folder, using the same path structure: /Custom Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.<br />
<br />
Groundnets are not mandatory but, in absence of this routing information, AI Aircraft cannot park anywhere; they will still try to stick to their schedule, appearing magically at the centre of the airport and taxiing directly to the runways’ thresholds, over grass, buildings and static objects, on time.<br />
<br />
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking. <br />
<br />
== A technical perspective ==<br />
A ground network xml file consists of four tables:<br />
* '''<frequencies>''' The Airport’s radio frequencies (Optional). As of v1.9.0, FlightGear uses these to display some ATC messages like start-up approval requests. You can "hear" them by tuning to the first ground frequency listed in the section.<br />
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircraft can use them.<br />
* '''<TaxiNodes>''' The list of all the nodes in the ground network.<br />
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.<br />
<br />
Each Parking and Node element in the groundnet has a unique index number, allowing routes be formed (from one ID to the next via a segment/arc) between parking positions and runways <br />
<br />
''Parking Positions Parameters:''<br />
* '''index''' Unique ID, internal to the file structure<br />
* '''lat''' latitude in decimal minutes format, for example <code>N50 56.988</code>)<br />
* '''lon''' longitude in decimal minutes format, for example <code>W01 21.756</code>)<br />
* '''name & number ''' (gate identification as found on airport charts, for example <code>D23</code> or <code>C1</code>). <br />
* '''type:''' The type of aircraft which can use this space. Matched to the <flighttype> parameter found in traffic files:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo/freighter)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''heading:''' The heading at which the aircraft parks in this space.<br />
* '''radius:''' The size of the parking spot. Matched to the aircraft <radius> parameter in traffic files to determine if a given AI Aircraft model will fit the position. See [[aircraft radii]]<br />
* '''airlineCodes:''' a comma-separated list of ICAO airline codes allowed to park at this gate. Matched to the aircraft <airline> parameter of traffic files. Leave blank for all airline to be able to use the gate.<br />
* '''pushBackRoute:''' The ID of the next node in the network along a pushback route. 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.<br />
<br />
''Nodes parameters:''<br />
<br />
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircraft waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear<br />
* '''holdPointType''' can have the following values:<br />
** '''None''' Not a holding point (normal taxi-through node) <br />
** '''PushBack''' The node marks the end of a pushback route, where the aircraft stops rolling backward and start rolling forward upon clearance. A pushback Holding Point can be part of more than one pushback route. See Pushback below. <br />
** '''Normal''' (Not yet supported): a regular taxiway holding point.<br />
** '''CAT II/III''' (Not yet supported): a special holding point for IFR conditions.<br />
<br />
''segments parameters:''<br />
<br />
* '''begin''' The id of the parking space or AINode where this segment starts<br />
* '''end''' The id of the parking space or AINode where this segment ends<br />
* '''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.<br />
* '''name''' Name of the taxiway.<br />
<br />
== Tools & Source Material ==<br />
Groundnets can be built using either FG Airports (v0.032 or later) or Taxidraw (legacy) <br />
<br />
[[FGAirports]] is the current tool of choice. Its philosophy is airport centered rather than file specific and allows you to visualize at a glance all of the existing groundnets as well as editing them and submitting them to Terrasync. It leverages Open Street Map data, APT.DAT and scenery xmls to provide a visual representation of the airport layout as well as thresholds and tower positions. <br />
<br />
FGA automatically checks the validity of groundnet files before submission and assess their adequacy by comparing the number of gates set against the volume of AI traffic at a particular airport.<br />
<br />
[[TaxiDraw]] pre dates WED and allowed the creation of airport layouts from basic geometrical shapes. Its ground network module is somewhat separate from the rest of the airport project code but allows the creation and local export of simple groundnets.<br />
<br />
See the [[TaxiDraw]] and [[FGAirports]] articles for instructions on how to obtain the tools and operating instructions.<br />
<br />
Most Civil Aviation authorities make electronic versions of their Aeronautical Information Publication available on the web (Lookup 'eAIP' or go to https://www.eurocontrol.int/articles/ais-online). AIPs contain precise Airport Charts but also lists of parking stands with their exact Latitude/Longitude as well as usage (Cargo, Gate) and the category (radii) of aircraft they can accommodate.<br />
<br />
Gates Numbers and Airlines operating them can often be found on Airports website. Most flight tracking sites/apps will also allow you to monitor a flight all to the way to its gate to identify who parks where.<br />
<br />
In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!<br />
<br />
== Ground traffic rendering ==<br />
''19th November 2021.''<br />
<br />
=== Performance ===<br />
<br />
* CPU: Currently having a lot of nodes in the OSG scene-graph will rapidly make FlightGear CPU bound. A lot of separately animated ground traffic objects mean a lot of nodes. Static objects (i.e. non-animated objects) can be put into one mesh - meaning one scenegraph node with the current system.<br />
* GPU: Having fewer draw calls is fast. Having fewer state changes is fast. <br />
* The fast path for both CPU and GPU is creating a way to combine multiple animated objects in one mesh - this is how modern 3d applications do lots of objects with animations fast.<br />
<br />
=== The fast way to do moving objects is to let the vertex shader look at information in buffers and position each object ===<br />
<br />
* Have all the different path segments stored in one buffer that can be read by the vertex shader. This buffer can be generated at runtime for each airport, maybe using NASAL scripts, and not updated.It's also possible to store the 1st buffer in TerraSync. <br />
* Have a second buffer store all per-object data in an array. The array is indexed by the object ID. This includes things like vehicle animation state, which path segment each object is on, the starting time, and a speed scaling factor. The second buffer is updated regularly by the CPU.<br />
* Two approaches to packing different types of objects in a 1 or few meshes <br />
**'''a).''' Every type of object is combined in one vertex buffer and rendered with the same shaders, texture atlas or array. Every vehicle is packed one after the other in the vertex buffers. Multiple types of vehicles are contained in the same mesh. Multiple instances of the same vehicle take up extra space. <br />
*** All material parameters or uniform values that change between objects, or within objects, like specularity are added as vertex attributes or textures. A vertex shader that can handle all object animations is used. <br />
*** The entire set of objects takes up one scene graph node, and is rendered in one draw call. It's possible to do ground vehicles and AI aircraft as two meshes.<br />
*** The object ID (an integer) can be added to each vertex as an vertex attribute. This is used to lookup per-object info in the 2nd buffer, including the paths from the first buffer.<br />
** '''b).''' Each different type of object (different ground vehicle) is instanced and takes up one scene-graph node. This can allow different shaders and textures per object type. There is less vertex data taking up RAM and VRAM. There are more scenegraph nodes, and draw calls.<br />
*** The object ID (an integer) can be added as a per-instance vertex attribute.<br />
* The vertex shader can trivially look at the object ID, then find the path segment, the starting time, speed scaling factor, and current time to position each object. If the current time is past the end of the current path, the object will stay at the end position.<br />
* The buffers can be a uniform array (minimum of points in each path segment and more smoothing), Uniform Buffer Object (UBO - not available until Vulkan due to Macs not supporting it), a Texture Buffer Object (TBO - Mac support unknown), or a texture looked up in a vertex shader (maybe slower).<br />
* Data format: Each path segment is x,y,z position at regular times - a time-series of positions - e.g. [10m, 20m, 0m elevation] at t = 1s. [20m, 25m, 0m] at t=2s . [30m, 30m, 0m] at t= 3s. 16 bit integers are enough, but 32 but floats can also be used at the cost of 2x the occupancy. 16 bit implementation: If a texture is used it can be 16bit RGB - R=x, G=y, B=z. 2 consecutive 8 bit values can also be read from a texture.16 bit integers can cover an ground traffic area of ~65km with a spacing of 1m. 16bits can give a ~13km ground traffic area with an accuracy of 20cm. The accuracy of the positions doesn't matter too much - the vertex shader can look at 2-3+ path positions and create a smooth interpolation (a smooth curve joining the points). The time steps can also be large. <br />
* If a path has a slowly moving segment, it will take up more points. If a path segment takes a short amount of time, it can have a special xyz numner to indicate path has ended - otherwise the path start/end time information can be stored as uniforms or in a UBO. Vehicles that move faster can have a higher speed scaling. There can be different path segment variations, for example if vehicles have a different acceleration pattern - e.g. speeding up and braking hard, or sharper turns, in an emergency.<br />
* Both ground vehicles, and taxiing aircraft can be done this way. It's possible to replace a conventional AI aircraft model, with a fast rendering ground traffic model once an aircraft starts taxiing.<br />
* If models use animations, they should ideally use a vertex shader that can handle all these animations - so having multiple draw calls per model and CPU-side animation is avoided.<br />
* It's possible to split of different parts of craft into separate meshes for parts that are very dissimilar - at the cost of more scenegraph nodes and draw calls. For example, a separate mesh for lights of various types - these lights will follow the same paths as the vechiles and position themselves correctly.<br />
* <br />
<br />
<br />
<br />
The way animation is handled (animation meaning moving objects, and parts of moving objects) in modern 3d application is to store the animation data in arrays/buffers on the GPU side and render multiple objects in one draw call.<br />
<br />
From a quick google search - a 2010 blog about whether UBOs or TBOs are more suited for different tasks:<br />
<br />
''"Personally I use them [UBOs] for instanced rendering by storing the model-view matrix and related information of each and every instance in a common uniform buffer and use the instance id as an index to this combined data structure. This usage performs very well on my system.''<br />
<br />
''Also uniform buffers can be used to store the matrices of bones and use them for implementing skeletal animation, however, I personally prefer using normal 2D textures for this purpose to take advantage of the free interpolation thanks to the dedicated texture fetching units but that’s another story.''<br />
<br />
''[..] Personally I use texture buffers for different geometry deformation techniques, to resolve batching issues when the size limitation of uniform buffers is a blocking factor, and for some inverse kinematics effects." - Rastergrid blog, 2010 [https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/][https://web.archive.org/web/20211119134448/https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/]''<br />
<br />
This is from a 2010 blog - this general approach has been the way to do lots of animated objects for a long time. <br />
<br />
Even really complicated animations like moving bodies and cloth physics are handled by moving animation data into buffers - this approach would be needed if FlightGear ever did a simulation of crowds at an airport - not just for boarding one plane which probably won't be too cripplingly slow. But for crowds boarding lots of planes, and moving about large airports. For animating humans, there are will be standard animation formats compatible with output of tools in blender or make human[http://www.makehumancommunity.org/]. This approach may also be worth while for rendering lots of seated passengers with really simple movements - and a few walking about with a simple walk cycle. It may also be justified for large amounts of ground personnel at big airports (not just a few relevant for the users plane).<br />
<br />
== Warnings and Limitations ==<br />
The complexity of building a fully functional groundnet (and the time spent on it) grows exponentially with the size of the airport but very small airports, on Pacific Islands for example, pose even larger challenges. An ideal project to start with is a Metropolitan airport with one or two runways, and two dozen of parking positions. <br />
<br />
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:<br />
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]<br />
* TM does not space landing aircraft. You will most likely see packs of landing aircraft hitting your runways at once, sometimes from both ends. Departures are spaced properly though <br />
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route. <br />
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied. <br />
* AI Aircraft cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight) <br />
<br />
* Groundnets, terrain and scenery objects are independent. If you see your AI aircraft rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.<br />
<br />
Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.<br />
<br />
Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircraft are handled. <br />
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.<br />
<br />
On the bright side, both Taxidraw and FG Airports contain a validation tool which will allow you to detect any structural problem with your groundnet. You will also find a lot of resources and tips in the AI section of the Flightgear forums.<br />
<br />
Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.<br />
[[File:Gate Definition in FG Airports.png|300px|thumb|FG Airports UI for Parking Position]]<br />
== Creating the base network == <br />
<br />
Objective:<br />
* You have enough gates for all AI aircraft using the airport<br />
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet<br />
* Each Runway(s) threshold has a unique link to the rest of the groundnet<br />
* Departing Aircraft can reach any threshold, from any parking position <br />
* Arriving Aircraft can reach any suitable parking position from any threshold<br />
<br />
<br />
'''Step 1 : Place and configure the Parking Positions'''<br />
<br />
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.<br />
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]] <br />
AI Aircraft will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.<br />
<br />
Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters. <br />
Military and General Aviation can also be used if you are running personalized traffic files on your machine.<br />
<br />
Adjust the heading and radius for each of your gates according to the maximum wingspan the stand can accommodate. See [[aircraft radii]]. <br />
Set a unique name for the gate.<br />
Leave the AIRLINE field empty at this point.<br />
<br />
'''Step 2 : Place and configure the Runway accesses'''<br />
<br />
AI aircraft need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.<br />
<br />
At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).<br />
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.<br />
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircraft will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.<br />
<br />
Backtracking: Certain airports do not have taxiways along the runway and aircraft will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].<br />
<br />
Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.<br />
[[File:Multiple Route leading to a single Threshold.png|thumb|Runway access routes must be unique]]<br />
Your access route must be unique: Traffic manager does not handle intersections (nodes with 4 routes) very well. Your take off points should not be connected to more than one route (case of taxiways on both sides of the runway feeding a single take off point from both sides as shown on the right.<br />
<br />
Select each of the nodes placed on the physical runway (not the ones leading to it) and mark them "On Runway" with the toggle in their properties panel <br />
<br />
'''Step 3 : Connect ParPos and Runway Access routes to form the groundnet.''' <br />
<br />
Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.<br />
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircraft as many routing options as possible.<br />
<br />
Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.<br />
<br />
Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircraft park straight and leave their parking straight (rolling forward or pushing back).<br />
<br />
Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircraft. In essence draw just enough routes so that all gates and runways are connected.<br />
<br />
'''Step 4 : Visual Check'''<br />
Once your base groundnet complete, Check visually that your parking positions do not overlap, that nodes placed on physical runways are marked as such and that intersections are formed properly (no node unless the aircraft can turn here)<br />
<br />
'''Step 5 : Structural Check and Test'''<br />
<br />
Run the verification tool (available in both Taxidraw and FGAirports). Both programs will ensure at this stage that routes are valid and that nodes on runway are marked as such. <br />
Taxidraw does not check the routes structures individually but rather that a route solution exist: If an aircraft can use different path/routes to go from its ParkPos to a given runway threshold and even if one of these routes is "broken" (unconnected segments) no error will be reported, because the aircraft could use another (unbroken) route to get to the threshold and hence still has a routing solution.<br />
<br />
FGAirports will do the same routing check but will also signal any unconnected node (broken routes). <br />
Correct the errors found and re run the verification tools until no more problems are found.<br />
<br />
Time to test with 'real' traffic. Save your groundnet and export it to a custom scenery folder (NOT to the Terrasync Folder), usually something like F:\My Sceneries\Airports\S\B\SBGR.groundnet.xml.<br />
Startup Flightgear and add your custom scenery folder path (the parent of \Airports) to your extra sceneries list in the Add On screen. Select your Airport as Startup Location. Run <br />
<br />
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]] <br />
* Parked aircraft will start appearing on the parking stands you have set. Departing aircraft will light up (red/green nav lights on wing tips, flashing beacon on top)<br />
* Upon ATC clearance (automatic) Departing aircraft will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.<br />
* Departing Aircraft will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off<br />
* Arriving aircraft will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off<br />
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircraft following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.<br />
* Aircraft will taxi from both directions on single taxiways, eventually passing through each other<br />
* On larger airports where AI aircraft can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier. <br />
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)<br />
* No aircraft (no AI traffic at this airport or not activated in FG options)<br />
* Aircraft queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)<br />
<br />
<br />
=== Refining the network: Routing Flow & Baggage Carousels Belts === <br />
<br />
Objective:<br />
* All Objectives in the "Creating the base Network" section<br />
* No clogging at intersections<br />
* No Head on crashes of aircraft sharing a single taxiway<br />
<br />
The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircraft will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.<br />
<br />
You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes: <br />
* AI traffic cannot make decisions: Typically, where presented with multiple routing options (an X intersection with 4 or more valid routes), AI traffic will consistently freeze/clog after some time if not immediately.<br />
* AI traffic does not stand bullying: If presented with no alternative at all (too many unidirectional routes) AI traffic will move away from your groundnet taxiways and start mowing the lawns. <br />
<br />
<br />
[[File:Groundnet Routing Flow Example.png|border|right|950px|Groundnet Routing Flow Example]]<br />
Keeping these two constraints in mind, the clogging and head on collisions noted in your previous tests can be addressed by setting up a ‘Routing Flow’. The purpose of said routing is to guide each aircraft to their final destination (Parking or Threshold), by ensuring it uses a single route and never crosses any other aircraft path.<br />
To achieve this we only have and need two tools: The ability to force the direction of traffic on any given segment (by making it “unidirectional”) and the ability of Traffic manager to handle priorities and queues formation at routes merging points (Y shaped intersections).<br />
<br />
The complexity of Routing Flow will increase exponentially with the number of gates, thresholds and traffic files handled: A single groundnet flow must accommodate indifferently a cargo flight arriving on RWY 1 in the evening or a commuter departing from RWY 2 in the morning.<br />
<br />
To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel. <br />
That is all bags (Aircraft) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).<br />
<br />
An advantage AI aircraft have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.<br />
<br />
Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.<br />
<br />
[[File:Apron Belt at Bahrein Intl.png|left|thumb|Using the Belt technique to feed the OBBI apron]] <br />
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.<br />
<br />
The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircraft to move from one belt to the other.<br />
<br />
You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.<br />
<br />
Certain smaller airports do not have enough taxiways to allow the formation of a proper global belt but the technique can be used on individual aprons to ensure proper flow in and out of parking areas and simplify the design of pushback routes (next section) as shown on the image on the left, at Bahrein Intl.<br />
<br />
Testing : Once your routing flows in place you should re-test you groundnet. The expected behaviour is the same then the one described in the “Base Network, Step 5” section, with the exception of head on collisions and clogged intersections which should no longer exist<br />
<br />
<br />
=== Refining the network: Pushback routes ===<br />
<br />
'''THIS SECTION IS WIP'''<br />
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. Pushback routes are optional (if you like the terminal crashing scenario described above).<br />
<br />
'''Examples of simple valid pushback routes''' (Left: If the taxiway is bidirectional | Centre: If the taxiway is not bidirectional | Right: With shared Pushback Holding point)<br />
<br />
[[File:MultiDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid AI Groudnet pushback for multi directional taxiway]] <br />
[[File:UniDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid Pushback Route on Un directional taxiway]]<br />
[[File:Shared Pushback Holding Point in Taxidraw.jpg|400px|Shared Pushback Holding Point]] <br />
<br />
[[File:Roll Forward Gate in Taxidraw.jpg|thumb|Invalid Park Pos Exist route : at and angle with Parking Position]]<br />
===== Pushback Holding Points must be unique per Parking Position =====<br />
<br />
Each Parking space (ParkPos) can't have more than one push back route and one pushback holding point at the end of the route. Nevertheless, multiple Parkpos can share part of their pushback routes and a single Pushback Holding Point.<br />
<br />
The formal criteria for a valid push back route is that each gate should have a maximum of one push back holding point associated with it, which can be reached using one route only.<br />
From an editing point of view, mark all segments between your parking position and its final holding point as "push back", do not forget to mark the ending node as Pushback Holding Point.<br />
<br />
===== The AI code does not handle sharp angles =====<br />
<br />
Add nodes to smoothen your routes so that no consecutive segments form an angle of less than 90 degrees. <br />
This rule applies to both pushback and roll forward / taxiways routes <br />
<br />
===== The Inbound route and the outbound routes are parallel ===== <br />
[[File:On Taxiway Pushback Holding Point in Taxidraw.jpg|thumb|Invalid Groudnet Pushback : Holding Point on Taxiway]]<br />
<br />
The last segment of the pushback route will condition the aircraft heading:<br />
<br />
1. During its travel along the pushback route <br />
<br />
2. At the Pushback Holding point (whilst waiting for clearance)<br />
<br />
3. On departing the pushback holding point, rolling forward to the runway.<br />
<br />
<br />
You can not control/force an AI aircraft to leave a Pushback Holding point at a different angle/heading than the one it came onto its final holding node at, whatever the number of routes you add.<br />
<br />
As a result, the last segment of the pushback route must align with the segment you expect the aircraft to use when starting to roll forward after clearance. The simpler set up is to have this final pushback segment overlapping the first segment of the roll forward route.<br />
<br />
Alternatively, the last segment of the pushback route can -itself- be the first segment of the roll forward route but this means Traffic Manager will consider this segment 'reserved' whilst the aircraft is pushing back and no other aircraft will be able to use the taxiway.<br />
<br />
For the same reason the Pushback Holding point should NOT be directly placed on the taxiway as shown in the image on the right 'On Taxiway Pushback Holding Point in Taxidraw'.<br />
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to. <br />
<br />
The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircraft which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI <br />
<br />
<br />
It is important to note that the Taxidraw "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 with all aircraft from one side of the E terminal are being linked to one shared push back point. <br />
<br />
Given the current push back system allows for fairly complicated behavior it is advisable to test extensively your groundnet and play with various configurations before sharing it to the community. <br />
<br />
Taxidraw note: TaxiDraw versions prior to February 5, 2009 did export the pushBackRoute attribute correctly. <br />
<br />
[[File:TaxiDraw2.png|thumb]]<br />
<br />
==== Verifying the network ====<br />
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. <br />
<br />
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.<br />
<br />
* '''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.<br />
* '''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. <br />
* '''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. <br />
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.<br />
<br />
=== Copying the ground network into FlightGear's scenery directory ===<br />
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>.<br />
<br />
In Taxidraw menu select File, Export AI Network and save the file in the above folde as ICAO.groundnet.xml. Please note that the File / Save project menu applies only to the airport layout and does NOT save your groundnet.<br />
<br />
=== Testing the network ===<br />
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. <br />
<br />
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.<br />
<br />
=== Airports with ground networks ===<br />
<br />
== Collision Detection == <br />
<br />
Version 2024.1.X and all version prior use an avoidance strategy based on the ground network. This means there are lots of Dijkstra calls to determine the possible route to the runway. Another implication is that the designer of the ground network must ensure the separation. This is of course not possible in pushback or even with the user aircraft. <br />
The next version will get real detection of nearness and integration with ATC. This is based on a Quadtree and just reacts on the current snapshot and not on "future" plans of an aircraft. <br />
<br />
=== Nearness rose ===<br />
[[File:Ai-windrose.png|thumb|A diagram showing an aircraft and different szenarios based on heading]]<br />
<br />
This diagram shows some possible angles of approach.<br />
<br />
=== Braking ===<br />
[[File:Following slowdown.png|thumb|A diagram showing the braking of a following aircraft]]<br />
<br />
When following aircraft must brake in a plausible way.<br />
<br />
= Runway Usage Configuration = <br />
<br />
ICAO.rwyuse.XML dictates which runway(s) should be used for AI take off and which ones accept AI landings. These instructions are organised in multiple sets (or configurations) and ordered by preference of use.<br />
<br />
Schedules can be defined so different runway configurations can be used at different time of the day. Different Sets can also be applied to the General Aviation and Commercial traffic.<br />
<br />
Each set of runway configuration is tested against the wind conditions and applies only if the crosswind and tailwind are within tolerance. If not, the next set in the order of preference, will be picked.<br />
<br />
Examples below taken from the Amsterdam Schiphol EHAM.rwyuse.xml file.<br />
<br />
Wind conditions are stored at the beginning of the file and indicate the maximum values of Crosswind and Tailwind acceptable to authorize take off and landing at the airport.<br />
<br />
<syntaxhighlight lang="xml"><br />
<wind tail="7"<br />
cross="20" /><br />
</syntaxhighlight><br />
<br />
{{quote|As well as aircraft, airports have operational crosswind and tailwind limits. [] The values vary but crosswind limits are normally 15-25 kts and tailwinds are normally no more than 10 kts.|ICAO|AMOFSG/10-SN No. 14}}<br />
<br />
The < time > table defines the hours of activation for a particular Schedule. Each schedule contains a 'Pattern' ie a fixed number of runways allocated to either take off or landing).<br />
<br />
For instance, at EHAM, the commercial "inbound" schedule is active from 06:20 to 08h30 UTC, at a time where there is more inbound than outbound traffic and the airport needs to allocate more runways to landing than to take off.<br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "06:20"<br />
end = "08:30"<br />
schedule = "inbound"/><br />
</syntaxhighlight><br />
<br />
In most cases, a single schedule can apply 24h every day. <br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "00:00"<br />
end = "24:00"<br />
schedule = "Day"/><br />
</syntaxhighlight><br />
<br />
<br />
The different sets of runways allocation are listed in each < schedule > table by order of preference and can be read/deciphered vertically as ”columns” delimited by commas.<br />
<br />
When wind conditions do not allow the use of a set, the next one will apply (next “column”).<br />
<br />
Still using the EHAM.rwyuse.xml file as example, from 06:20 to 08:30 UTC, when the Inbound schedule applies; AI traffic will preferably use runway 36L for take-offs, and both 06 and 36R for landings (first “column” of data).<br />
<br />
<syntaxhighlight lang="xml"><br />
<schedule name="inbound"><br />
<takeoff>36L, 24, 18L, 36L, 24, 24, 18L, 09</takeoff><br />
<landing>06, 18R, 18R, 36R, 27, 18R, 18R, 06</landing><br />
<landing>36R, 18C, 18C, 36C, 18R, 22, 22, 09</landing><br />
</schedule><br />
</syntaxhighlight><br />
<br />
Shall wind conditions prevent the use of this configuration (Tailwind or Crosswind values exeeding the ones defined in <wind> above), the next set (or “column”) will apply ie 24 for take-offs, and 18R + 18C for landings.<br />
<br />
Again, if wind conditions prevent this configuration use, the next set will be used (18L for take-offs, 18R and 18C for landing).<br />
<br />
This test of runway sets against wind values will continue with the rest of the sets in the schedule until a valid one is found and applied.<br />
<br />
It is necessary for each of the <takeoff> and <landing> entries to have an equal number of runway values, per schedule, so each set contains the same number of runways.<br />
<br />
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAMbEsE46ontK4G43zmrEqLEk%3D8ZK5sQ-vxZup%3DNjpaUDgb-ASw%40mail.gmail.com/#msg37166996 Source from Durk post in Devel]<br />
<br />
<br />
= Model Animation =<br />
<br />
To assist with creating realistic aircraft behaviour, some properties are set by the Traffic Manager during particular flight phases as follows<br />
<br />
{| class="wikitable"<br />
|-<br />
! Property !! Description !! Type !! At Gate !! Taxiing !! Take-off !! Cruise !! Approach and Landing<br />
|-<br />
| gear/gear[0..5]/position-norm || Gear Position || double (interpolated over 10 seconds || 1.0 || 1.0 || 0.0 (above 400ft) || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| surface-positions/flap-pos-norm || Flaps position || double (interpolated over 20 seconds || 0.0 || 0.0 || 0.5 (below 2000ft) || 0.0 || 1.0 ( below 2000ft)<br />
|-<br />
| surface-positions/spoiler-pos-norm || Spoiler position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (on runway)<br />
|-<br />
| surface-positions/speedbrake-pos-norm || Speedbrake position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| controls/lighting/beacon || Beacon || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/cabin-lights || Cabin lights || bool || true || true || true || false || false<br />
|-<br />
| controls/lighting/landing-lights || Landing lights || bool || false || false || false || true || true<br />
|-<br />
| controls/lighting/nav-lights || Navigation lights || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/strobe || Strobes || bool || false || false || true || true || true<br />
|-<br />
| controls/lighting/taxi-lights || Taxi lights || bool || false || true || false || false || false<br />
|}<br />
<br />
= SIDs / STARs =<br />
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 flight path, 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 way points. <br />
<br />
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-concept data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of this data. Note that this data is meant to be just that; a proof-of-concept. User contributions will be accepted as soon as the format has stabilized.<br />
<br />
= Appendix: Special Notes =<br />
<br />
<br />
== Performance ==<br />
With recent versions of FlightGear, we have much better performance than before 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. <br />
<br />
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.<br />
<br />
= Related content =<br />
* [[Airports with ground networks]]<br />
* [[FGAirports]] - A groundnet editor<br />
* [[Flightplan XML formats]]<br />
* [[Status of AI in FlightGear]]<br />
<br />
<br />
[[de:Interaktiver Verkehr]]<br />
<br />
[[Category:AI Traffic]]<br />
[[Category:FlightGear feature]]<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=File:Following_slowdown.png&diff=141259File:Following slowdown.png2025-01-21T13:23:59Z<p>Portreekid: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=A diagram showing the braking of a following aircraft}}<br />
|date=2025-01-21<br />
|source={{own}}<br />
|author=[[User:Portreekid|Portreekid]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-4.0}}<br />
<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=File:Ai-windrose.png&diff=141258File:Ai-windrose.png2025-01-21T13:23:59Z<p>Portreekid: Uploaded own work with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=A diagram showing an aircraft and different szenarios based on heading}}<br />
|date=2025-01-21<br />
|source={{own}}<br />
|author=[[User:Portreekid|Portreekid]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-4.0}}<br />
<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=AI_Traffic&diff=141257AI Traffic2025-01-21T13:19:21Z<p>Portreekid: /* Ground networks */</p>
<hr />
<div>{{AI Navbar}}<br />
<br />
'''AI Traffic''' (Artificial Intelligence), '''AI-Traffic''', or '''Interactive Traffic''' was introduced with [[FlightGear]] version 0.9.5. The purpose of AI traffic is to automatically populate airports sceneries with animated aircraft models reflecting the actual daily movements at and between airports to enrich the flightgear experience and improve its realism. This page aims at providing the documentation needed to populate airports with AI traffic.<br />
<br />
In essence, the AI controlled traffic system is comprised of four elements: <br />
# AI Aircraft models: Are part of the base package under <tt>$DATA/AI/Aircraft</tt> and cannot be flown by end user like regular FDM models as they are dedicated and exclusive to AI systems. <br />
# AI traffic schedules: Are part of the base package under <tt>$DATA/AI/Traffic</tt> and define where and when AI aircraft should fly. Files are unique per Operator's ICAO and split in sub-folders using the ICAO Initial. For example, traffic for United Airlines is stored under <tt>[[$FG ROOT]]/AI/Traffic/U/UAL.xml</tt> <br />
# Groundnets: Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and contain the information required to guide AI aircraft on the ground from gates to runways and vice versa, at each individual airport (one per airport). The parking stands defined in an airport groundnet can also be used as Starting Positions when flying an FDM aircraft. They are shown and can be selected in Flightgear's "Location" startup tab.<br />
# Runway Use Configurations (RWYUSE): Are part of the scenery pack under <tt>[[terrasync]]/Airports</tt> and condition which runway(s) are for AI take off and landings based on the time of the day and wind conditions.<br />
<br />
<br />
<br />
= Traffic Schedules =<br />
Traffic pattern describe the relationship between two separate entities: Aircraft and Flights.<br />
<br />
In real life, Flight Scheduling aims at maximizing the number of flights operated with the fleet of aircraft available, taking in account each aircraft’s initial location, the length of each flight, the required turnaround time at each airport and of course the routes operated. In practice an aircraft will fly different routes of different length on different day/time and not all aircraft will return to their home base the same day, especially in the case of long haul routes. The list of flights an aircraft will operate during a set period of time is the Aircraft Schedule.<br />
AI aircraft provide some extra benefits: They do not need maintenance (or crew replacement) and so can be scheduled for use 24h00 per day; they are also never late nor cancelled hence they will perform 100% of their assigned flights on time.<br />
<br />
To minimize the amount of data handled, a frequency is attached to each flight as either daily or weekly; For example an aircraft based at EHAM can fly daily in the morning to EGLL (and back) but then to different destinations in the afternoon depending on the day of the week (LFPG on Monday, EDDF on Tuesday etc). In this scenario the EGLL flights are operated daily and the LFPG and EDDF ones, weekly as it will take another full week before they are operated again.<br />
<br />
Like in real life, the flights assigned to an aircraft must follow a logical routing sequence and the arrival city of one flight must be the departure city of the next (AI aircraft do not time travel no teleport). <br />
Flightgear schedules are set for a full week and repeat indefinitely until the traffic file is updated. As a result, the routing sequence described above must be consistent with the schedule weekly reset: If the last flight in an aircraft schedule (Sunday night) take it to KSFO then the first flight in the schedule (Monday morning) must depart from KSFO.<br />
From the above. The Home Base of an aircraft is always the departure city of its first flight in the schedule ie the airport it will be departing from for its first flight on Monday morning.<br />
<br />
It is recommended the traffic schedules follow as much as possible reality and so they should include turnaround time at each airport even if an AI aircraft does not require cleaning and refuelling.<br />
<br />
To facilitate scheduling, a new database format was introduced in FlightGear 1.9.0 and flights are no longer directly and rigidly assigned to a specific aircraft (Unique registration). 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.<br />
<br />
<br />
== An example of a traffic file ==<br />
<br />
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:<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCB</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<br />
<flight><br />
<callsign>KLM0765</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>0/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCM</port><br />
<time>0/21:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
<br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>TNCM</port><br />
<time>3/01:25:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>EHAM</port><br />
<time>3/10:50:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</trafficlist><br />
</syntaxhighlight><br />
<br />
== Dissecting the traffic file ==<br />
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.<br />
<br />
=== General layout ===<br />
The general layout of each file should look like the above example.<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<br />
</trafficlist><br />
</syntaxhighlight><br />
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.<br />
<br />
=== Defining the aircraft ===<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<trafficlist><br />
<aircraft><br />
<model>Aircraft/MD11/Models/KLMmd11.xml</model><br />
<livery>KLM</livery><br />
<airline>KLM</airline><br />
<home-port>EHAM</home-port><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<actype>MD11/P</actype><br />
<offset>25</offset><br />
<radius>39</radius><br />
<flighttype>gate</flighttype><br />
<performance-class>jet_transport</performance-class><br />
<registration>PH-KCA</registration><br />
<heavy>true</heavy><br />
</aircraft><br />
<aircraft><br />
...<br />
</aircraft><br />
</trafficlist><br />
</syntaxhighlight><br />
The first lines inside the '''<aircraft>''' definition specify some of the aircraft's performance characteristics.<br />
<br />
* '''<model>''' Here is a path specified to the 3D model that should be used in FlightGear.<br />
* '''<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 aircraft type ('''<actype>''') and paint scheme, but I abandoned that idea, because it didn't turn out to be very compatible with the existing FlightGear model loading code. <br />
* '''<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. <br />
* '''<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 in the routing algorithm. '''[New for Traffic Manager II]'''<br />
* '''<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]'''<br />
* '''<actype>''' A description of the aircraft type reserved for future use in [[ATC]].<br />
* '''<offset>''' Ground offset of the 3D model. Not all aircraft 3D models are built 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.<br />
* '''<radius>''' An estimate of the aircraft's size. This is mainly used at airports for gate assignments.<br />
* '''<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:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''<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:<br />
** '''light_aircraft''' (General aviation prop driven single or twin),<br />
** '''turboprop_transport''' (Commercial Turboprop),<br />
** '''jet_transport''' (Commercial jet)<br />
** '''heavy_jet''' (Commercial jet w/ MTOW > 136tons)<br />
** '''ww2_fighter''' (world war two fighter),<br />
** '''jet_fighter''' (modern fighter aircraft)<br />
** '''tanker''' (tanker aircraft), or.<br />
** '''ufo''' (allows extreme accel/decel capabilities).<br />
* '''<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.<br />
* '''<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.<br />
<br />
=== Defining a flight ===<br />
The Traffic Manager II file formats contains separate sections for both aircraft 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:<br />
<syntaxhighlight lang="xml"><br />
<aircraft> <br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</aircraft><br />
<br />
<flight><br />
...<br />
<required-aircraft>MD11KLM</required-aircraft><br />
...<br />
</flight><br />
</syntaxhighlight><br />
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. <br />
<syntaxhighlight lang="xml"><br />
<flight><br />
<callsign>KLM0769</callsign><br />
<required-aircraft>MD11KLM</required-aircraft><br />
<fltrules>IFR</fltrules><br />
<departure><br />
<port>EHAM</port><br />
<time>2/12:35:00</time><br />
</departure><br />
<cruise-alt>330</cruise-alt><br />
<arrival><br />
<port>TNCB</port><br />
<time>2/22:15:00</time><br />
</arrival><br />
<repeat>WEEK</repeat><br />
</flight><br />
</syntaxhighlight><br />
The '''<flight>''' 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:<br />
* '''<flight>''' All the relevant parameter should be specified between the '''<flight></flight>''' keywords.<br />
* '''<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''').<br />
* '''<required-aircraft>''' The key that links this flight to a particular aircraft. The see explanation in the ''aircraft'' section. <br />
* '''<fltrules>''' Can be ''IFR'' or ''VFR''. This is required for use in ATC, but currently not used. This is likely to change, however.<br />
* '''<departure>''' Definition of the departure airport. This section should contain the '''<port>''' and '''<nowiki><time></nowiki>''' keywords.<br />
* '''<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. Values are in [https://en.wikipedia.org/wiki/Flight_level flightlevels]<br />
* '''<arrival>''' Same as '''<departure>''', but now defining the '''<port>''' and '''<nowiki><time></nowiki>''' of arrival.<br />
* '''<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.<br />
* '''<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. <br />
* '''<nowiki><time></nowiki>''' 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 unpredictable. Times should be in UTC. Weekdays start on Sunday (0) and end on Saturday (6).<br />
<br />
== Putting it all together: Including a traffic file ==<br />
Traffic files are found under [[$FG_ROOT]]/AI/Traffic. The actual traffic files should be stored in a subdirectory one level below /AI/Traffic.<br />
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.<br />
<br />
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 aircraft with airlines tags AAL and another series with tag DAL. Similarly, certain flights in the file will be numbered AAxxxx or DLxxxx.<br />
<br />
= Ground networks =<br />
<br />
[[File:LFPG T2E ParkPos.jpg|thumb|Using a Groundnet, AI aircraft can park precisely at the Terminal gates]]<br />
<br />
Using the traffic files information above, the AI Traffic Manager knows which AI aircraft should land at (and take off from) each airport and when. It will automatically place the relevant aircraft models in the scenery and animate them so they navigate from the runways to the gates and vice versa, according to their individual schedule.<br />
<br />
Although the physical layout of each airport is stored in FlightGear's APT.DAT master file, the information is not accurate enough to determine which specific routes AI models can use; Instead, Traffic manager will rely on a dedicated file containing a simple wireframe/network of taxiways and gates AI aircraft can follow whilst on the ground ie a GroundNet. A groundnet is made of 3 different elements: Parking Positions, Nodes and Segments (to join nodes and Parking together). <br />
<br />
This routing information is aggregated, per airport, in a XML, stored and distributed by Terrasync as '''/Terrasync/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml''' where ICAO stands for the 4 letter ICAO code of the relevant airport.<br />
<br />
Similarly to Terrain and Objects, Terrasync groundnets can be overridden by placing a personalized version in your custom scenery folder, using the same path structure: /Custom Scenery/Airports/[I]/[C]/[A]/[ICAO].groundnet.xml.<br />
<br />
Groundnets are not mandatory but, in absence of this routing information, AI Aircraft cannot park anywhere; they will still try to stick to their schedule, appearing magically at the centre of the airport and taxiing directly to the runways’ thresholds, over grass, buildings and static objects, on time.<br />
<br />
Groundnets rely on the runway threshold information stored in /Terrasync/Airports/[I]/[C]/[A]/[ICAO].threshold.xml to determine where runways are (the space between each pair of thresholds in the file) and their heading. This data is used to determine an aircraft has reached the runway and can initiate take off. Similarly it is used to select where an arriving AI aircraft can touch down and start braking. <br />
<br />
== A technical perspective ==<br />
A ground network xml file consists of four tables:<br />
* '''<frequencies>''' The Airport’s radio frequencies (Optional). As of v1.9.0, FlightGear uses these to display some ATC messages like start-up approval requests. You can "hear" them by tuning to the first ground frequency listed in the section.<br />
* '''<parkingList>''' The details of each parking/gate at the airport and the characteristics of which AI aircraft can use them.<br />
* '''<TaxiNodes>''' The list of all the nodes in the ground network.<br />
* '''<TaxiWaySegments>''' A list of all links/segments (or "arcs" as David Luff called them initially) existing between all nodes and Parking Positions.<br />
<br />
Each Parking and Node element in the groundnet has a unique index number, allowing routes be formed (from one ID to the next via a segment/arc) between parking positions and runways <br />
<br />
''Parking Positions Parameters:''<br />
* '''index''' Unique ID, internal to the file structure<br />
* '''lat''' latitude in decimal minutes format, for example <code>N50 56.988</code>)<br />
* '''lon''' longitude in decimal minutes format, for example <code>W01 21.756</code>)<br />
* '''name & number ''' (gate identification as found on airport charts, for example <code>D23</code> or <code>C1</code>). <br />
* '''type:''' The type of aircraft which can use this space. Matched to the <flighttype> parameter found in traffic files:<br />
** '''ga''' (general aviation), <br />
** '''cargo''' (cargo/freighter)<br />
** '''gate''' (commercial passenger traffic) <br />
** '''mil-fighter''' (military fighter)<br />
** '''mil-cargo''' (military transport)<br />
* '''heading:''' The heading at which the aircraft parks in this space.<br />
* '''radius:''' The size of the parking spot. Matched to the aircraft <radius> parameter in traffic files to determine if a given AI Aircraft model will fit the position. See [[aircraft radii]]<br />
* '''airlineCodes:''' a comma-separated list of ICAO airline codes allowed to park at this gate. Matched to the aircraft <airline> parameter of traffic files. Leave blank for all airline to be able to use the gate.<br />
* '''pushBackRoute:''' The ID of the next node in the network along a pushback route. 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.<br />
<br />
''Nodes parameters:''<br />
<br />
* '''isOnRunway'''' A logical value that is 1 when the node is on the runway, 0 otherwise. Aircraft waiting to take off will line up behind the last node marked “not on runway” (“0”) until the runway is clear<br />
* '''holdPointType''' can have the following values:<br />
** '''None''' Not a holding point (normal taxi-through node) <br />
** '''PushBack''' The node marks the end of a pushback route, where the aircraft stops rolling backward and start rolling forward upon clearance. A pushback Holding Point can be part of more than one pushback route. See Pushback below. <br />
** '''Normal''' (Not yet supported): a regular taxiway holding point.<br />
** '''CAT II/III''' (Not yet supported): a special holding point for IFR conditions.<br />
<br />
''segments parameters:''<br />
<br />
* '''begin''' The id of the parking space or AINode where this segment starts<br />
* '''end''' The id of the parking space or AINode where this segment ends<br />
* '''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.<br />
* '''name''' Name of the taxiway.<br />
<br />
== Tools & Source Material ==<br />
Groundnets can be built using either FG Airports (v0.032 or later) or Taxidraw (legacy) <br />
<br />
[[FGAirports]] is the current tool of choice. Its philosophy is airport centered rather than file specific and allows you to visualize at a glance all of the existing groundnets as well as editing them and submitting them to Terrasync. It leverages Open Street Map data, APT.DAT and scenery xmls to provide a visual representation of the airport layout as well as thresholds and tower positions. <br />
<br />
FGA automatically checks the validity of groundnet files before submission and assess their adequacy by comparing the number of gates set against the volume of AI traffic at a particular airport.<br />
<br />
[[TaxiDraw]] pre dates WED and allowed the creation of airport layouts from basic geometrical shapes. Its ground network module is somewhat separate from the rest of the airport project code but allows the creation and local export of simple groundnets.<br />
<br />
See the [[TaxiDraw]] and [[FGAirports]] articles for instructions on how to obtain the tools and operating instructions.<br />
<br />
Most Civil Aviation authorities make electronic versions of their Aeronautical Information Publication available on the web (Lookup 'eAIP' or go to https://www.eurocontrol.int/articles/ais-online). AIPs contain precise Airport Charts but also lists of parking stands with their exact Latitude/Longitude as well as usage (Cargo, Gate) and the category (radii) of aircraft they can accommodate.<br />
<br />
Gates Numbers and Airlines operating them can often be found on Airports website. Most flight tracking sites/apps will also allow you to monitor a flight all to the way to its gate to identify who parks where.<br />
<br />
In essence, all the information you need can be compiled from multiple sources, including Wikipedia, airport diagrams published on the net, in flight airline magazines, etc. etc. In other words, be creative!<br />
<br />
== Ground traffic rendering ==<br />
''19th November 2021.''<br />
<br />
=== Performance ===<br />
<br />
* CPU: Currently having a lot of nodes in the OSG scene-graph will rapidly make FlightGear CPU bound. A lot of separately animated ground traffic objects mean a lot of nodes. Static objects (i.e. non-animated objects) can be put into one mesh - meaning one scenegraph node with the current system.<br />
* GPU: Having fewer draw calls is fast. Having fewer state changes is fast. <br />
* The fast path for both CPU and GPU is creating a way to combine multiple animated objects in one mesh - this is how modern 3d applications do lots of objects with animations fast.<br />
<br />
=== The fast way to do moving objects is to let the vertex shader look at information in buffers and position each object ===<br />
<br />
* Have all the different path segments stored in one buffer that can be read by the vertex shader. This buffer can be generated at runtime for each airport, maybe using NASAL scripts, and not updated.It's also possible to store the 1st buffer in TerraSync. <br />
* Have a second buffer store all per-object data in an array. The array is indexed by the object ID. This includes things like vehicle animation state, which path segment each object is on, the starting time, and a speed scaling factor. The second buffer is updated regularly by the CPU.<br />
* Two approaches to packing different types of objects in a 1 or few meshes <br />
**'''a).''' Every type of object is combined in one vertex buffer and rendered with the same shaders, texture atlas or array. Every vehicle is packed one after the other in the vertex buffers. Multiple types of vehicles are contained in the same mesh. Multiple instances of the same vehicle take up extra space. <br />
*** All material parameters or uniform values that change between objects, or within objects, like specularity are added as vertex attributes or textures. A vertex shader that can handle all object animations is used. <br />
*** The entire set of objects takes up one scene graph node, and is rendered in one draw call. It's possible to do ground vehicles and AI aircraft as two meshes.<br />
*** The object ID (an integer) can be added to each vertex as an vertex attribute. This is used to lookup per-object info in the 2nd buffer, including the paths from the first buffer.<br />
** '''b).''' Each different type of object (different ground vehicle) is instanced and takes up one scene-graph node. This can allow different shaders and textures per object type. There is less vertex data taking up RAM and VRAM. There are more scenegraph nodes, and draw calls.<br />
*** The object ID (an integer) can be added as a per-instance vertex attribute.<br />
* The vertex shader can trivially look at the object ID, then find the path segment, the starting time, speed scaling factor, and current time to position each object. If the current time is past the end of the current path, the object will stay at the end position.<br />
* The buffers can be a uniform array (minimum of points in each path segment and more smoothing), Uniform Buffer Object (UBO - not available until Vulkan due to Macs not supporting it), a Texture Buffer Object (TBO - Mac support unknown), or a texture looked up in a vertex shader (maybe slower).<br />
* Data format: Each path segment is x,y,z position at regular times - a time-series of positions - e.g. [10m, 20m, 0m elevation] at t = 1s. [20m, 25m, 0m] at t=2s . [30m, 30m, 0m] at t= 3s. 16 bit integers are enough, but 32 but floats can also be used at the cost of 2x the occupancy. 16 bit implementation: If a texture is used it can be 16bit RGB - R=x, G=y, B=z. 2 consecutive 8 bit values can also be read from a texture.16 bit integers can cover an ground traffic area of ~65km with a spacing of 1m. 16bits can give a ~13km ground traffic area with an accuracy of 20cm. The accuracy of the positions doesn't matter too much - the vertex shader can look at 2-3+ path positions and create a smooth interpolation (a smooth curve joining the points). The time steps can also be large. <br />
* If a path has a slowly moving segment, it will take up more points. If a path segment takes a short amount of time, it can have a special xyz numner to indicate path has ended - otherwise the path start/end time information can be stored as uniforms or in a UBO. Vehicles that move faster can have a higher speed scaling. There can be different path segment variations, for example if vehicles have a different acceleration pattern - e.g. speeding up and braking hard, or sharper turns, in an emergency.<br />
* Both ground vehicles, and taxiing aircraft can be done this way. It's possible to replace a conventional AI aircraft model, with a fast rendering ground traffic model once an aircraft starts taxiing.<br />
* If models use animations, they should ideally use a vertex shader that can handle all these animations - so having multiple draw calls per model and CPU-side animation is avoided.<br />
* It's possible to split of different parts of craft into separate meshes for parts that are very dissimilar - at the cost of more scenegraph nodes and draw calls. For example, a separate mesh for lights of various types - these lights will follow the same paths as the vechiles and position themselves correctly.<br />
* <br />
<br />
<br />
<br />
The way animation is handled (animation meaning moving objects, and parts of moving objects) in modern 3d application is to store the animation data in arrays/buffers on the GPU side and render multiple objects in one draw call.<br />
<br />
From a quick google search - a 2010 blog about whether UBOs or TBOs are more suited for different tasks:<br />
<br />
''"Personally I use them [UBOs] for instanced rendering by storing the model-view matrix and related information of each and every instance in a common uniform buffer and use the instance id as an index to this combined data structure. This usage performs very well on my system.''<br />
<br />
''Also uniform buffers can be used to store the matrices of bones and use them for implementing skeletal animation, however, I personally prefer using normal 2D textures for this purpose to take advantage of the free interpolation thanks to the dedicated texture fetching units but that’s another story.''<br />
<br />
''[..] Personally I use texture buffers for different geometry deformation techniques, to resolve batching issues when the size limitation of uniform buffers is a blocking factor, and for some inverse kinematics effects." - Rastergrid blog, 2010 [https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/][https://web.archive.org/web/20211119134448/https://www.rastergrid.com/blog/2010/01/uniform-buffers-vs-texture-buffers/]''<br />
<br />
This is from a 2010 blog - this general approach has been the way to do lots of animated objects for a long time. <br />
<br />
Even really complicated animations like moving bodies and cloth physics are handled by moving animation data into buffers - this approach would be needed if FlightGear ever did a simulation of crowds at an airport - not just for boarding one plane which probably won't be too cripplingly slow. But for crowds boarding lots of planes, and moving about large airports. For animating humans, there are will be standard animation formats compatible with output of tools in blender or make human[http://www.makehumancommunity.org/]. This approach may also be worth while for rendering lots of seated passengers with really simple movements - and a few walking about with a simple walk cycle. It may also be justified for large amounts of ground personnel at big airports (not just a few relevant for the users plane).<br />
<br />
== Warnings and Limitations ==<br />
The complexity of building a fully functional groundnet (and the time spent on it) grows exponentially with the size of the airport but very small airports, on Pacific Islands for example, pose even larger challenges. An ideal project to start with is a Metropolitan airport with one or two runways, and two dozen of parking positions. <br />
<br />
FG Scenery and Traffic manager have their limitations and dependencies which create specific challenges of their own. For example:<br />
[[File:AI Traffic at KJFK former Terminal 3.jpg|300px|thumb|AI Traffic sitting on top of KJFK former Terminal 3]]<br />
* TM does not space landing aircraft. You will most likely see packs of landing aircraft hitting your runways at once, sometimes from both ends. Departures are spaced properly though <br />
* TM does not yet use Regular/Cat III Holding points data and so you cannot force an AI aircraft to pause/hold on a route. <br />
* TM does not support the conditional use of gates (Do not use A if B is occupied); Always assume all the Parking position you set will be occupied. <br />
* AI Aircraft cannot "pivot" on their parking positions. The last segment on a route leading to or exiting a parking position must have the same heading than the parking position itself (Park Straight) <br />
<br />
* Groundnets, terrain and scenery objects are independent. If you see your AI aircraft rolling on grass or sitting on buildings and for as long as your groundnet lat.lon data is correct, consider that the airport terrain/layout may be outdated or misplaced. Similarly, Building/Object may have been placed at certain Lat/Lon but since demolished (example of JFK Terminal 3 on the right) to make space for a new taxiway as airports expand and change layout regularly.<br />
<br />
Make sure you have verified the data in your ICAO.threshold.xml before starting building your groundnet. If the data is incorrect, locate the correct one on the web and post a request for adjustment in the FlightGear AI forum with a link to the correct data source.<br />
<br />
Your candidate groundnet will need to be tested thoroughly by running it in FG, at different time of the day as wind conditions and traffic patterns will impact which runways are used and how many AI aircraft are handled. <br />
You should have log/debug enabled as traffic manager will create :ai entries, allowing easier troubleshooting.<br />
<br />
On the bright side, both Taxidraw and FG Airports contain a validation tool which will allow you to detect any structural problem with your groundnet. You will also find a lot of resources and tips in the AI section of the Flightgear forums.<br />
<br />
Finally, the approach to creating a groudnet is described below as three separate phases, each one including its own specific testing which will hopefully simplify your journey.<br />
[[File:Gate Definition in FG Airports.png|300px|thumb|FG Airports UI for Parking Position]]<br />
== Creating the base network == <br />
<br />
Objective:<br />
* You have enough gates for all AI aircraft using the airport<br />
* Each gate has a valid incoming and outgoing link (route) to the rest of the groundnet<br />
* Each Runway(s) threshold has a unique link to the rest of the groundnet<br />
* Departing Aircraft can reach any threshold, from any parking position <br />
* Arriving Aircraft can reach any suitable parking position from any threshold<br />
<br />
<br />
'''Step 1 : Place and configure the Parking Positions'''<br />
<br />
Place a parking position at each location an aircraft is allowed to park. Use your AIP Lat/Lon data and/or the FGA OSM background for extra precision.<br />
[[File:Extend Route passed Displaced THR.png|thumb|Example of route ended after a displaced Threshold]] <br />
AI Aircraft will be positioned so their centre of rotation (main gear and/or X=0 in .ac model file) sits at the Lat/Lon defined for the parking position.<br />
<br />
Set a type for each off your gates: GATE if the stand is used by commercial traffic or CARGO if used by freighters. <br />
Military and General Aviation can also be used if you are running personalized traffic files on your machine.<br />
<br />
Adjust the heading and radius for each of your gates according to the maximum wingspan the stand can accommodate. See [[aircraft radii]]. <br />
Set a unique name for the gate.<br />
Leave the AIRLINE field empty at this point.<br />
<br />
'''Step 2 : Place and configure the Runway accesses'''<br />
<br />
AI aircraft need an access route to each threshold of each runway you want them to use for take off or landing. Your groundnet will need at least one route to one threshold for validation.<br />
<br />
At this stage, place only two access route per runway, one at each end, do not create routes starting/ending hallway (to vacate the runway at midpoint).<br />
Your access routes will be used to ‘guide’ the aircraft all the way to a final node at which point it will be ‘handed over’ to the tower, start accelerating and take off.<br />
This final node of each access route (Take Off Point) must sit within the runway thresholds. If not, departing aircraft will simply stop and queue at the entrance of the runway. This is crucial when dealing with displaced thresholds. As a rule of thumb, your access route should end up on the white marking indicating the runway number/identification.<br />
<br />
Backtracking: Certain airports do not have taxiways along the runway and aircraft will 'backtrack' on the runway itself to reach the threshold (often circling on a turnaround area to align for take off). In this scenario, you still need a route to guide your aircraft all the way to the take off node by placing nodes and segments on the runway and the the turnaround loop area. Make sure your loop starts (exits the runway) ahead of passing the final take off node: see an example [[:File:Using_the_runway_to_backtrack_to_the_threshold.jpg|HERE]].<br />
<br />
Your access routes (all routes at this stage in fact) must be bi directional so they can also be used for aircraft to vacate the runway if they taxi all the way to the threshold.<br />
[[File:Multiple Route leading to a single Threshold.png|thumb|Runway access routes must be unique]]<br />
Your access route must be unique: Traffic manager does not handle intersections (nodes with 4 routes) very well. Your take off points should not be connected to more than one route (case of taxiways on both sides of the runway feeding a single take off point from both sides as shown on the right.<br />
<br />
Select each of the nodes placed on the physical runway (not the ones leading to it) and mark them "On Runway" with the toggle in their properties panel <br />
<br />
'''Step 3 : Connect ParPos and Runway Access routes to form the groundnet.''' <br />
<br />
Link each of your parking positions and runway access routes by marking the taxiways with segments, avoiding sharp 90 degrees angles by breaking curves into 2 or 3 segments.<br />
Keep the network as unconstrained as possible; Make all segments bi-directional, do not include any holding points (Pushback, Regular or Cat III) and do not mark any segment as pushback; At this stage, the idea is to give AI aircraft as many routing options as possible.<br />
<br />
Nodes should be placed only at points where the aircraft will change heading so they should be none in the middle of straight routes and definitely none at taxiway crossings.<br />
<br />
Segments starting (or ending) at a parking position must have the same heading than the parking stand. AI aircraft park straight and leave their parking straight (rolling forward or pushing back).<br />
<br />
Your groundnet does not need to cover 100% of the airport taxiways; certain areas (like De Icing stations or Engine Test Areas) will not be used by AI aircraft. In essence draw just enough routes so that all gates and runways are connected.<br />
<br />
'''Step 4 : Visual Check'''<br />
Once your base groundnet complete, Check visually that your parking positions do not overlap, that nodes placed on physical runways are marked as such and that intersections are formed properly (no node unless the aircraft can turn here)<br />
<br />
'''Step 5 : Structural Check and Test'''<br />
<br />
Run the verification tool (available in both Taxidraw and FGAirports). Both programs will ensure at this stage that routes are valid and that nodes on runway are marked as such. <br />
Taxidraw does not check the routes structures individually but rather that a route solution exist: If an aircraft can use different path/routes to go from its ParkPos to a given runway threshold and even if one of these routes is "broken" (unconnected segments) no error will be reported, because the aircraft could use another (unbroken) route to get to the threshold and hence still has a routing solution.<br />
<br />
FGAirports will do the same routing check but will also signal any unconnected node (broken routes). <br />
Correct the errors found and re run the verification tools until no more problems are found.<br />
<br />
Time to test with 'real' traffic. Save your groundnet and export it to a custom scenery folder (NOT to the Terrasync Folder), usually something like F:\My Sceneries\Airports\S\B\SBGR.groundnet.xml.<br />
Startup Flightgear and add your custom scenery folder path (the parent of \Airports) to your extra sceneries list in the Add On screen. Select your Airport as Startup Location. Run <br />
<br />
What to expect (normal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
[[File:Base GRoundnet Visual Check.jpg|border|right|950px|Base Taxidraw Groundnet for SBGR]] <br />
* Parked aircraft will start appearing on the parking stands you have set. Departing aircraft will light up (red/green nav lights on wing tips, flashing beacon on top)<br />
* Upon ATC clearance (automatic) Departing aircraft will roll forward into the terminal buildings then dance around a bit then join a taxiway and head for a threshold. The route they will use may not be the shortest nor the one you expected but it will be a route you have set.<br />
* Departing Aircraft will queue up at the threshold. The first in line will enter the runway, accelerate (strobes lights activate) and take off. Aircraft will climb in a straight line and after +/- 10 seconds, change heading. At this point, the next aircraft in line will enter the runway and initiate its take off<br />
* Arriving aircraft will start landing. The touchdown position will depend on the type of aircraft. Arrivals are not spaced out and you can see more than one aircraft landing at once on a single runway. After slowing down, they will taxi all the way to the end of the runway, exit via the access route you have set then head for an available parking position. Again the route they will use may not be the shortest or the one you expected and they may not park where you wanted. Once parked, Nav Lights will turn off<br />
* At any given intersection (4 or more segments sharing a node) and at any time during the test, one aircraft will get stuck. Aircraft following it will start queueing. The intersection will remain clogged and AI taxiing stuck until you decide to shut down Flightgear.<br />
* Aircraft will taxi from both directions on single taxiways, eventually passing through each other<br />
* On larger airports where AI aircraft can use more than one route to go from one point to another and/or can park at multiple aprons they will show a geographical preference (normally North West) so parking and routes in this area will be busier. <br />
What to look for (abnormal behaviour with base groundnet, if FG has AI traffic at the airport):<br />
* Aircraft appearing in the middle of the airport and not following taxiways (not enough Parking Positions or not suitable in size or type CARGO/GATE)<br />
* No aircraft (no AI traffic at this airport or not activated in FG options)<br />
* Aircraft queue up at runway but do not take off (Misplaced Threshold in ICAO.threshold.xml)<br />
<br />
<br />
=== Refining the network: Routing Flow & Baggage Carousels Belts === <br />
<br />
Objective:<br />
* All Objectives in the "Creating the base Network" section<br />
* No clogging at intersections<br />
* No Head on crashes of aircraft sharing a single taxiway<br />
<br />
The traffic manager code is not fully documented nor maintained so only repeated testing (and discussions on the FG AI Forum) will allow you to form and understanding of the way AI aircraft will behave based on the type of groundnet data you feed them. This is an interesting but potentially frustrating exercise.<br />
<br />
You will eventually realize that AI traffic has a “mind of its own” which fluctuates between two extremes: <br />
* AI traffic cannot make decisions: Typically, where presented with multiple routing options (an X intersection with 4 or more valid routes), AI traffic will consistently freeze/clog after some time if not immediately.<br />
* AI traffic does not stand bullying: If presented with no alternative at all (too many unidirectional routes) AI traffic will move away from your groundnet taxiways and start mowing the lawns. <br />
<br />
<br />
[[File:Groundnet Routing Flow Example.png|border|right|950px|Groundnet Routing Flow Example]]<br />
Keeping these two constraints in mind, the clogging and head on collisions noted in your previous tests can be addressed by setting up a ‘Routing Flow’. The purpose of said routing is to guide each aircraft to their final destination (Parking or Threshold), by ensuring it uses a single route and never crosses any other aircraft path.<br />
To achieve this we only have and need two tools: The ability to force the direction of traffic on any given segment (by making it “unidirectional”) and the ability of Traffic manager to handle priorities and queues formation at routes merging points (Y shaped intersections).<br />
<br />
The complexity of Routing Flow will increase exponentially with the number of gates, thresholds and traffic files handled: A single groundnet flow must accommodate indifferently a cargo flight arriving on RWY 1 in the evening or a commuter departing from RWY 2 in the morning.<br />
<br />
To better understand how efficient routing is achieved, draw on your experience at an airport Baggage carousel (or at a ‘Sushi Train' restaurant) where all bags arrive from one or two tunnels onto a moving belt and are then distributed to passengers waiting around the carousel. <br />
That is all bags (Aircraft) arrive from a limited number of tunnels (Thresholds) and can reach any standing passenger (ParkPos) using a single belt (routing flow). It does not matter where the passenger stands nor what order the bags arrives in; if you wait long enough all bags will meet their owner, (unless you are at Heathrow).<br />
<br />
An advantage AI aircraft have over bags is that they can ‘transfer’ from one belt to another if a segment belongs to more than one belt/route. Putting it visually, a typical routing flow will resemble something like the image on the right : ‘Belts’ in green rotate clockwise, red ones rotate counter clockwise, segments in blue provide access in and out of the belts. The main belt along the northern runway includes bypasses allowing an aircraft to quickly reach the other side of the belt without having to travel its full length.<br />
<br />
Using the diagram, you can pick any combination of one runway access (threshold or intermediate vacating point) and one parking position and realize you can always find a unique route from A to B and another unique route from B to A without ever coming across an intersection, always using "Y" shaped merging lanes.<br />
<br />
[[File:Apron Belt at Bahrein Intl.png|left|thumb|Using the Belt technique to feed the OBBI apron]] <br />
An additional benefit of the technique is visible when comparing the routing flow diagram and the base network image in the previous section: A groundnet with proper routing uses less nodes and segments than a full network, saving you time during the building phase. In fact, as you get more familiar with the technique you will realize it is a good idea to map your routing flow before building your groundnet so you create just enough nodes and segments. It is also important to know that you do NOT need to mark each and every segment as "unidirectional" but only the ones forming your Y shaped intersections.<br />
<br />
The belt technique can easily be adjusted to the specific shape of different airports: All of KJFK’s traffic is routed with only 2 belts set as concentric rings running in opposite directions. The inner ring connects all the aprons in an infinite loop; the external ring connects all the runways in a similar loop. A small number of “transfer belts” allow aircraft to move from one belt to the other.<br />
<br />
You can have a look at existing groundnets’ routing to better understand how this technique can be applied to your project. VVNB has the most basic version; LEMD and LFPG have very elaborate ones.<br />
<br />
Certain smaller airports do not have enough taxiways to allow the formation of a proper global belt but the technique can be used on individual aprons to ensure proper flow in and out of parking areas and simplify the design of pushback routes (next section) as shown on the image on the left, at Bahrein Intl.<br />
<br />
Testing : Once your routing flows in place you should re-test you groundnet. The expected behaviour is the same then the one described in the “Base Network, Step 5” section, with the exception of head on collisions and clogged intersections which should no longer exist<br />
<br />
<br />
=== Refining the network: Pushback routes ===<br />
<br />
'''THIS SECTION IS WIP'''<br />
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. Pushback routes are optional (if you like the terminal crashing scenario described above).<br />
<br />
'''Examples of simple valid pushback routes''' (Left: If the taxiway is bidirectional | Centre: If the taxiway is not bidirectional | Right: With shared Pushback Holding point)<br />
<br />
[[File:MultiDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid AI Groudnet pushback for multi directional taxiway]] <br />
[[File:UniDirectionnal Pushback Route in Taxidraw.jpg|400px|Valid Pushback Route on Un directional taxiway]]<br />
[[File:Shared Pushback Holding Point in Taxidraw.jpg|400px|Shared Pushback Holding Point]] <br />
<br />
[[File:Roll Forward Gate in Taxidraw.jpg|thumb|Invalid Park Pos Exist route : at and angle with Parking Position]]<br />
===== Pushback Holding Points must be unique per Parking Position =====<br />
<br />
Each Parking space (ParkPos) can't have more than one push back route and one pushback holding point at the end of the route. Nevertheless, multiple Parkpos can share part of their pushback routes and a single Pushback Holding Point.<br />
<br />
The formal criteria for a valid push back route is that each gate should have a maximum of one push back holding point associated with it, which can be reached using one route only.<br />
From an editing point of view, mark all segments between your parking position and its final holding point as "push back", do not forget to mark the ending node as Pushback Holding Point.<br />
<br />
===== The AI code does not handle sharp angles =====<br />
<br />
Add nodes to smoothen your routes so that no consecutive segments form an angle of less than 90 degrees. <br />
This rule applies to both pushback and roll forward / taxiways routes <br />
<br />
===== The Inbound route and the outbound routes are parallel ===== <br />
[[File:On Taxiway Pushback Holding Point in Taxidraw.jpg|thumb|Invalid Groudnet Pushback : Holding Point on Taxiway]]<br />
<br />
The last segment of the pushback route will condition the aircraft heading:<br />
<br />
1. During its travel along the pushback route <br />
<br />
2. At the Pushback Holding point (whilst waiting for clearance)<br />
<br />
3. On departing the pushback holding point, rolling forward to the runway.<br />
<br />
<br />
You can not control/force an AI aircraft to leave a Pushback Holding point at a different angle/heading than the one it came onto its final holding node at, whatever the number of routes you add.<br />
<br />
As a result, the last segment of the pushback route must align with the segment you expect the aircraft to use when starting to roll forward after clearance. The simpler set up is to have this final pushback segment overlapping the first segment of the roll forward route.<br />
<br />
Alternatively, the last segment of the pushback route can -itself- be the first segment of the roll forward route but this means Traffic Manager will consider this segment 'reserved' whilst the aircraft is pushing back and no other aircraft will be able to use the taxiway.<br />
<br />
For the same reason the Pushback Holding point should NOT be directly placed on the taxiway as shown in the image on the right 'On Taxiway Pushback Holding Point in Taxidraw'.<br />
Using this particular configuration, once the aircraft 'cleared for taxi', it will ignore the taxiway segments on its left and right and keep its heading, rolling forward towards the original parking position, then 'get lost' and start spinning around, looking for a node to re-anchor to. <br />
<br />
The "Roll Forward on my current heading" rules also applies to Parking position with no pushback route. These are often used for smaller propeller aircraft which "pivot" on their parking position before rolling forward. You cannot currently replicate this pivot behaviour in Flightgear AI <br />
<br />
<br />
It is important to note that the Taxidraw "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 with all aircraft from one side of the E terminal are being linked to one shared push back point. <br />
<br />
Given the current push back system allows for fairly complicated behavior it is advisable to test extensively your groundnet and play with various configurations before sharing it to the community. <br />
<br />
Taxidraw note: TaxiDraw versions prior to February 5, 2009 did export the pushBackRoute attribute correctly. <br />
<br />
[[File:TaxiDraw2.png|thumb]]<br />
<br />
==== Verifying the network ====<br />
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. <br />
<br />
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.<br />
<br />
* '''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.<br />
* '''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. <br />
* '''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. <br />
* '''Check and set pushback nodes''' this function verifies whether any specified pushback nodes adhere to the above specifications and updates some internal consistency.<br />
<br />
=== Copying the ground network into FlightGear's scenery directory ===<br />
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>.<br />
<br />
In Taxidraw menu select File, Export AI Network and save the file in the above folde as ICAO.groundnet.xml. Please note that the File / Save project menu applies only to the airport layout and does NOT save your groundnet.<br />
<br />
=== Testing the network ===<br />
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. <br />
<br />
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.<br />
<br />
=== Airports with ground networks ===<br />
<br />
== Collision Detection == <br />
<br />
Version 2024.1.X and all version prior use an avoidance strategy based on the ground network. This means there are lots of Dijkstra calls to determine the possible route to the runway. Another implication is that the designer of the ground network must ensure the separation. This is of course not possible in pushback or even with the user aircraft. <br />
The next version will get real detection of nearness and integration with ATC. This is based on a Quadtree and just reacts on the current snapshot and not on "future" plans of an aircraft. <br />
<br />
=== Nearness rose ===<br />
<br />
=== Braking ===<br />
<br />
= Runway Usage Configuration = <br />
<br />
ICAO.rwyuse.XML dictates which runway(s) should be used for AI take off and which ones accept AI landings. These instructions are organised in multiple sets (or configurations) and ordered by preference of use.<br />
<br />
Schedules can be defined so different runway configurations can be used at different time of the day. Different Sets can also be applied to the General Aviation and Commercial traffic.<br />
<br />
Each set of runway configuration is tested against the wind conditions and applies only if the crosswind and tailwind are within tolerance. If not, the next set in the order of preference, will be picked.<br />
<br />
Examples below taken from the Amsterdam Schiphol EHAM.rwyuse.xml file.<br />
<br />
Wind conditions are stored at the beginning of the file and indicate the maximum values of Crosswind and Tailwind acceptable to authorize take off and landing at the airport.<br />
<br />
<syntaxhighlight lang="xml"><br />
<wind tail="7"<br />
cross="20" /><br />
</syntaxhighlight><br />
<br />
{{quote|As well as aircraft, airports have operational crosswind and tailwind limits. [] The values vary but crosswind limits are normally 15-25 kts and tailwinds are normally no more than 10 kts.|ICAO|AMOFSG/10-SN No. 14}}<br />
<br />
The < time > table defines the hours of activation for a particular Schedule. Each schedule contains a 'Pattern' ie a fixed number of runways allocated to either take off or landing).<br />
<br />
For instance, at EHAM, the commercial "inbound" schedule is active from 06:20 to 08h30 UTC, at a time where there is more inbound than outbound traffic and the airport needs to allocate more runways to landing than to take off.<br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "06:20"<br />
end = "08:30"<br />
schedule = "inbound"/><br />
</syntaxhighlight><br />
<br />
In most cases, a single schedule can apply 24h every day. <br />
<br />
<syntaxhighlight lang="xml"><br />
<time start = "00:00"<br />
end = "24:00"<br />
schedule = "Day"/><br />
</syntaxhighlight><br />
<br />
<br />
The different sets of runways allocation are listed in each < schedule > table by order of preference and can be read/deciphered vertically as ”columns” delimited by commas.<br />
<br />
When wind conditions do not allow the use of a set, the next one will apply (next “column”).<br />
<br />
Still using the EHAM.rwyuse.xml file as example, from 06:20 to 08:30 UTC, when the Inbound schedule applies; AI traffic will preferably use runway 36L for take-offs, and both 06 and 36R for landings (first “column” of data).<br />
<br />
<syntaxhighlight lang="xml"><br />
<schedule name="inbound"><br />
<takeoff>36L, 24, 18L, 36L, 24, 24, 18L, 09</takeoff><br />
<landing>06, 18R, 18R, 36R, 27, 18R, 18R, 06</landing><br />
<landing>36R, 18C, 18C, 36C, 18R, 22, 22, 09</landing><br />
</schedule><br />
</syntaxhighlight><br />
<br />
Shall wind conditions prevent the use of this configuration (Tailwind or Crosswind values exeeding the ones defined in <wind> above), the next set (or “column”) will apply ie 24 for take-offs, and 18R + 18C for landings.<br />
<br />
Again, if wind conditions prevent this configuration use, the next set will be used (18L for take-offs, 18R and 18C for landing).<br />
<br />
This test of runway sets against wind values will continue with the rest of the sets in the schedule until a valid one is found and applied.<br />
<br />
It is necessary for each of the <takeoff> and <landing> entries to have an equal number of runway values, per schedule, so each set contains the same number of runways.<br />
<br />
[https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAMbEsE46ontK4G43zmrEqLEk%3D8ZK5sQ-vxZup%3DNjpaUDgb-ASw%40mail.gmail.com/#msg37166996 Source from Durk post in Devel]<br />
<br />
<br />
= Model Animation =<br />
<br />
To assist with creating realistic aircraft behaviour, some properties are set by the Traffic Manager during particular flight phases as follows<br />
<br />
{| class="wikitable"<br />
|-<br />
! Property !! Description !! Type !! At Gate !! Taxiing !! Take-off !! Cruise !! Approach and Landing<br />
|-<br />
| gear/gear[0..5]/position-norm || Gear Position || double (interpolated over 10 seconds || 1.0 || 1.0 || 0.0 (above 400ft) || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| surface-positions/flap-pos-norm || Flaps position || double (interpolated over 20 seconds || 0.0 || 0.0 || 0.5 (below 2000ft) || 0.0 || 1.0 ( below 2000ft)<br />
|-<br />
| surface-positions/spoiler-pos-norm || Spoiler position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (on runway)<br />
|-<br />
| surface-positions/speedbrake-pos-norm || Speedbrake position || double || 0.0 || 0.0 || 0.0 || 0.0 || 1.0 (below 2000ft)<br />
|-<br />
| controls/lighting/beacon || Beacon || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/cabin-lights || Cabin lights || bool || true || true || true || false || false<br />
|-<br />
| controls/lighting/landing-lights || Landing lights || bool || false || false || false || true || true<br />
|-<br />
| controls/lighting/nav-lights || Navigation lights || bool || false || true || true || true || true<br />
|-<br />
| controls/lighting/strobe || Strobes || bool || false || false || true || true || true<br />
|-<br />
| controls/lighting/taxi-lights || Taxi lights || bool || false || true || false || false || false<br />
|}<br />
<br />
= SIDs / STARs =<br />
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 flight path, 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 way points. <br />
<br />
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-concept data for EHAM SIDs will be committed to the World Scenery Repository, along with some experimental code in FlightGear to make use of this data. Note that this data is meant to be just that; a proof-of-concept. User contributions will be accepted as soon as the format has stabilized.<br />
<br />
= Appendix: Special Notes =<br />
<br />
<br />
== Performance ==<br />
With recent versions of FlightGear, we have much better performance than before 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. <br />
<br />
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.<br />
<br />
= Related content =<br />
* [[Airports with ground networks]]<br />
* [[FGAirports]] - A groundnet editor<br />
* [[Flightplan XML formats]]<br />
* [[Status of AI in FlightGear]]<br />
<br />
<br />
[[de:Interaktiver Verkehr]]<br />
<br />
[[Category:AI Traffic]]<br />
[[Category:FlightGear feature]]<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=TerraMaster&diff=141185TerraMaster2025-01-03T20:01:57Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
|title = TerraMaster<br />
|logo =<br />
|image = TerraMaster r32 - Global view.png<br />
|developedby = reeed, portree kid<br />
|initialrelease = July 18, 2011<br />
|latestrelease = January 3, 2025 (v3.02)<br />
|writtenin = Java<br />
|os =<br />
|platform = Cross-platform<br />
|developmentstatus =<br />
|type = Scenery manager<br />
|license = [[GNU GPL]] v2<br />
|website = https://portree-kid.github.io/terramaster/<br />
}}<br />
<br />
'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the [[FlightGear Scenery Database]]. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.<br />
<br />
== Overview ==<br />
=== Map ===<br />
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.<br />
<br />
=== Icons ===<br />
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:<br />
* ''Status field''. Shows the name of the tile that was last selected.<br />
<br />
* ''Sync icon''. Syncs the tiles currently selected.<br />
* ''Clock icon''. Syncs old tiles.<br />
* ''Flight icon''. Opens a dialog to help selecting a route.<br />
* ''Trash can icon''. Deletes the currently selected tiles.<br />
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.<br />
* ''Stop button''. Currently does not work.<br />
<br />
* ''Empty paper''. Hides all shown airports.<br />
* ''Globe icon''. Zooms out to the global view.<br />
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.<br />
<br />
* ''Search field''. Used to search for airports.<br />
<br />
* ''Sync progress bar''. Only visible during syncing.<br />
<br />
=== Tile border colours ===<br />
The tiles are colour coded to represent the state of the tiles:<br />
<br />
* '''Green''' tiles have both terrain and objects.<br />
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)<br />
* '''Red''' tiles are currently selected for synchronisation.<br />
* '''Blue''' tiles are currently being synchronised.<br />
<br />
The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.<br />
<br />
== Using ==<br />
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]<br />
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]<br />
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]<br />
<br />
=== Zooming and panning ===<br />
TerraMaster with the global view. Left-clicking will zoom you in on an area.<br />
<br />
'''Zoom''' using the scroll wheel.<br />
<br />
'''Pan''' around by dragging the map while pressing the right mouse button.<br />
<br />
Get '''back to global view''' by clicking the "globe" icon.<br />
<br />
=== Showing tile information ===<br />
To get some information about a downloaded tile, hold the mouse pointer over it.<br />
<br />
A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.<br />
<br />
=== Syncing tiles ===<br />
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles. <br />
<br />
To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.<br />
<br />
'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.<br />
<br />
=== Syncing old tiles ===<br />
<br />
'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.<br />
<br />
=== Deleting tiles ===<br />
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.<br />
<br />
=== Showing all airports in a tile ===<br />
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.<br />
<br />
=== Searching for an airport ===<br />
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.<br />
<br />
Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.<br />
<br />
== Video tutorial ==<br />
Here is a short video tutorial:<br />
{{#ev:youtube|YxWV4wk_dHw}}<br />
<br />
== Tips ==<br />
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].<br />
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.<br />
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.<br />
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.<br />
<br />
== Installing ==<br />
Before installing, make sure you have Java 6 or higher, as it is needed. NB: On Ubuntu 22.04 (Jammy) OpenJDK 8+ works.<br />
<br />
# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].<br />
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code><br />
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.<br />
# Done!<br />
<br />
== External link ==<br />
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=TerraMaster&diff=141158TerraMaster2025-01-01T20:04:15Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
|title = TerraMaster<br />
|logo =<br />
|image = TerraMaster r32 - Global view.png<br />
|developedby = reeed, portree kid<br />
|initialrelease = July 18, 2011<br />
|latestrelease = January 1, 2025 (v3.00)<br />
|writtenin = Java<br />
|os =<br />
|platform = Cross-platform<br />
|developmentstatus =<br />
|type = Scenery manager<br />
|license = [[GNU GPL]] v2<br />
|website = https://portree-kid.github.io/terramaster/<br />
}}<br />
<br />
'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the [[FlightGear Scenery Database]]. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.<br />
<br />
== Overview ==<br />
=== Map ===<br />
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.<br />
<br />
=== Icons ===<br />
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:<br />
* ''Status field''. Shows the name of the tile that was last selected.<br />
<br />
* ''Sync icon''. Syncs the tiles currently selected.<br />
* ''Clock icon''. Syncs old tiles.<br />
* ''Flight icon''. Opens a dialog to help selecting a route.<br />
* ''Trash can icon''. Deletes the currently selected tiles.<br />
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.<br />
* ''Stop button''. Currently does not work.<br />
<br />
* ''Empty paper''. Hides all shown airports.<br />
* ''Globe icon''. Zooms out to the global view.<br />
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.<br />
<br />
* ''Search field''. Used to search for airports.<br />
<br />
* ''Sync progress bar''. Only visible during syncing.<br />
<br />
=== Tile border colours ===<br />
The tiles are colour coded to represent the state of the tiles:<br />
<br />
* '''Green''' tiles have both terrain and objects.<br />
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)<br />
* '''Red''' tiles are currently selected for synchronisation.<br />
* '''Blue''' tiles are currently being synchronised.<br />
<br />
The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.<br />
<br />
== Using ==<br />
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]<br />
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]<br />
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]<br />
<br />
=== Zooming and panning ===<br />
TerraMaster with the global view. Left-clicking will zoom you in on an area.<br />
<br />
'''Zoom''' using the scroll wheel.<br />
<br />
'''Pan''' around by dragging the map while pressing the right mouse button.<br />
<br />
Get '''back to global view''' by clicking the "globe" icon.<br />
<br />
=== Showing tile information ===<br />
To get some information about a downloaded tile, hold the mouse pointer over it.<br />
<br />
A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.<br />
<br />
=== Syncing tiles ===<br />
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles. <br />
<br />
To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.<br />
<br />
'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.<br />
<br />
=== Syncing old tiles ===<br />
<br />
'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.<br />
<br />
=== Deleting tiles ===<br />
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.<br />
<br />
=== Showing all airports in a tile ===<br />
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.<br />
<br />
=== Searching for an airport ===<br />
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.<br />
<br />
Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.<br />
<br />
== Video tutorial ==<br />
Here is a short video tutorial:<br />
{{#ev:youtube|YxWV4wk_dHw}}<br />
<br />
== Tips ==<br />
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].<br />
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.<br />
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.<br />
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.<br />
<br />
== Installing ==<br />
Before installing, make sure you have Java 6 or higher, as it is needed. NB: On Ubuntu 22.04 (Jammy) OpenJDK 8 works, OpenJDK 18 does not.<br />
<br />
# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].<br />
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code><br />
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.<br />
# Done!<br />
<br />
== External link ==<br />
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=TerraMaster&diff=141122TerraMaster2024-12-23T18:28:41Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
|title = TerraMaster<br />
|logo =<br />
|image = TerraMaster r32 - Global view.png<br />
|developedby = reeed, portree kid<br />
|initialrelease = July 18, 2011<br />
|latestrelease = October 10, 2024 (v2.07)<br />
|writtenin = Java<br />
|os =<br />
|platform = Cross-platform<br />
|developmentstatus =<br />
|type = Scenery manager<br />
|license = [[GNU GPL]] v2<br />
|website = https://portree-kid.github.io/terramaster/<br />
}}<br />
<br />
'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the [[FlightGear Scenery Database]]. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.<br />
<br />
== Overview ==<br />
=== Map ===<br />
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.<br />
<br />
=== Icons ===<br />
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:<br />
* ''Status field''. Shows the name of the tile that was last selected.<br />
<br />
* ''Sync icon''. Syncs the tiles currently selected.<br />
* ''Clock icon''. Syncs old tiles.<br />
* ''Flight icon''. Opens a dialog to help selecting a route.<br />
* ''Trash can icon''. Deletes the currently selected tiles.<br />
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.<br />
* ''Stop button''. Currently does not work.<br />
<br />
* ''Empty paper''. Hides all shown airports.<br />
* ''Globe icon''. Zooms out to the global view.<br />
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.<br />
<br />
* ''Search field''. Used to search for airports.<br />
<br />
* ''Sync progress bar''. Only visible during syncing.<br />
<br />
=== Tile border colours ===<br />
The tiles are colour coded to represent the state of the tiles:<br />
<br />
* '''Green''' tiles have both terrain and objects.<br />
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)<br />
* '''Red''' tiles are currently selected for synchronisation.<br />
* '''Blue''' tiles are currently being synchronised.<br />
<br />
The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.<br />
<br />
== Using ==<br />
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]<br />
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]<br />
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]<br />
<br />
=== Zooming and panning ===<br />
TerraMaster with the global view. Left-clicking will zoom you in on an area.<br />
<br />
'''Zoom''' using the scroll wheel.<br />
<br />
'''Pan''' around by dragging the map while pressing the right mouse button.<br />
<br />
Get '''back to global view''' by clicking the "globe" icon.<br />
<br />
=== Showing tile information ===<br />
To get some information about a downloaded tile, hold the mouse pointer over it.<br />
<br />
A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.<br />
<br />
=== Syncing tiles ===<br />
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles. <br />
<br />
To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.<br />
<br />
'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.<br />
<br />
=== Syncing old tiles ===<br />
<br />
'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.<br />
<br />
=== Deleting tiles ===<br />
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.<br />
<br />
=== Showing all airports in a tile ===<br />
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.<br />
<br />
=== Searching for an airport ===<br />
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.<br />
<br />
Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.<br />
<br />
== Video tutorial ==<br />
Here is a short video tutorial:<br />
{{#ev:youtube|YxWV4wk_dHw}}<br />
<br />
== Tips ==<br />
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].<br />
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.<br />
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.<br />
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.<br />
<br />
== Installing ==<br />
Before installing, make sure you have Java 6 or higher, as it is needed. NB: On Ubuntu 22.04 (Jammy) OpenJDK 8 works, OpenJDK 18 does not.<br />
<br />
# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].<br />
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code>. Java versions 9+ require a <code>java --add-opens java.base/sun.net.dns=ALL-UNNAMED -jar terramaster-2.07.jar<br />
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.<br />
# Done!<br />
<br />
== External link ==<br />
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}<br />
<br />
[[Category:Scenery software]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=TerraMaster&diff=141062TerraMaster2024-12-02T08:06:13Z<p>Portreekid: /* Installing */</p>
<hr />
<div>{{Infobox Software<br />
|title = TerraMaster<br />
|logo =<br />
|image = TerraMaster r32 - Global view.png<br />
|developedby = reeed, portree kid<br />
|initialrelease = July 18, 2011<br />
|latestrelease = October 10, 2024 (v2.07)<br />
|writtenin = Java<br />
|os =<br />
|platform = Cross-platform<br />
|developmentstatus =<br />
|type = Scenery manager<br />
|license = [[GNU GPL]] v2<br />
|website = https://portree-kid.github.io/terramaster/<br />
}}<br />
<br />
'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the [[FlightGear Scenery Database]]. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.<br />
<br />
== Overview ==<br />
=== Map ===<br />
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.<br />
<br />
=== Icons ===<br />
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:<br />
* ''Status field''. Shows the name of the tile that was last selected.<br />
<br />
* ''Sync icon''. Syncs the tiles currently selected.<br />
* ''Clock icon''. Syncs old tiles.<br />
* ''Flight icon''. Opens a dialog to help selecting a route.<br />
* ''Trash can icon''. Deletes the currently selected tiles.<br />
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.<br />
* ''Stop button''. Currently does not work.<br />
<br />
* ''Empty paper''. Hides all shown airports.<br />
* ''Globe icon''. Zooms out to the global view.<br />
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.<br />
<br />
* ''Search field''. Used to search for airports.<br />
<br />
* ''Sync progress bar''. Only visible during syncing.<br />
<br />
=== Tile border colours ===<br />
The tiles are colour coded to represent the state of the tiles:<br />
<br />
* '''Green''' tiles have both terrain and objects.<br />
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)<br />
* '''Red''' tiles are currently selected for synchronisation.<br />
* '''Blue''' tiles are currently being synchronised.<br />
<br />
The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.<br />
<br />
== Using ==<br />
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]<br />
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]<br />
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]<br />
<br />
=== Zooming and panning ===<br />
TerraMaster with the global view. Left-clicking will zoom you in on an area.<br />
<br />
'''Zoom''' using the scroll wheel.<br />
<br />
'''Pan''' around by dragging the map while pressing the right mouse button.<br />
<br />
Get '''back to global view''' by clicking the "globe" icon.<br />
<br />
=== Showing tile information ===<br />
To get some information about a downloaded tile, hold the mouse pointer over it.<br />
<br />
A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.<br />
<br />
=== Syncing tiles ===<br />
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles. <br />
<br />
To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.<br />
<br />
'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.<br />
<br />
=== Syncing old tiles ===<br />
<br />
'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.<br />
<br />
=== Deleting tiles ===<br />
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.<br />
<br />
=== Showing all airports in a tile ===<br />
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.<br />
<br />
=== Searching for an airport ===<br />
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.<br />
<br />
Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.<br />
<br />
== Video tutorial ==<br />
Here is a short video tutorial:<br />
{{#ev:youtube|YxWV4wk_dHw}}<br />
<br />
== Tips ==<br />
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].<br />
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.<br />
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.<br />
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.<br />
<br />
== Installing ==<br />
Before installing, make sure you have Java 6 or higher, as it is needed. NB: On Ubuntu 22.04 (Jammy) OpenJDK 8 works, OpenJDK 18 does not.<br />
<br />
# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].<br />
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code>. Java versions 9+ require a <code>java --add-opens java.base/sun.net.dns=ALL-UNNAMED -jar terramaster-2.07.jar</jar><br />
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.<br />
# Done!<br />
<br />
== External link ==<br />
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}<br />
<br />
[[Category:Scenery software]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=Howto_talk:Animated_jetways&diff=141032Howto talk:Animated jetways2024-11-17T17:04:12Z<p>Portreekid: Portreekid moved page Howto talk:Animated jetways to Howto talk:Animated jetways (Type 1): Was confusing just added Type 1</p>
<hr />
<div>#REDIRECT [[Howto talk:Animated jetways (Type 1)]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=Howto_talk:Animated_jetways_(Type_1)&diff=141031Howto talk:Animated jetways (Type 1)2024-11-17T17:04:12Z<p>Portreekid: Portreekid moved page Howto talk:Animated jetways to Howto talk:Animated jetways (Type 1): Was confusing just added Type 1</p>
<hr />
<div>A380 includes this in the fgdata and git dev repository versions.<br />
<br />
[[User:Scotth1|Scotth1]] 07:56, 20 February 2011 (EST)</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=Howto:Animated_jetways&diff=141030Howto:Animated jetways2024-11-17T17:04:12Z<p>Portreekid: Portreekid moved page Howto:Animated jetways to Howto:Animated jetways (Type 1): Was confusing just added Type 1</p>
<hr />
<div>#REDIRECT [[Howto:Animated jetways (Type 1)]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=Howto:Animated_jetways_(Type_1)&diff=141029Howto:Animated jetways (Type 1)2024-11-17T17:04:12Z<p>Portreekid: Portreekid moved page Howto:Animated jetways to Howto:Animated jetways (Type 1): Was confusing just added Type 1</p>
<hr />
<div>'''Animated jetways''' are dynamic {{Wikipedia|jetway}} models that connect to your aircraft when you are pulled up at a gate. [[FlightGear]] boasts the most advanced animated jetways in the flight simulator market, beating those of Microsoft Flight Simulator and X-Plane in features — a testament to the flexibility of FlightGear. This article describes how to obtain and use the jetways and interface them with aircraft and scenery.<br />
<br />
This feature was broken for a while from end of 2016 up to 2018.2. FlightGear couldn't write the temporary model files in FG_HOME. Meanwhile this issue is solved. <ref>{{cite web<br />
|url = https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/57E1A8F5.8020005%40gmx.de/#msg35381005<br />
|title = <nowiki> AI Jetways broken in 2016.3.1 </nowiki> <br />
|author = <nowiki> several </nowiki> <br />
|date = Sep 20th, 2016<br />
|added = Sep 20th, 2016 <br />
|script_version = 0.40 <br />
}}</ref><br />
A workaround was to use jetways.nas modified by icare38.<ref>{{cite web<br />
|url = https://forum.flightgear.org/viewtopic.php?f=5&t=8728&hilit=animated+jetways&start=360#p305747<br />
|title = <nowiki> AI Jetways broken in 2016.3.1 </nowiki> <br />
|author = <nowiki> icare38 </nowiki> <br />
|date = Feb 29th, 2017<br />
|added = Feb 29th, 2017<br />
|script_version = 0.40 <br />
}}</ref><br />
<br />
<br />
== Compatible airports and aircraft ==<br />
This section lists the airports having animated jetways, as well as the aircraft and AI aircraft supporting them, as of September 2015.<br />
<br />
The compatible airports are:<br />
* [[London Gatwick Airport]] (EGKK)*<br />
* [[Amsterdam Airport Schiphol]] (EHAM)<br />
* Denver International Airport (KDEN)*<br />
* Las Vegas McCarran International Airport (KLAS)*<br />
* [[San Francisco International Airport]] (KSFO)<br />
* Ted Stevens Anchorage International Airport (PANC)*<br />
''<nowiki>*</nowiki> indicates the jetways for this airport were auto-converted and do not have gate numbers.''<br />
<br />
The aircraft supporting animated jetways are:<br />
* [[Boeing 717]]<br />
* [[Boeing 747-8i]]<br />
* [[Boeing 757-200]] and -300<br />
* [[Boeing 767-300]]/ER<br />
* [[Boeing 777-200ER|Boeing 777 (all passenger versions)]]<br />
* [[Bombardier CRJ700]]<br />
* [[McDonnell Douglas MD-11]]<br />
* [[Tupolev Tu-144]]<br />
* [[Tupolev Tu-154B]]<br />
<br />
The [[AI Traffic|AI aircraft]] supporting animated jetways are:<br />
* [[Airbus A319]]<br />
* [[Airbus A320]]<br />
* [[Airbus A321]]<br />
* [[Boeing 737]]<br />
* [[Boeing 747-400]]<br />
* [[McDonnell Douglas MD-80]]<br />
<br />
== Obtaining and installing ==<br />
FlightGear 2.4.0 and later include the animated jetway system. Nothing extra has to be installed.<br />
<br />
== Using the jetways ==<br />
# Start FlightGear in any compatible aircraft. Make sure to have animated jetways enabled (AI->Jetway->EnableAnimatedJetways and View->RenderingOptions->AnimatedJetways)<br />
# Fly (or spawn) to any airport equipped with animated jetways. You can tell if a jetway is animated by pressing {{key press|Ctrl|C}}; if the polygons are highlighted in yellow, then it is animated.<br />
{{note|Ensure you have the latest scenery from [[TerraSync]] so you do not get conflicts between animated and static jetways.}}<br />
<ol start="3"><br />
<li>Taxi up to an animated jetway and park near it, then click it. If your aircraft is supported and parked well enough, the jetway will extend, rotate, and connect.</li><br />
</ol><br />
<br />
An easy use case eg. is to spawn FlightGear with a 777-200 (which is supported) at KSFO parking position E60. You will see the jetway through the cockpit window. Click on it and it will start moving.<br />
<br />
== Development ==<br />
=== Available jetway models ===<br />
The {{fgdata file|Models/Airport/Jetway/generic.xml|t=generic jetway model}} in FGData is broken, but there is [http://scenemodels.flightgear.org/app.php?c=Models&a=view&id=2211 a repaired version in the TerraSync scenery repository].<br />
<br />
Available jetway models in the object database are listed here https://scenery.flightgear.org/app.php?c=Models&a=browse&shared=21. Only some of them can be used as animated jetway. These are:<br />
<br />
{| class="wikitable"<br />
! Model file !! Link !! Used at || Remarks<br />
|-<br />
| generic.xml || https://scenery.flightgear.org/app.php?c=Models&a=view&id=2211 || KSFO || This model might cause a collision with your aircraft if you move too close. <br />
|}<br />
<br />
The number of occurences in the database probably is misleading because usages in ''ICAO''.jetways.xml are not counted here.<br />
<br />
=== Adding support in aircraft ===<br />
# Open up the main model of your aircraft in your favorite 3D modeling software (such as [[Blender]]).<br />
# Move the model around to account for any offsets you have in the main model file, then get the coordinates of the door.<br />
[[File:Animated-jetway-tutorial.jpg]]<br />
<ol start="3"><br />
<li>Add the following code in your aircraft's -set.xml (remember to merge the tags properly):</li><br />
</ol><br />
<syntaxhighlight language="xml"><br />
<sim><br />
<model><br />
<door><br />
<position-x-m type="float">X-M</position-x-m><br />
<position-y-m type="float">Y-M</position-y-m><br />
<position-z-m type="float">Z-M</position-z-m><br />
<jetway-hood-deg type="float">HOOD-DEG</jetway-hood-deg><br />
</door><br />
</model><br />
</sim><br />
</syntaxhighlight><br />
: where <tt>X-M</tt>, <tt>Y-M</tt>, and <tt>Z-M</tt> are the X/Y/Z coordinates of the door in meters and <tt>HOOD-DEG</tt> is the jetway hood rotation amount. To specify more doors, just add more door elements.<br />
<ol start="4"><br />
<li>Add the following code into your XML model file to enable the jetways to connect to your aircraft over the [[multiplayer]] network:</li><br />
</ol><br />
<syntaxhighlight language="xml"><br />
<nasal><br />
<load><br />
var model = cmdarg();<br />
model.getNode("door[0]/position-x-m", 1).setValue(X-M);<br />
model.getNode("door[0]/position-y-m", 1).setValue(Y-M);<br />
model.getNode("door[0]/position-z-m", 1).setValue(Z-M);<br />
model.getNode("door[0]/jetway-hood-deg", 1).setValue(HOOD-DEG);<br />
</load><br />
</nasal><br />
</syntaxhighlight><br />
: Again, replace <tt>X-M</tt>, <tt>Y-M</tt>, <tt>Z-M</tt> and <tt>HOOD-DEG</tt> with their respective values. To add more doors, duplicate the last four lines of [[Nasal]] code and replace <tt>[0]</tt> with <tt>[1]</tt> or <tt>[2]</tt>.<br />
<br />
==== Adding support in AI aircraft ====<br />
Follow the steps for regular aircraft above, but only add in the Nasal code. <br />
<br />
Background: The model definition of AI (and MP) aircraft is not available in Nasal. So any door definition located as property inside any XML file is not available for the jetways module. For that reason AI aircraft xml files must contain an embedded piece of Nasal code for writing the door information into the AI models property tree. This is an example taken from the MD80 AI aircraft:<br />
<br />
<syntaxhighlight lang="xml"><br />
<?xml version="1.0"?><br />
<PropertyList><br />
...<br />
<nasal><br />
<load><br />
var model = cmdarg();<br />
model.getNode("door[0]/position-x-m",1).setValue(-19.241);<br />
model.getNode("door[0]/position-y-m",1).setValue(-1.529);<br />
model.getNode("door[0]/position-z-m",1).setValue(2.505);<br />
model.getNode("door[0]/jetway-hood-deg",1).setValue(3);<br />
</load><br />
</nasal><br />
...<br />
</PropertyList><br />
</syntaxhighlight><br />
<br />
=== Adding support in scenery ===<br />
==== Placing jetways ====<br />
# Launch FlightGear in your favorite aircraft, such as the [[Bluebird]].<br />
{{note|You ''cannot'' use the [[UFO]] because its scenery editing function will interfere with the jetway editor.}}<br />
<ol start="2"><br />
<li>Go to {{menu item|AI|Jetway Settings}} and tick the '''Enable jetway editor''' checkbox, then click the {{button|Open Editor}} button.<br />
[[File:Animated-jetway-editor.jpg]]<br />
<li>With the editor enabled, click anywhere on the ground to place an animated jetway, which will flash to indicate it is selected. The jetway editor is similar to the UFO scenery model editor. You can {{key press|Alt}}+click on the terrain to move the current selected jetway. {{key press|Ctrl}}+click selects the jetway closest to the click position (the new jetway will flash to indicate it is selected). {{key press|Shift}}+click deselects the current jetway.</li><br />
</ol><br />
<br />
: The dialog is used to adjust the selected jetway. The top sliders adjust position and orientation and the bottom ones adjust the jetway itself. The offsets that the bottom sliders control can be used to model jetways that are in obscure configurations. The dropdown menus at the very bottom of the dialog control various properties of the jetway, such as the model, gate number, airline sign and door number. The following models are available:<br />
:* Generic<br />
:* Glass<br />
:* [[EHAM]] gate<br />
:* [[EHAM]] 747 gate<br />
<br />
<ol start="4"><br />
<li>When you are finished editing your airport jetway layout, click the {{button|Export}} button. A jetway definition file will be created and written to <tt>$FG_HOME/Export/ICAO.xml</tt>, where <tt>ICAO</tt> is the ICAO code of the nearest airport. (The exact location of this file is printed to the console window.) This file should be [[FlightGear Scenery Database#Contribute|submitted to TerraSync]].</li><br />
</ol><br />
<br />
==== Auto-converting static/obsolete jetways ====<br />
{{WIP}}<br />
<br />
== Future development ==<br />
{{See also|AI Jetway Objects}}<br />
Ryan A Young, the original developer of the animated jetway code, is planning to rewrite it as a C++ subsystem. This would bring several advantages:<br />
* some hacks in the current [[Nasal]] code would be removed, and the system would be faster and more reliable;<br />
* the model files could be streamlined and the jetways could be automatically placed on the ground, irrespective of the employed scenery;<br />
* performance could be improved by letting the user decide how many jetways would be rendered;<br />
* they could be integrated with AI traffic.<ref>{{cite web<br />
| url = http://sourceforge.net/p/flightgear/mailman/message/34725917/<br />
| title = <nowiki>[Flightgear-devel] Animated jet bridges redux</nowiki><br />
| author = <nowiki>Ryan A Young</nowiki><br />
| date = Dec 29th, 2015<br />
}}</ref><br />
<br />
== Related content ==<br />
* [[Animated jetways]]<br />
* [[List of .stg files with non-AI jetway scenery objects]]<br />
* [[Ramp Marshall]]<br />
* {{forum link|title=The animated jetway project|t=8728}}<br />
<br />
{{Appendix}}<br />
<br />
[[Category:Scenery]]<br />
[[Category:Scenery enhancement]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=TerraMaster&diff=140810TerraMaster2024-10-21T10:53:57Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
|title = TerraMaster<br />
|logo =<br />
|image = TerraMaster r32 - Global view.png<br />
|developedby = reeed, portree kid<br />
|initialrelease = July 18, 2011<br />
|latestrelease = October 10, 2024 (v2.07)<br />
|writtenin = Java<br />
|os =<br />
|platform = Cross-platform<br />
|developmentstatus =<br />
|type = Scenery manager<br />
|license = [[GNU GPL]] v2<br />
|website = https://portree-kid.github.io/terramaster/<br />
}}<br />
<br />
'''TerraMaster''' is a graphical [[scenery]] manager that gives you a quick overview of your scenery and makes it easier to maintain that scenery. TerraMaster is a cross platform stand alone application written in Java that synchronises [[TerraSync]] scenery tiles you select with the [[FlightGear Scenery Database]]. You can delete scenery tiles if the TerraSync scenery directory takes too much space, and you can also search for airports.<br />
<br />
== Overview ==<br />
=== Map ===<br />
When TerraMaster starts it will show a map of the Earth. The map can be zoomed and one or more 1x1 degree tiles can be selected before they are synced or deleted. All the airports within a tile can be shown, and airports can be searched for and be shown.<br />
<br />
=== Icons ===<br />
The top row contains a status field, two groups of icon buttons, a search field and a sync progress bar. The icons will be grayed out when they can not be used. For more detailed directions, see the section [[#Using|Using]] below. From left to right:<br />
* ''Status field''. Shows the name of the tile that was last selected.<br />
<br />
* ''Sync icon''. Syncs the tiles currently selected.<br />
* ''Clock icon''. Syncs old tiles.<br />
* ''Flight icon''. Opens a dialog to help selecting a route.<br />
* ''Trash can icon''. Deletes the currently selected tiles.<br />
* ''Eye icon''. Shows all airports in the first selected tile of the currently selected tiles.<br />
* ''Stop button''. Currently does not work.<br />
<br />
* ''Empty paper''. Hides all shown airports.<br />
* ''Globe icon''. Zooms out to the global view.<br />
* ''Gear icon''. Opens a dialogue to select the location of the TerraSync scenery directory.<br />
<br />
* ''Search field''. Used to search for airports.<br />
<br />
* ''Sync progress bar''. Only visible during syncing.<br />
<br />
=== Tile border colours ===<br />
The tiles are colour coded to represent the state of the tiles:<br />
<br />
* '''Green''' tiles have both terrain and objects.<br />
* '''Amber/Yellow''' tiles has terrain but no objects. (And are possibly unsyncable - see "Bug", below.)<br />
* '''Red''' tiles are currently selected for synchronisation.<br />
* '''Blue''' tiles are currently being synchronised.<br />
<br />
The blue tiles that are being synced will change colour to green or amber/yellow as they are synced. Tiles that get no border after they have been synced don't contain terrain or objects and are usually located in open seas.<br />
<br />
== Using ==<br />
[[File:TerraMaster r32 - Mouse hint.png|thumb|Tile information pop-up when holding the mouse pointer over a tile.]]<br />
[[File:TerraMaster r32 - Airports in selected tile.png|thumb|Showing all airports in a selected tile using the "eye" button.]]<br />
[[File:TerraMaster r32 - Searching for an airport.png|thumb|Searching for an airport.]]<br />
<br />
=== Zooming and panning ===<br />
TerraMaster with the global view. Left-clicking will zoom you in on an area.<br />
<br />
'''Zoom''' using the scroll wheel.<br />
<br />
'''Pan''' around by dragging the map while pressing the right mouse button.<br />
<br />
Get '''back to global view''' by clicking the "globe" icon.<br />
<br />
=== Showing tile information ===<br />
To get some information about a downloaded tile, hold the mouse pointer over it.<br />
<br />
A pop-up box will show the name of that tile, if there are terrain and objects in it and what airports it contains. This only works if a tile has been synced, either with Terrasync or TerraMaster.<br />
<br />
=== Syncing tiles ===<br />
To '''select just one tile''' left-click it. The scenery for download is available in 1x1 degree tiles. <br />
<br />
To '''select more tiles''' press the Ctrl key while left-clicking or left-dragging over the wanted tiles. If you accidentally selected a tile to many, '''deselect tiles''' using it Ctrl+left-click. You can also deselect several tiles using Ctrl+left-click and dragging.<br />
<br />
'''Start the update and/or download''' clicking the "sync" icon. The tiles will be downloaded starting from the first tile you selected and proceed in order of distance from it. If you are downloading tiles for a long flight you should then begin by selecting a tile close to the departure airport.<br />
<br />
=== Syncing old tiles ===<br />
<br />
'''Start the update and/or download''' clicking the 2nd "sync" icon. All previously downloaded tiles that are older than the age given in the settings, will be downloaded.<br />
<br />
=== Deleting tiles ===<br />
You can delete files from the TerraSync scenery by selecting the tiles you want to delete and click the "trash can" icon.<br />
<br />
=== Showing all airports in a tile ===<br />
To show all airports in a tile, select it and click on the "eye" icon. To hide the airports again, click the "empty paper" icon.<br />
<br />
=== Searching for an airport ===<br />
You can search for airports using the search field and pressing enter. The airports location an ICAO code will be shown in white on the map. If you don't see it, zoom out. ICAO airport codes works best, but sometimes the airport's name also work. To hide the airports again, click the "empty paper" icon.<br />
<br />
Be warned that the search function is rather slow as it uses a web query to mpmap.flightgear.org and that it also doesn't tell if there was no airports found.<br />
<br />
== Video tutorial ==<br />
Here is a short video tutorial:<br />
{{#ev:youtube|YxWV4wk_dHw}}<br />
<br />
== Tips ==<br />
* '''Before [[multiplayer]] events''' it might be an idea to sync the related tiles, even more so if you know that someone has crated new buildings etc. and got them into the [[FlightGear Scenery Database|scenery database]].<br />
* If you have very little hard drive space left you can delete tiles you rarely or never fly within.<br />
* Starting TerraMaster in a console window will let you see the sync process, which can be useful if the sync stalls for unknown reasons.<br />
* If you already have a synchronisation running and want to add more tiles to be synced, just mark more tiles as above with Ctrl + leftclick and drag to mark more tiles and press the sync button again.<br />
<br />
== Installing ==<br />
Before installing, make sure you have Java 6 or higher, as it is needed. NB: On Ubuntu 22.04 (Jammy) OpenJDK 8 works, OpenJDK 18 does not.<br />
<br />
# Download the newest version of TerraMaster from the [https://github.com/Portree-Kid/terramaster/releases releases page].<br />
# Create a shortcut or script that runs <code>java -jar terramaster.jar</code>.<br />
# When running TerraMaster the first time, click the "gear" icon and select the folder where your TerraSync scenery is located. On some machines you might have to manually edit the property file to have it pointing to the TerraSync directory.<br />
# Done!<br />
<br />
== External link ==<br />
* {{forum link|title=TerraMaster: a new scenery manager|t=12050}}<br />
<br />
[[Category:Scenery software]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FlightGear_Tracker&diff=138472FlightGear Tracker2023-10-15T16:43:31Z<p>Portreekid: Added https://fgtracker.us.to/</p>
<hr />
<div>The '''FlightGear Tracker''' tracks all flights performed on the [[Howto: Multiplayer|multiplayer servers]]. The flights are stored by callsign. Every flight the following data is logged:<br />
* Start time<br />
* End time<br />
* Max altitude<br />
* Aircraft<br />
* Duration<br />
* Total distance<br />
* Max ground speed<br />
* Max Mach<br />
Some of them are also shown in a diagram. The route is shown on a map. Beside these data the total flight time of every callsign is shown.<br />
<br />
Be aware that multiple pilots could use the same callsign. The tracker doesn't track by pilot, but by callsign. So choose a callsign that noone else will use.<br />
<br />
Pilots flying on some servers can be seen on a online map, [[MPmap]].<br />
<br />
== External links ==<br />
* [http://mpserver15.flightgear.org/ FlightGear Tracker] (inactive)<br />
* [https://fgtracker.us.to/ FlightGear Tracker us to] (active)<br />
* [http://fgfs.i-net.hu/modules/fgtracker/ FlightGear Tracker] (same database, but the newest data is from approx. september 2010)<br />
<br />
[[fr:FlightGear Tracker]]<br />
[[Category:Multiplayer]]<br />
[[Category:Software]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=132202FGAirports2021-05-28T18:53:38Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.32 (28 May 2021)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== Checks ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! ID !! Message !! Explanation <br />
|-<br />
| LONG_SEGMENT || Start/End of long route || The check has found a segment with >2km <br />
| || Unconnected Pushbacknode ||<br />
|}<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
<br />
== Related content ==<br />
* [[Aircraft radii]]<br />
* [[Airports with ground networks]]<br />
* [[AI Traffic#Creating the base network]]<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=131349FGAirports2021-04-21T09:26:31Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.31 (21 Apr 2021)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== Checks ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! ID !! Message !! Explanation <br />
|-<br />
| LONG_SEGMENT || Start/End of long route || The check has found a segment with >2km <br />
| || Unconnected Pushbacknode ||<br />
|}<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
<br />
== Related content ==<br />
* [[AI Traffic#Creating the base network]]<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=130327FGAirports2021-02-15T13:13:55Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.30 (15 Feb 2021)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== Checks ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! ID !! Message !! Explanation <br />
|-<br />
| LONG_SEGMENT || Start/End of long route || The check has found a segment with >2km <br />
| || Unconnected Pushbacknode ||<br />
|}<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=129887FGAirports2021-01-12T21:14:50Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.28 (12 Jan 2021)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== Checks ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! ID !! Message !! Explanation <br />
|-<br />
| LONG_SEGMENT || Start/End of long route || The check has found a segment with >2km <br />
| || Unconnected Pushbacknode ||<br />
|}<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=127766FGAirports2020-09-30T19:34:47Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.25 (01 Jul 2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== Checks ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! ID !! Message !! Explanation <br />
|-<br />
| LONG_SEGMENT || Start/End of long route || The check has found a segment with >2km <br />
| || Unconnected Pushbacknode ||<br />
|}<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=126444FGAirports2020-07-19T18:43:50Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.20 (01 Jul 2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== Checks ==<br />
<br />
{| class="wikitable"<br />
|-<br />
! ID !! Message !! Explanation <br />
|-<br />
| LONG_SEGMENT || Start/End of long route || The check has found a segment with >2km <br />
| || Unconnected Pushbacknode ||<br />
|}<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=126017FGAirports2020-07-01T20:34:07Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.15 (01 Jul 2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
Issues are tracked in https://github.com/Portree-Kid/flightgear-airports <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| ParkPos Icon Unclear || 0.14.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.14.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.14.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.14.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=126016FGAirports2020-07-01T20:29:13Z<p>Portreekid: /* Setup */</p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.15 (01 Jul 2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form. Best is a GIT clone of https://github.com/terrasync/main<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here during the scan.<br />
## Export Directory - Work in progress can be copied here for test purposes. You can set it as an additional FG Scenery directory. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{Template:Done}}<br />
|-<br />
| ParkPos Icon Unclear || 0.14.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.14.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.14.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.14.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=Aircraft_tester_list&diff=125933Aircraft tester list2020-06-24T16:08:51Z<p>Portreekid: </p>
<hr />
<div>for test procedure see [[Aircraft testing checklist]]<br />
<br />
{| class="wikitable sortable"<br />
|-<br />
! Aircraft !! Tester(s) !! Remarks<br />
|-<br />
| A300 || Jonathan Redpath|| <br />
|-<br />
| A320-200 || Jonathan Redpath|| [NB - upstream github repo for issues]<br />
|-<br />
| A340-600 || Jonathan Redpath|| <br />
|-<br />
| A380 || Jonathan Redpath|| <br />
|-<br />
| Aerostar-700 || James || <br />
|-<br />
| B1900D || James || <br />
|-<br />
| 737NGs || James || <br />
|-<br />
| 757 || James || <br />
|-<br />
| F15 || Richard H. || presumably :)<br />
|-<br />
| J3Cub || Wayne Bragg|| <br />
|-<br />
| DaSH || Wayne Bragg|| <br />
|-<br />
| SUMPAC || Wayne Bragg|| <br />
|-<br />
| p51d || Stuart || <br />
|-<br />
| hunter || Stuart || <br />
|-<br />
| seahawk || Stuart || <br />
|-<br />
| CRJ700 family || Henning, Daniel || <br />
|-<br />
| DR400 || Scott || <br />
|-<br />
| Socata || Scott || <br />
|-<br />
| Cap 10C || Scott || <br />
|-<br />
| Lionceau || Scott || <br />
|-<br />
| Grob || Scott || <br />
|-<br />
| Skyvan || Keith || <br />
|-<br />
| F6F - Hellcat || Keith || <br />
|}</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=125772FGAirports2020-06-16T08:53:15Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.13 (16.06.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{Template:Done}}<br />
|-<br />
| ParkPos Icon Unclear || 0.14.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.14.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.14.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.14.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=125434FGAirports2020-06-03T18:13:31Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.12 (03.06.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.12.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.13.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=125433FGAirports2020-06-03T18:13:04Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/latest 0.0.10 (03.06.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.12.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.13.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=125091FGAirports2020-05-25T19:59:18Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-0eccacbcb06017d7a1a4 0.0.10 (21.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{Template:Done}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.12.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.13.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=125089FGAirports2020-05-25T19:52:27Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-0eccacbcb06017d7a1a4 0.0.10 (21.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{Template:Fixed}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.12.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.12.0 || {{pending}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.13.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124821FGAirports2020-05-21T16:44:44Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-0eccacbcb06017d7a1a4 0.0.10 (21.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.11.0 || {{pending}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.11.0 || {{pending}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.11.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124816FGAirports2020-05-21T15:52:40Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-367c2e2bd7068c20116c 0.0.9 (13.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Loading Performance (SET_PARKINGS) || 0.11.0 || {{pending}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.11.0 || {{pending}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.11.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124784FGAirports2020-05-20T19:29:25Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-367c2e2bd7068c20116c 0.0.9 (13.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
{| class="wikitable"<br />
!Work item !! Version !! Progress <br />
|-<br />
| Zoom/Move performance || 0.10.0 || {{Template:Fixed}}<br />
|-<br />
| Extend properties editing || 0.11.0 || {{pending}}<br />
|-<br />
| ParkPos Icon Unclear || 0.11.0 || {{pending}}<br />
|-<br />
| Consistent click behaviour || 0.11.0 || {{pending}}<br />
|-<br />
| Layer visibility || 0.11.0 || {{pending}}<br />
|-<br />
| Import from X-Plane Gateway || 0.12.0 || {{pending}}<br />
|-<br />
| Full Airline names in dropdown || 0.12.0 || {{pending}}<br />
|-<br />
| Editing of single airport (without terrasync copy) || || {{pending}}<br />
|-<br />
| Undo || || {{pending}}<br />
|-<br />
|}<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=User:Portreekid&diff=124782User:Portreekid2020-05-20T18:32:27Z<p>Portreekid: </p>
<hr />
<div>I previsouly participated in the [[Osm2city.py]] project.<br />
<br />
http://wiki.flightgear.org/Areas_populated_with_osm2city_scenery<br />
<br />
Currently I do some modelling like EDOE and my native Scotland. I also am the maintainer of [[TerraMaster]].<br />
<br />
TODO FG Airports<br />
<br />
Navigation / Project Level Functions<br />
<br />
Confusing LHS Panel<br />
<br />
It contains both Product Level (Settings, Search) and Project Level (Parking List, Properties) functions<br />
<br />
Happy to have a think and come back with suggestions. I would group Icons functionally (Program Level ie Setting, Search, Tool vs Project Level ie Parking, Properties, Check)<br />
No transition message. Maybe some kind of spinning wheel / Wait message during transitions (loading selected airport etc) as unsure if the program is hanged or just loading data?<br />
Unclear how to use the Work In Progress Tool. No mouse hover help on icons<br />
Unclear how to use the Check option; No "Start" button nor explanation of what is checked and the purpose <br />
<br />
<br />
Project/Airport Overview (non Edit mode)<br />
<br />
Too much going on in the background. Is this impacting performance?<br />
It looks like you are rendering both OSM and APT/DAT elements.<br />
Maybe the user should be able to select in Program settings what background layers to render (including none). An option to have them in greyscale would also help distinguishing things the user can vary (Groundnet Elements) from the one he/she can’t<br />
<br />
Clickable Elements (Parkpos, Segments): <br />
<br />
Clicking on a graphic element on the map should bring up the properties panel in the LHS (It does not open by default)<br />
<br />
ParkPos Icon Unclear : No indication of purpose nor heading (PHP and OnRunway icons have icons in them). Can you fill the circle with a simple aircraft outline pointing to heading? I can put together an SVG/PNG is you give me specs/size <br />
<br />
Bug : Clicking on pushback routes with properties panel open : the map shows pushback routes in different colour but the LHS panel shows all routes as pushback off <br />
<br />
Non Clickable Elements (why) : <br />
Inconsistency: Regular Nodes not shown in non edit mode but PHP and OnRunwat are. Clicking on these does nothing (confusing)<br />
<br />
<br />
Menu<br />
<br />
Why is upload in this panel if Check is on the LHS one? Shouldn't they be together so, At project level I can see all the airports I am working on and in the same space Check / Upload them ? <br />
<br />
Not sure what Test Icon does. My fault. need to play more with it <br />
<br />
<br />
<br />
Project/Airport (Edit mode)<br />
<br />
LHS Panel does not show all the data stored: LAT LON only for Parkpos and not nodes?, No Heading for Parkpos shown<br />
Ideally all data a user can vary should be able for editing not only in the Map/Graphic interface space but also as basic text entry in the Properties panel (lat and lon should be two different fields) <br />
Airlines List : Can you show the full name next to the IATA Code in the combo? (not in the selected box). I can provide the list <br />
Counter intuitive experience with PHP and Nodes On Runways nodes. There is an icon but you can't click on it. <br />
Counter intuitive experience with Threshold: Another Icon/Circle that looks FGA but that I can’t click (shall you grey it?).<br />
<br />
The threshold XML includes headings. Like ParkPos this is another another circle we could fill with a basic pointing shape. Happy to provide design. <br />
Two Zoomin Icons?<br />
<br />
<br />
Actually making edits<br />
<br />
Some serious latency (I am guessing the background images take up a lot of resources (see above option to de activate to improve performance). Zooming in/out is actually a killer <br />
Undo : Only choice is to get back to Original/Last Save. Can you get a simple CTRL-Z undo last entry so we don’t have to save every 5 seconds?<br />
<br />
[[User:Portreekid/FGAirports]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124657FGAirports2020-05-13T20:06:57Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-367c2e2bd7068c20116c 0.0.9 (13.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
* Import from X-Plane Gateway<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124503FGAirports2020-05-04T19:38:56Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/0.0.8 0.0.8 (04.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
== Sidebar == <br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
=== Properties ===<br />
Currently selected item can be edited here.<br />
=== Parking List ===<br />
Table of all parkings for easy editing.<br />
=== Search === <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
=== Check result === <br />
=== Work in Progress === <br />
List of edited airports with the possibility to remove after upload.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
## Airports Directory - The directory with all/most airports. Must conform to Airports/A/B/C/ABCD.groundnet.xml form.<br />
## Flightgear Directory - Flightgear directory. apt.dat and traffic is read from here.<br />
## Test Directory - Work in progress can be copied here for test purpose. <br />
# Start scans one after the other in sidebar with sync icon.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
== ToDo / Wishlist == <br />
* Import from X-Plane Gateway<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124502FGAirports2020-05-04T18:24:17Z<p>Portreekid: Version 0.0.8</p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/0.0.8 0.0.8 (04.05.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
== Search == <br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
== World view ==<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow too little parking. Red no groundnet.<br />
<br />
== Setup ==<br />
# Set directories in settings (bottom left)<br />
# Start scans one after the other in sidebar with magnifying glass.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124467FGAirports2020-05-03T12:23:53Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = [https://github.com/Portree-Kid/flightgear-airports/releases/tag/untagged-336c1b92f233350fa589 0.0.7 (28.04.2020)]<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
== Setup ==<br />
Set directories in settings (bottom left)<br />
Start scans one after the other in sidebar with magnifying glass.<br />
Search<br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
World view<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow to little parking. Red no groundnet.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.<br />
<br />
[[Category:Scenery software]]<br />
[[Category:AI Traffic]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=124385FGAirports2020-04-28T18:33:13Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = 0.0.7<br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
<br />
== Setup ==<br />
Set directories in settings (bottom left)<br />
Start scans one after the other in sidebar with magnifying glass.<br />
Search<br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
World view<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow to little parking. Red no groundnet.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=User:Portreekid/FGAirports&diff=123996User:Portreekid/FGAirports2020-04-21T18:56:43Z<p>Portreekid: Portreekid moved page User:Portreekid/FGAirports to FGAirports</p>
<hr />
<div>#REDIRECT [[FGAirports]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=123995FGAirports2020-04-21T18:56:43Z<p>Portreekid: Portreekid moved page User:Portreekid/FGAirports to FGAirports</p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = <br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
<br />
== Setup ==<br />
Set directories in settings (bottom left)<br />
Start scans one after the other in sidebar with magnifying glass.<br />
Search<br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
World view<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow to little parking. Red no groundnet.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=FGAirports&diff=123970FGAirports2020-04-19T18:29:06Z<p>Portreekid: </p>
<hr />
<div>{{Infobox Software<br />
| title = Flightgear Airports<br />
| image = <br />
| alt = <br />
| developedby = Keith Paterson<br />
| initialrelease = 2020<br />
| latestrelease = <br />
| os = Windows, GNU/Linux, MacOS X<br />
| website = https://github.com/Portree-Kid/flightgear-airports/wiki<br />
| license = [[GNU General Public License]]<br />
}}<br />
<br />
Flightgear Airports is a (free) taxiway editor for FlightGear licensed under the GNU GPL. It is cross-platform, known to work on Windows but should work on all platforms supported by electron. The usage philosophy is not to be file centred, but airport centred. <br />
<br />
== Setup ==<br />
Set directories in settings (bottom left)<br />
Start scans one after the other in sidebar with magnifying glass.<br />
Search<br />
You can search for airports with ICAO or parts of the name. Only airports with flights are shown. If you want to view another one it will be added when you type the full ICAO.<br />
World view<br />
When zoomed out you will see circles. Their size corresponds with the number of flights. Blue means Ok. Yellow to little parking. Red no groundnet.<br />
<br />
== Overview ==<br />
<br />
[[File:FGAirportsEditing.png|frameless|FG Airports editing view]]<br />
<br />
<br />
== Edit Bar ==<br />
Button with ICAO code opens the Airport data in the edit tab.<br />
[[File:FGAMenuBar.png|thumb|FG Airports Menu Bar]]<br />
* The top 4 buttons in the button bar are for zooming (+/-/details/large).<br />
* Upload sends the current airport to [http://groundweb.azurewebsites.net/ groundweb].<br />
* Edit switches into edit mode<br />
* Undo undos all changes or all changes during session<br />
* Save, saves the groundnet<br />
* Draw taxiline<br />
* Draw push<br />
* Add parking<br />
* Remove element, removes the currently selected element<br />
* Check triggers the groundnet check.</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=File:FGAMenuBar.png&diff=123969File:FGAMenuBar.png2020-04-19T18:22:19Z<p>Portreekid: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=FG Airports Menu Bar}}<br />
|date=2020-04-19<br />
|source={{own}}<br />
|author=[[User:Portreekid|Portreekid]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-4.0}}<br />
<br />
<br />
<br />
[[Category:FlightgearAirports]]</div>Portreekidhttps://wiki.flightgear.org/w/index.php?title=File:FGAirportsEditing.png&diff=123968File:FGAirportsEditing.png2020-04-19T18:22:18Z<p>Portreekid: User created page with UploadWizard</p>
<hr />
<div>=={{int:filedesc}}==<br />
{{Information<br />
|description={{en|1=FG Airports editing view}}<br />
|date=2020-04-19<br />
|source={{own}}<br />
|author=[[User:Portreekid|Portreekid]]<br />
|permission=<br />
|other versions=<br />
}}<br />
<br />
=={{int:license-header}}==<br />
{{self|cc-by-sa-4.0}}<br />
<br />
<br />
<br />
[[Category:FlightgearAirports]]</div>Portreekid