De/Interaktiver Verkehr

From FlightGear wiki
Jump to navigation Jump to search

AI Verkehr, AI-Verkehr oder Interaktiver Verkehr steht seit der Version 0.9.5 von FlightGear zur Verfügung. Seitdem wird das interaktive Verkehrssystem ständig weiterentickelt. Das interaktive Verkehrsystem basiert auf einer Art Künstlichen Intelligenz (Artificial Intelligence). Diese Seite stellt die erforderliche Dokumentation für die Einrichtung und Nutzung des interaktiven Verkehrssystem dar.

Das interaktive Verkehrssystem beinhaltet drei Schritte:

  1. Erstellen von Dateien für den interaktiven Verkehr
  2. Flughäfen für den interaktiven Verkehr vorbereiten
  3. Anflug- und Abflugverfahren für den jeweiligen Flughafen erstellen

Die Flugzeuge für den interaktiven Verkehr sind ein Teil des Basispaketes. Eine zusätzliche Installation von AI-Flugzeugen ist nicht mehr erforderlich.

Dateiverzeichnis für den interaktiven Verkehr

Die Dateien für den interaktiven Verkehr werden im "Extended Markup Language"-Format (XML; Dateiendung:.xml) erstellt. Der Speicherort dieser Dateien hängt von der Version von FlightGear ab. In der nachfolgenden Tabelle sind die Unterverzeichnisse im FlightGear-Hauptverzeichnis aufgeführt:

FlightGear-Version Verzeichnis Hinweis
0.9x $FG ROOT/Traffic/
1.0 $FG ROOT/AI/Aircraft/ Beispiel: AI-Flugzeuge einer A380 der Lufthansa sind hier gespeichert: $FG ROOT/AI/Aircraft/A380/A380-Lufthansa-traffic.xml
1.9.0 und höher $FG ROOT/AI/Traffic/ Mit der FlightGear-Version 1.9.0 und höher wird ein neues Dateiformat genutzt (im Folgenden als "Traffic-Manager II"-Format (TM-II) bezeichnet). Mit TM-II-Format sind die AI-Flugzeuge und die AI-Verkehrdaten getrennt. Dies führt zu einer höheren Flexibilität beim interaktiven Verkehr.

Aus Gründen der Übersichtlichkeit wird je Fluggesellschaft eine Traffic-Manager II-Datei angelegt. Diese Datei wird in ein Unterverzeichnis mit der ersten Buchstaben gespeichert. So wird beispielsweise für KLM eine Datei $FG ROOT/AI/Traffic/K/KLM.xml oder für die Lufthansa $FG ROOT/AI/Traffic/D/DLH.xml angelegt.

Für den militärischen und allgemeinen Flugverkehr gibt es keine formalen Vorgaben. Die oben beschriebene Vorgehensweise kann auch hier genutzt werden. So kann beispielsweise für die Luftwaffe die XML-Datei in folgenden Verzeichnis abgelegt werden: $FG ROOT/AI/Traffic/mi/Luftwaffe.xml.

Traffic-Manager-System

Der interaktive Verkehr in FlightGear konzentriert sich auf den Flugverkehr.

Ein Verkehrsflugzeug wird durch eine Fluglinie täglich eingesetzt um Passagiere von einem Flughafen zu einem anderen Flughafen zu bringen. So werden Flugzeuge zu Langstreckenflüge zwischen Kontinenten, aber auch zu kürzeren Inlandsflügen eingesetzt. Weiter gibt es auch Standzeiten für das Aus- und Einsteigen von Passagieren, für die Betankung und weiteren Servicezeiten am Flughafen. Diese unterschiedlichen Flug- und Standzeiten müssen bei einem interaktiven Verkehr berücksichtigt werden.

Zur Zeit werden die Flug- und Standzeiten in FlightGear noch nicht wirklichkeitgetreu umgesetzt. Dies soll jedoch in Zukunft möglich sein. So kann jedem einzelnen AI-Flugzeug eine oder mehrere Flugrouten zugeordnet werden, die regelmäßig - stündlich, täglich oder wöchentlich - wiederholt werden können.

