NAVIGRAPH

Allerdings, vielen Dank! :)

Gibt es eigentlich (ganz allgemein) irgendwo eine frei zugängliche maschinenlesbare Version der RAD, bin ich nur zu blöd die zu finden? Ich sehe immer nur die scheinbar handgepflegten Excel-Tabellen und wundere mich jedes mal aufs neue wie man die eigentlich automatisiert verarbeiten können soll.

@David, wie machst Du das?


Danke auch an Hermann - darf ich fragen wie lange Du für die Routenerstellung benötigt hast (ging ja scheinbar recht schnell) und wie Du auf die folgenden Directs gekommen bist?

  1. NEMOS DCT NINTU
  2. AGN DCT PIPOR

Der 2. Direct löst den RAD-Knoten in Frankreich und an der Grenze zu Spanien, der sonst so gut wie jede Route blockiert und zu schwachsinnigen Umwegen führt. Auf VATSIM sind Directs ja verpönt (außerhalb FRA natürlich), offenbar ist das nicht ganz realistisch. Wie bist Du auf die Idee gekommen, diese Directs auszuprobieren, gibt es da irgendeine Regel an der man festmachen kann wann und wo es sinnvoll ist die Airways durch Directs abzulösen und auf gut Glück in den Validator zu schicken?
 

Oliver Gruetzmann

961224
RG München - NAV
Dankeauch an Hermann - darf ich fragen wie lange Du für die Routenerstellung benötigt hast (ging ja scheinbar recht schnell) und wie Du auf die folgenden Directs gekommen bist?

  1. NEMOS DCT NINTU
  2. AGN DCT PIPOR
Beide finden sich im RAD Appendix 4:

1. (In verschiedenen Konstellationen und Höhen)
"Compulsory for traffic Via BENOT and NINTU Via LSAGL7 Except a. DEP LSZS/ZA/ZL/ZR/ML, LFST, EDDS/SB/JA/FM/NL/NY/TB/TC/TD/TF/TG/TL/TM/TN/TO/TP/TQ/TR/TS/TU/TW/TX/TY/TZ, ETHL b. ARR LFCR/LC/LX/LV/LN/LO "

2.
"Only available for traffic 1. Via DGO 2. ARR LEAS/LEBB/LEBG/LEVT/LEXJ"
 
Hallo Daniel,

das hat ca. 5-10 Minuten gedauert.
Zu 1.: Das ursprüngliche Routing aus PFPX sah den UN869 durchgängig vor. Das ergab dann einen Error beim Validieren und unter dem entsprechenden Code im RAD den Hinweis, NEMOS DCT NINTU zu filen (was fast aufs gleiche rauskommt, weil der UN869 da fast geradeaus verläuft).
Zu 2.: Der AGN DCT PIPOR kommt direkt so aus PFPX, ich musste nur noch die Höhe FL270 anpassen.

Viele Grüße,
Hermann
 
Gibt es eigentlich (ganz allgemein) irgendwo eine frei zugängliche maschinenlesbare Version der RAD, bin ich nur zu blöd die zu finden? Ich sehe immer nur die scheinbar handgepflegten Excel-Tabellen und wundere mich jedes mal aufs neue wie man die eigentlich automatisiert verarbeiten können soll.
Hey Daniel,

die Excel-Dateien sind ein automatischer Auszug aus der Datenbank und nicht handgepflegt :)
Das ist die beste lesbare Version, die es gibt.
Das Interface von NM ist weit mehr unübersichtlicher und die Datenbank dahinter mit ihren ganzen Restrictions ist rieeeesig.

LG
 
Allerdings, vielen Dank! :)

Gibt es eigentlich (ganz allgemein) irgendwo eine frei zugängliche maschinenlesbare Version der RAD, bin ich nur zu blöd die zu finden? Ich sehe immer nur die scheinbar handgepflegten Excel-Tabellen und wundere mich jedes mal aufs neue wie man die eigentlich automatisiert verarbeiten können soll.

@David, wie machst Du das?


Danke auch an Hermann - darf ich fragen wie lange Du für die Routenerstellung benötigt hast (ging ja scheinbar recht schnell) und wie Du auf die folgenden Directs gekommen bist?

  1. NEMOS DCT NINTU
  2. AGN DCT PIPOR

Der 2. Direct löst den RAD-Knoten in Frankreich und an der Grenze zu Spanien, der sonst so gut wie jede Route blockiert und zu schwachsinnigen Umwegen führt. Auf VATSIM sind Directs ja verpönt (außerhalb FRA natürlich), offenbar ist das nicht ganz realistisch. Wie bist Du auf die Idee gekommen, diese Directs auszuprobieren, gibt es da irgendeine Regel an der man festmachen kann wann und wo es sinnvoll ist die Airways durch Directs abzulösen und auf gut Glück in den Validator zu schicken?
Moin,