Das FlightGear-Traffic-Manager-System überprüft periodisch die ungefähre Position der AI-Flugzeuge in seiner Datenbank. Diese Datenbank wurde ursprünglich auf der Grundlage einer festen Flugtabelle je AI-Flugzeug erstellt. Wie in der realen Welt endet ein Flug an einem Flughafen und der folgende Flug des AI-Flugzeuges startet wieder an diesem. In der realen Welt werden Flugzeuge auf unterschiedlichen Routen eingesetzt. In FlightGear fliegen die AI-Flugzeuge auf der gleichen Route hin und her. Ebenso wird in FlightGear die Wartung der AI-Flugzeuge und die dadurch außer Betriebnahme nicht berücksichtigt.

Mit dem "Traffic-Manager II"-Format sind die durchzuführenden Flüge nicht mehr starr einem bestimmten Flugzeug zugeordnet. Stattdessen werden die durchzuführenden Flüge einer Flugzeugflotte zugeordnet. Das Routing wird vom FlightGear-TrafficManager-System übernommen.


Traffic-Manager-Datei

Nachfolgend ist eine eine Beispiel für eine "Traffic-Manager II"-Datei aufgeführt. Diese Traffic-Manager-Datei wird in den FlightGear-Versionen 1.9.0 und höher verwendet: 

<?xml version="1.0"?>
 <trafficlist>
    <aircraft>
       <model>Aircraft/MD11/Models/KLMmd11.xml</model>
       <livery>KLM</livery>
       <airline>KLM</airline>
       <home-port>EHAM</home-port>
       <required-aircraft>MD11KLM</required-aircraft>
       <actype>MD11/P</actype>
       <offset>25</offset>
       <radius>39</radius>
       <flighttype>gate</flighttype>
       <performance-class>jet_transport</performance-class>
       <registration>PH-KCA</registration>
       <heavy>true</heavy>
    </aircraft>
    <aircraft>
       <model>Aircraft/MD11/Models/KLMmd11.xml</model>
       <livery>KLM</livery>
       <airline>KLM</airline>
       <home-port>EHAM</home-port>
       <required-aircraft>MD11KLM</required-aircraft>
       <actype>MD11/P</actype>
       <offset>25</offset>
       <radius>39</radius>
       <flighttype>gate</flighttype>
       <performance-class>jet_transport</performance-class>
       <registration>PH-KCB</registration>
       <heavy>true</heavy>
    </aircraft>
 
    <flight>
       <callsign>KLM0765</callsign>
       <required-aircraft>MD11KLM</required-aircraft>
       <fltrules>IFR</fltrules>
       <departure>
           <port>EHAM</port>
           <time>0/12:35:00</time>
       </departure>
       <cruise-alt>330</cruise-alt>
       <arrival>
           <port>TNCM</port>
           <time>0/21:15:00</time>
       </arrival>
       <repeat>WEEK</repeat>
    </flight>
 
    <flight>
       <callsign>KLM0769</callsign>
       <required-aircraft>MD11KLM</required-aircraft>
       <fltrules>IFR</fltrules>
       <departure>
           <port>TNCM</port>
           <time>3/01:25:00</time>
       </departure>
       <cruise-alt>330</cruise-alt>
       <arrival>
           <port>EHAM</port>
           <time>3/10:50:00</time>
       </arrival>
       <repeat>WEEK</repeat>
    </flight>
 </trafficlist>

Dateiaufbau

Die Traffic-Manager II-Dateien sind im "Extended Markup Language"-Format (XML-Format) aufgebaut. Der logische Aufbau entspricht einer Baumstruktur und ist damit hierarchisch organisiert.

Die Traffic-Manager II-Datei hat folgenden Aufbau:

  • Allgemeiner Teil
  • Flugzeugdefinition
  • Flugplandefinition

Allgemeiner Teil

Der allgemeine Teil der Traffic-Manager II-Datei enthält in der ersten Zeile einen generischen XML-Header <?xml version="1.0"?>. In der zweiten Zeile folgt der sogenannte Start-Tag <trafficlist>. Die Traffic-Manager II-Datei wird mit einem End-Tag </trafficlist> abgeschlossen.

Beispiel: 

<?xml version="1.0"?>
 <trafficlist>

 </trafficlist>


Flugzeugdefinition

Nach dem XML-Header und dem Start-Tag der Traffic-Manager II-Datei folgt die Definition der Flugzeuge. Jedes Flugzeug muss definiert werden. Die Flugzeugdefinition beginnt mit dem XML-Tag <aircraft> und endet mit dem XML-Tag </aircraft>.

Ein Flugzeug wird mit folgenden Eigenschaften beschrieben:

XML-Tag Beschreibung Beispielwert Hinweis
<model> Datei Aircraft/MD11/Models/KLMmd11.xml Verzeichnispfad und Dateiname der Datei des 3D-Modells
<livery> Lackierung KLM Dieser Wert wir zur Zeit nicht genutzt.

Ursprünglich bestand die Idee, das einzelnen Flugzeugen eine individuelle Lackierung erhalten sollten. Die Zuordnung wäre über die Angaben <model> und <livery> erfolgt. Eine Umsetzung ist bisher nicht erfolgt, da Kompabilitätsprobleme nicht auszuschließen sind.

<airline> Fluggesellschaft KLM Dieser Wert wird für die Zuweisung und Verwendung der Parkpositionen am Gate oder der Vorfeld-Standplätze genutzt. Es ist der offizielle dreistellige ICAO-Code für die Fluggesellschaften zu verwenden. Für Privat- oder Militärflugzeuge können andere Werte genutzt werden.
<home-port> Heimatflughafen EHAM Jedem Flugzeug wird ein Heimatflughafen zugewiesen. Verwendet wird der vierstellige ICAO-Code. In FlightGear wird dadurch sichergestellt, dass eine Flugroute am Heimatflughafen endet. Dadurch wir der Routing-Algorithmus des Traffic-Manager-Systems genauer.
<required-aircraft> Flugplanzuordnung MD11KLM Mit diesem Wert wird dieses Flugzeug mit einem Flugplan verknüpft. Der Wert <required-aircraft> (hier MD11KLM) wird auch bei der Flugplandefinition verwendet.

Wird ein Flugzeugtyp einer Fluggesellschaft von mehreren Heimatflughäfen (z.B. bei der KLM von Frankfurt und Amsterdam) betrieben, sind die Flugpläne aufzuteilen. Damit die Flugpläne übersichtlich bleiben, kann je Heimatflughafen der ICAO-Code des Flughafen verwendet werden, zum Beispiel: Flugplan-Frankfurt MD11KLMEDDF und Flugplan-Amsterdam MD11KLMEHAM).

<actype> ATC-Name MD11 Eine Beschreibung des Flugzeugtyps für die zukünftige Verwendung bei der Flugverkehrskontrolle (ATC).
<offset> Korrekturwert 25 Korrekturwert des verwendeten 3D-Modells des Flugzeugs

Dieser Wert dient dazu, dass das 3D-Modell mit den Rädern den Boden berührt. Bei einem falschen Wert "schwebt" oder "versinkt" das Flugzeug im Boden. Dieser Wert wird wahrscheinlich zuküftig nicht mehr erforderlich sein, da ein entsprechender Wert in der XML-Datei des Flugzeuges verwendet wird.

<radius> Flugzeuggrösse 39 Dieser Wert beschreibt die geschätzte Flugzeuggrösse. Dieser Wert wird auf den Flughäfen eingesetzt um zum Beispiel eine passende Parkposition am Gate zu finden.
<flighttype> Flugzeugtyp Tor Folgende Werte sind möglich:
  • ga - Allgemeiner Luftverkehr
  • cargo - Frachtverkehr
  • gate - Passagierverkehr
  • mil-fighter - Militärische Luftverkehr
  • mil-cargo - Militärischer Frachtverkehr