die Updates für RAD und Directs Restrictions für PFPX werden händisch eingepflegt. Soweit mir bekannt bietet das Tool keine automatisierte Möglichkeit dafür.

Was NEMOS DCT NINTU und den UN869 angeht, so beiße ich mir da schon seit letztem Jahr die Zähne dran aus.
Sobald die Schweizer im Geneva-Sector ebenfalls FRA einführen, dürfte sich das Problem allerdings von selbst erledigt haben. ;)
 
Mal ein kleiner Einwurf für Dispatcher und Piloten: Die RADs werden auch nur von Menschen gemacht, meist in Hinblick auf Steuerung von Verkehrsströmen zwecks Entlastung der Sektoren - Aber auch hier kann es durchaus zu Fehlern oder zum "Übersehen" von einzelnen Citypairs kommen sodass dann wirklich kuriose Routings notwendig werden.. solche gibt es aber im RL dann auch.

Ein Beispiel von vor über 15 Jahren als wir noch unser altes Streifensystem hatten: Dieses System war relativ "dumm", da es die Inhalte auf dem Streifen nach einem gewissen Regelwerk gefüllt hat - so wusste das System wenn ein Flieger über Wegpunkt 1 einfliegt und Destination X hat, dann muss der Flug über Wegpunkt 2 ausfliegen; so stand es auch in den RADs, zumindest dachte man das. Eine Lücke in den RADs führte dazu dass man vollkommen legal von einem Airway auf den anderen (parallellen) Airway wechseln konnte, und so war der Flugplan auch aufgegeben und so hatte der Piloten die Route auch im FMC. Der Lotse hatte jedoch aufgrund des Rulesets des Streifens eine anderen Exitpoint stehen und war durchaus verwundert, dass der Flug nun einfach mal "abbiegt". Es kam zu keinen weiteren Problemen, da weit und breit kein anderer Flieger war, ich wollte das nur ausführen um zu zeigen, wie wichtig die RADs und korrekte Flugpläne für das System "ATC" sind.

P.S.: PFPX > all. Wer mal an einem Abend zig Routen für ein Cross the Pond durch britischen, französischen, schweizer sowie italienischen Luftraum basteln musste, weiß was ich meine.
 
Zuletzt bearbeitet:

Michael Krause

810881
RG München - NAV
Ach Alex, dem Kristian wäre sowas doch niemals passiert! ;)
Nee Spaß beiseite - eure Daten passen eigentlich immer recht gut, die Kollegen schauen da eigentlich immer sehr gut drauf. Problem ist halt, dass bisher das RAD von den entsprechenden RAD Koordinatoren der Länder erstellt wurde und dann nochmal meist händisch in die NM Systeme eingepflegt wurde. Das ändert sich grad, NM hat da auch noch anderweitig ein Großprojekt vor sich die ganze Software auf neue Beine zu stellen, d.h. da sollten künftig zumindest in der Übertragung weniger Fehler passieren. Aber klar wird man auch dann nicht immer an alle Citypairs denken können. Manche Dinge merkt man dann auch erst in Kombination, wenn sie live im System sind - speziell wenn es sich um reine Höhenregeln handelt und in den Tests vor dem AIRAC keine veränderten Abbruchraten oder Routings auftauchen - dann sind manchmal Lotsen die ersten, die merken, dass ein ganzer Trafficstrom plötzlich unerwartet tief bleibt - meist fällt das dann am Wochenende auf, weil AIRAC ist ja am Donnerstag, d.h. wenn sie Glück haben kommt ein Increment am Freitag, wenn sie Pech haben müssen sie bis Montag da manuell mit umgehen...

Gruß
Micha
 
Ach Alex, dem Kristian wäre sowas doch niemals passiert! ;)
Haha, der is ja jetzt in Pension :D

Wobei das Filen ist ja eine Sache - die andere Sache ist halt dann die Umsetzung. Sollte ein RAD wirklich so nicht gewünscht sein gibts eh von ATC-Seite schnelle Lösungen auf der Frequenz und wenn das nicht unbedingt ein Pimperlplatz mit 3 IFR Movements im Jahr ist, fällt das auch recht flott auf.
 

Dominik Samuelis

842558
RG Frankfurt - NAV
Mal ein kleiner Einwurf für Dispatcher und Piloten: Die RADs werden auch nur von Menschen gemacht, meist in Hinblick auf Steuerung von Verkehrsströmen zwecks Entlastung der Sektoren - Aber auch hier kann es durchaus zu Fehlern oder zum "Übersehen" von einzelnen Citypairs kommen sodass dann wirklich kuriose Routings notwendig werden.. solche gibt es aber im RL dann auch.
Nur kann man im RL auch einfach mal beim NMOC anrufen, wenn einem bei einem Routing etwas spanisch vorkommt. Da fehlt hier bei uns irgendwie noch die Hotline :)
 
Oben