In Zukunft sollen diese Werte die Zuweisung der Start- und Landebahnen, der Rollwege und der Parkpositionen beeinflussen. Die verschiedenen Flugzeugtypen werden auf den Flughäfen mit diesem Wert individuell gesteuert.

<performance-class> Leistungseigenschaft jet_transport Folgende Werte sind möglich:
  • light_aircraft - Ein- oder zweimotoriges Propellerflugzeug
  • ww2_fighter - Flugzeug aus dem 2. Weltkrieg
  • jet-transport - Modernes Verkehrsflugzeug
  • jet_fighter - Militärflugzeug
  • tanker - Tankflugzeug
  • ufo - Ermöglicht extreme Beschleunigung bzw. Verzögerungen

Diese Werte sollen die Leistungseigenschaft des Flugzeuges beschreiben und einen realistischen AI-Verkehr gewährleisten.

<registration> Flugzeugregistrierung PH-KCA Flugzeugregistrierung am Flugzeugheck. Die Flugzeugregistrierung wird zukünftige bei der Flugverkehrskontrolle (ATC) verwendet. Für den gewerblichen Verkehr wird die Flugzeugregistrierung wahrscheinlich nicht genutzt werden.
<heavy> ATC-Zusatz true Folgende Werte sind möglich:
  • true
  • false

Eine zusätzliche Beschreibung des Flugzeugtyps für die zukünftige bei der Flugverkehrskontrolle (ATC). Wird der Wert true verwendet, wird der Zusatz Heavy an das Rufzeichen (Callsign) des Fluges angehängt.

Beispiel: 

<?xml version="1.0"?>
 <trafficlist>
    <aircraft>
       <model>Aircraft/MD11/Models/KLMmd11.xml</model>
       <livery>KLM</livery>
       <airline>KLM</airline>
       <home-port>EHAM</home-port>
       <required-aircraft>MD11KLM</required-aircraft>
       <actype>MD11/P</actype>
       <offset>25</offset>
       <radius>39</radius>
       <flighttype>gate</flighttype>
       <performance-class>jet_transport</performance-class>
       <registration>PH-KCA</registration>
       <heavy>true</heavy>
    </aircraft>
    <aircraft>
      ...
    </aircraft>
 
 </trafficlist>

Flugplandefinition

Nach der Flugzeugdefinition folgt die Definition des Flugplanes. Jeder Flug muss einzeln definiert werden. Die Flugplandefinition beginnt mit dem XML-Tag <flight> und endet mit dem XML-Tag </flight>.

Ein Flugplan wird mit folgenden Eigenschaften beschrieben:

XML-Tag Beschreibung Beispielwert Hinweis
<callsign> Rufzeichen KLM0769 Jedes Flugzeug hat für die Flugverkehrskontrolle (ATC) ein Rufzeichen. Bei einem Flugzeug einer Fluggesellschaft setzt sich das Rufzeichen aus dem Rufzeichen der Fluggesellschaft (z.B. bei KLM -> KLM oder Lufthansa -> LH) und der Flugnummer (z.B. KLM0605 oder LH1860) zusammen.
<required-aircraft> Flugzeugzuordnung MD11KLM Mit diesem Wert wird der Flugplan mit dem Flugzeug verknüpft. Der Wert <required-aircraft> (hier MD11KLM) wird auch bei der Flugzeugdefinition verwendet.
<fltrules> Flugregel IFR Folgende Werte sind möglich:

Dieser Wert wird zukünftig für die Flugverkehrskontrolle (ATC) benötigt. Mit IFR erfolgt der Flug nach den Instrumentenflugregeln. Wird der Wert VFR verwendet, wir der Flug nach den Sichtflugregeln behandelt.

<departure> Abflugdefinition Beginn des Abschnitts im Flugplan für Abflugflughafen und Abflug-Zeitpunkt
<port> Abflugflughafen EHAM Im Flugplan muss ein Abflugflughafen angegeben werden. Es wird der vierstellige ICAO-Code verwendet.
< time> Abflugzeit 0/12:35:00 Neben dem Abflugflughafen muss auch auch eine Abflugzeit angegeben werden. Für die Abflugzeit muss der Wochentag und die Uhrzeit nach UTC angegeben werden. Der Wert hat folgende Form: Wochentag/Uhrzeit.

Die Wochentage haben folgenden Wert:

  • 0 - Sonntag
  • 1 - Montag
  • 2 - Dienstag
  • 3 - Mittwoch
  • 4 - Donnerstag
  • 5 - Freitag
  • 6 - Samstag

Die Uhrzeit hat das Format: Stunde:Minute:Sekunde. Bei der UTC handelt es sich um die koordinierte Weltzeit. Die UTC wird u.a. als einheitliche Uhrzeit in der Luftfahrt eingesetzt. Die UTC wird auch Greenwich Mean Time (GMT) genannt, die vom Nullmeridian ausgeht.

</departure> Ende des Abschnitts der Abflugdefinition
<cruise-alt> Reiseflughöhe 330 Dieser Wert ist die Flugfläche, die die Reiseflughöhe während des Fluges darstellt. Der Wert 330 ist die Flugfläche 330 und gibt die Reiseflughöhe von 33.000 Fuß wieder.
<arrival> Ankunftsdefinition Beginn des Abschnitts im Flugplan für den Zielflughafen und die Ziel-Ankunftszeit
<port> Zielflughafen TNCB Im Flugplan muss ein Ziel-flughafen angegeben werden. Es wird der vierstellige ICAO-Code verwendet.
< time> Ziel-Ankunftszeit 2/22:15:00 Neben dem Zielflughafen muss auch auch eine Ziel-Ankunftszeit angegeben werden. Für die Ziel-Ankunftszeit muss der Wochentag und die Uhrzeit nach UTC angegeben werden. Der Wert hat folgende Form: Wochentag/Uhrzeit.

Die Wochentage haben folgenden Wert:

  • 0 - Sonntag
  • 1 - Montag
  • 2 - Dienstag
  • 3 - Mittwoch
  • 4 - Donnerstag
  • 5 - Freitag
  • 6 - Samstag

Die Uhrzeit hat das Format: Stunde:Minute:Sekunde.

</arrival> Ende des Abschnitts der Ankunftsdefinition
<repeat> Zeitraum WEEK Dieser Wert stellt den Wiederholungsrhythmus des Fluges dar. Folgende Werte sind möglich:
  • WEEK - wöchentliche Wiederholung
  • Zahl Hr - Wiederholung nach Stunden (= Zahl); (z.B. 6 Hr bedeutet eine Wiederholung nach 6 Stunden)

Es hat sich gezeigt, dass sich bei täglich wiederholenden Flügen ein seperater Flug je Wochentag bewährt hat.

Beispiel: 

<?xml version="1.0"?>
 <trafficlist>
     ...
    <flight>
       <callsign>KLM0765</callsign>
       <required-aircraft>MD11KLM</required-aircraft>
       <fltrules>IFR</fltrules>
       <departure>
           <port>EHAM</port>
           <time>0/12:35:00</time>
       </departure>
       <cruise-alt>330</cruise-alt>
       <arrival>
           <port>TNCM</port>
           <time>0/21:15:00</time>
       </arrival>
       <repeat>WEEK</repeat>
    </flight>
 </trafficlist>


Flugzeug und Flugplan verbinden

Mit dem Traffic-Manager II-Dateiformat wurde die Flugzeugdefinition und die Flugplandefinition getrennt. Um jedoch ein bestimmtes Flugzeug einem bestimmen Flugplan zuzuordnen zu können ist der XML-Tag <required-aircraft> erforderlich. Der XML-Tag wird in den XML-Bereichen <aircraft> und <flight> eingetragen. Der Wert dieses XML-Tag - hier: MD11KLM - verbindet das Flugzeug mit dem Flugplan.

Beispiel: 

    <trafficlist>
       <aircraft>
          ...
          <required-aircraft>MD11KLM</required-aircraft>
          ...
       </aircraft>
 
       <flight>
          ...
          <required-aircraft>MD11KLM</required-aircraft>
          ...
      </flight>
    </trafficlist>

Interaktiver Verkehr am Boden

Für die interaktive Flugzeuge am Boden werden auf den Start- und Landbahnen, auf den Rollbahnen und auf dem Flughafenvorfeld entsprechende Informationen benötigt. So müssen Informationen vorhanden sein damit Flugzeuge von der Landebahn auf bestimmte Parkpositionen fahren und wieder zurück auf die Startbahn.

Diese Informationen werden in einer XML-Datei je Flughafen gespeichert. Der Dateiname hat folgende Namenskonvention: [ICAO-Flughafencode].groundnet.xml. Die XML-Datei wird im Scenery-Verzeichnis von Flightgear unter "Airports" abgelegt: $FG_SCENERY/Airports/. Dabei werden die Unterverzeichnis mit den ersten drei Buchstaben des ICAO-Flughafencode verwendet.

Beispiel: 

   Verzeichnispfad für die XML-Datei des Flughafen San Francisco Airport (ICAO-Code: KSFO)

   Erste drei Buchstaben des ICAO-Flughafencode: [K] / [S] / [F]

   .../Flightgear/data/Scenery/Airports/K/S/F/KSFO.groundnet.xml

Bei Flightgear-Versionen 2.0.0 und älter sind die Informationen in einer XML-Datei parking.xml im Verzeichnis $FG_ROOT/AI/Airports/[ICAO]/ gespeichert worden.

Dateiaufbau

Die groundnet-XML-Datei ist in vier Abschnitte gegliedert:

  • Flughafen-Funkfrequenzen
  • Parkpositionen
  • Bodenpunkte mit Informationen für den interaktiven Verkehr
  • Verbindungsinformationen der einzelnen Bodenpunkte

Allgemeiner Teil

Der allgemeine Teil der groundnet-XML-Datei enthält in der ersten Zeile einen generischen XML-Header <?xml version="1.0"?>. In der zweiten Zeile folgt der sogenannte Start-Tag <groundnet> und in der letzten Zeile den Ende-Tag </groundnet>.

Beispiel: 

  <?xml version="1.0"?>
     <groundnet>
         ...
     </groundnet>

Flughafen-Funkfrequenzen

Jeder Flughafen oder Flugplatz hat verschiedene Funkfrequenzen. Die Flughafen-Funkfrequenzen beginnen mit dem XML-Tag <frequencies> und enden mit dem XML-Tag </frequencies>.

Die Flughafen-Funkfrequenzen werden mit folgenden Eigenschaften beschrieben:

XML-Tag Beschreibung Beispielwert Hinweis
<AWOS> Wetterinformationen 11805 AWOS (Automated Weather Observation System) stellt Piloten als automatisches Wetterbeobachtungssystem wichtige Wetterinformationen zur Verfügung. Die Messungen erfolgen je Minute. Als Wetterdaten werden Windgeschwindigkeit und -richtung, Temperatur, Taupunkt, Sicht, Wolkenhöhe und -typ, Niederschläge mitgeteilt.
<UNICOM> Universalfrequenz 12295 Flugplätze mit nur einer Betriebsfrequenz; Universalfrequenz zur Übermittlung von Verkehrsinformationen zwischen den Piloten in der Platzumgebung
<CLEARANCE> Freigabe 11820 Funkfrequenz zur Freigabeerteilung
<GROUND> Bodenkontrolle 12865 Flugverkehrskontrolle am Boden; Fluglotse leitet die rollenden Flugzeuge
<TOWER> Kontrollturm 12050 Teil der Flugverkehrskontrolle; Leitet den Flugverkehr rund um den Flughafen bzw. Flugplatz
<APPROACH> Anflugkontrolle 13395 Teil der Flugverkehrskontrolle
<DEPARTURE> Abflugkontrolle 13395 Teil der Flugverkehrskontrolle

Beispiel: 

  ...
    <frequencies>
        <AWOS>11805</AWOS>
        <UNICOM>12295</UNICOM>
        <CLEARANCE>11820</CLEARANCE>
        <GROUND>12865</GROUND>
        <TOWER>12050</TOWER>
        <APPROACH>13395</APPROACH>
        <DEPARTURE>13510</DEPARTURE>
     </frequencies>
   ...

Parkpositionen

Mit der Definition der Parkpositionen erfolgt die Zuweisung von Flugzeugen einer Fluggesellschaft oder eine bestimmte Flugzeugart zu einem oder mehreren Parkpositionen. Jede Parkposition hat eine einzigartige Nummerung (siehe <index>).

Die Parkpositionen werden zwischen XML-Tag <parkinglist> und </parkinglist> beschrieben. Für jede Parkposition wird ein XML-Tag benötigt. Der XML-Tag beginnt mit <Parking ...> und wird mit den nachfolgenden Werten beschrieben:

XML-Tag Beispielwert Hinweis
<pushBackRoute> 506 Punkt bis zu welchem das Flugzeug von der Parkposition zurückgeschoben werden soll
<airlineCodes> JBU ICAO-Code der Fluggesellschaft, die die Parkposition nutzt; bei mehren Fluggesellschaften werden die ICAO-Codes mit Komma getrennt
<radius> 40.3211 Wert, der die maximale Größe des Flugzeuges angibt, das die Parkposition nutzen kann; der Wert ist auch bei der Flugzeug-Definition enthalten; FlightGear nutzt eine Standardwerte für die Zuordnung, siehe auch Werte zur Flugzeuggröße
<heading> 250.708 Flugzeugrichtung auf der Parkposition; Angaben in Grad
<lon> W122 22.851 Parkposition als Längengrad
<lat> N37 37.098 Parkposition als Breitengrad
<number> 1 Dieser Wert wird mit dem Wert <name> für die vollständige Benennung der Parkposition genutzt.
<name> D55 Bezeichnung der Parkposition, wie sie auf Flughafenkarten angegeben ist
<type> gate Dieser Wert gibt an, welcher Flugzeugtyp die Parkposition nutzen kann. Der Wert wird bei der Flugzeugdefinition unter <flighttype> angegeben. Folgende Werte sind gültig:
  • ga - Allgemeine Luftfahrt
  • cargo - Frachtverkehr
  • gate - Passagierverkehr
  • mil-fighter - Militärische Kampfflieger
  • mil-cargo - Militärische Frachverkehr
<index> 1 Fortlaufende eindeutige Nummer der Parkposition

Beispiel: 

  ...
    <parkingList>
        <Parking pushBackRoute="506" airlineCodes="JBU,SWA,VRD" radius="40.3211" heading="250.708" lon="W122 22.851"
           lat="N37 37.098" number="1" name="D55" type="gate" index="0"/>
        <Parking pushBackRoute="473" airlineCodes="JBU,SWA,VRD" radius="30.9576" heading="115.799" lon="W122 22.922"
           lat="N37 37.101" number="53" name="D" type="gate" index="1"/>
        <Parking pushBackRoute="510" airlineCodes="JBU,SWA,VRD" radius="38.3993" heading="252.006" lon="W122 22.821"
           lat="N37 37.023" number="54" name="D" type="gate" index="2"/>
     </Parkinglist>
   ...

Bodenpunkte mit Informationen für den interaktiven Verkehr

Die Bodenpunkte auf den Start- und Landebahnen, sowie auf den Rollbahnen und -wegen haben auch eine eindeutige Nummer. Mit den Bodenpunkten erhält der interaktive Verkehr die Informationen, die für den Weg von der Landebahn zur Parkposition und wieder zurück zur Startbahn benötigte werden.

Die Bodenpunkte werden zwischen XML-Tag <TaxiNodes> und </TaxiNodes> beschrieben. Für jeden Bodenpunkt wird ein XML-Tag benötigt. Der XML-Tag beginnt mit <node ...> und wird mit den nachfolgenden Werten beschrieben:

XML-Tag Beispielwert Hinweis
<lon> W122 23.011 Position des Bodenpunkt als Längengrad
<lat> N37 36.386 Position des Bodenpunkt als Breitengrad
<index> 209 Eindeutige Nummer des Bodenpunktes
<holdPointType> none Beschreibt, ob der Bodenpunkt eine Halteposition ist. Folgend Werte sind möglich:
  • none - Keine Haltepostition
  • normal - Halteposition
  • CAT II/III - Positionspunkt für IFR-Bedingungen; wird derzeit nicht unterstützt
  • PushBack - Pushback-Endpunkt; Jede Parkposition kann nur mit einem Pushback-Endpunkt verbunden sein. Der Pushback-Weg kann jedoch über mehrere "normale" Haltepunkte führen. Der Pushback-Endpunkt ist optional.
<isOnRunway> 0 Tag der folgende Werte annehmen kann:
  • 1 - Bodenpunkt liegt auf der Start- oder Landebahn (Runway)
  • 0 - Bodenpunkt liegt nicht auf der Runway

Beispiel: 

  ...
    <TaxiNodes>
        <node lon="W122 23.011" lat="N37 36.386" index="209" holdPointType="none" isOnRunway="0"/>
        <node lon="W122 22.707" lat="N37 36.434" index="210" holdPointType="none" isOnRunway="0"/>
        <node lon="W122 22.572" lat="N37 36.642" index="211" holdPointType="none" isOnRunway="0"/>
     </TaxiNodes>
   ...

Verbindungsinformationen der einzelnen Bodenpunkte

Damit die Fahrzeuge sich auf den Lande-, Start- und Rollwegen bzw. auf dem Flughafen bewegen können, müssen die einzelnen Bodenpunkte verbunden werden. So kann ein Flugzeug von Bodenpunkt zu Bodenpunkt von der Parkposition zu Startbahn rollen. Diese Verbindungsinformationen sind ebenfalls in der XML-Datei hinterlegt.

Die Verbindungsinformationen werden zwischen XML-Tag <TaxiWaySegments> und </TaxiWaySegments> beschrieben. Für jeden Bodenpunkt wird ein XML-Tag benötigt. Der XML-Tag beginnt mit <arc ...> und wird mit den nachfolgenden Werten beschrieben:

XML-Tag Beispielwert Hinweis
<name> Route Name des Rollweges
<IsPushBackRoute> 0 Ist die Verbindung zwischen den Bodenpunkten eine Pushback-Route dann ist der Wert ein logischer Wert, ansonsten ist er "0". Folgende Werte sind daher möglich:
  • 0 - Verbindung zwischen den Bodenpunkten ist keine Pushback-Route
  • 1 - Verbindung zwischen den Bodenpunkten ist eine Pushback-Route
<end> 122 Nummer des Bodenpunktes am Ende der Verbinungsroute
<begin> 0 Nummer des Bodenpunktes am Ende der Verbinungsroute

Beispiel: 

  ...
    <TaxiWaySegments>
        <arc name="Route" isPushBackRoute="1" end="122" begin="0"/>
        <arc name="Route" isPushBackRoute="1" end="0" begin="122"/>
        <arc name="Route" isPushBackRoute="1" end="118" begin="1"/>
        <arc name="Route" isPushBackRoute="1" end="1" begin="118"/>
        <arc name="Route" isPushBackRoute="0" end="123" begin="2"/>
    </TaxiWaySegments>
   ...

Zusammenfassung

Tools

Für die Erstellung der Traffic-Manager II-Datei steht der AI Schedule Manager zur Verfügung. Dieses Tool ist eine GUI-Anwendung.

Weitere Tools und Anwendungen befinden sich in der Entwicklung, stehen aber derzeit für die öffentliche Nutzung nicht zur Verfügung.

Retrieved from "https://wiki.flightgear.org/w/index.php?title=De/Interaktiver_Verkehr&oldid=121076"