Login: 
Passwort: 
Neuanmeldung 
Passwort vergessen



Das neue Heft erscheint am 30. März
War früher alles besser?
Frühjahrsflug in die Normandie
EDNY: Slot-Frust und Datenleck
Triebwerksausfall kurz nach dem Start
Der kleine QRH-Bausatz
Unfall: Wer zu oft warnt ...
Engagierter Journalismus aus Sicht des eigenen Cockpits
Engagierter Journalismus aus Sicht des eigenen Cockpits
Sieben tote......
Sortieren nach:  Datum - neue zuerst |  Datum - alte zuerst |  Bewertung

  457 Beiträge Seite 18 von 19

 1 ... 18 19 
 

23. Mai 2019: Von Stefan K. an Johannes König

Kein Mensch benutzt diesen mittelalterlichen Flugplan wenn er es nicht muss. Er muss vom AIS überwacht werden und braucht eine Start und Landemeldung.

23. Mai 2019: Von ch ess an 

Aber gäbe es eine (am Ende sogar kostenlose) App, bei der ich Start, Ziel und Anzahl Personen angebe (meine und die Flugzeugdaten sind schon hinterlegt) und ich bekomme im Gegenzug Notams, Wetter, relevante AIP-Auszüge, Infos zu Beschränkungsgebieten, etc. einfach aufbereitet, dann könnte dieses System auch gleich einen FPL aufgeben und alle relevanten Stellen wüssten, was ich vor habe

Das ist doch genau das, was ich von SD bekomme ? Und dann gebe ich, wenn rechtlich erforderlich (=Ausland), einen FP auf.

Und, oh staun, dort liegt er vor und wird gelesen und ernstgenommen ! Gerade erst wieder festgestellt.

Das Problem in DE scheint doch hausgemacht...

Die Wahrscheinlichkeit das ein hoheitlicher Laden eine funktionale App hinbringt geht gegen Null. DFS sollte durch SD, FF etc gefilte FPs einfach ernsthaft bearbeiten. Beispiel gerne hier mal alles SE von Austria :-)

Nachtrag: Start und Landemeldungen koennte eine funktionale App wie SD auch verarbeiten...

23. Mai 2019: Von Georg v. Zulu-eZulu-schwit-Zulu an Stefan K. Bewertung: +6.00 [6]

Hi Stefan,

ich fürchte ja, dass "die App" schon richtig in Planung ist. Dazu zunächst der Wahnsinn des VRR (Verkehrsverbund Rhein-Ruhr). Der VRR ist der Zusammenschluss von 20-30 städtischen Verkehrsunternehmen, und im Prinzip kann jedes Unternehmen Fahrkarten für jeden Bereich verkaufen. Was war IT-mäßig das Ergebnis? Der VRR hatte zumindest früher eine Webseite, einen "Ticket-Shop" und eine App, die sich so in etwa an der Zeit von Webseiten "best viewed with Internet Explorer", in Sachen Verfügbarkeit an "Warum soll das Internet offen haben, wenn der Verkaufsschalter zu ist?" orientierten. Dieses Desaster einerseits, aber natürlich auch 20-30 Dorf-IT-Verantwortliche, die alle für ihre Gehaltsverhandlungen auch eine eigene App herausbringen wollten (koste die Entwicklung, was sie wolle, man will ja Öffi 2.0 sein), führte dann zu den Konkurrenzlösungen der Dorfbusunternehmen.

Wenn ich mal König von Deutschland werden sollte (keine Sorge, nicht geplant): Natürlich würde ich diesen Unfug und diese Geldverschwendung verbieten. Ich würde den Verkehrsbetrieben eine Frist setzen, eine gemeinsame API zu spezifizieren, die jedem interessierten Klienten mindestens die Funktionen Fahrplanauskunft, Verspätungsinfos, Preisauskunft und Ticketkauf zur Verfügung stellt. Und ggf. noch zwangsweise einen Tarif "Pay per Kilometer" vorschreiben. Es ist doch lächerlich (und Greta weint schon wieder), dass man heutzutage für die Fahrt von Haltestelle A in Düsseldorf zur Haltestelle B in Köln sich mit Lokaltickets von VRR und VRS unter Berücksichtigung von Übergangstickets rumschlagen muss. Wenn ich in Mannheim die Bahn vom Flughafen nach Heidelberg nehme, oder in Gent vor dem Fahrkartenautomaten verzweifele, ob eine 11-jährige nun Kind, Erwachsener oder gratis ist, sollen mir gefälligst die involvierten Dorföffis diese Informationen standardisiert zur Verfügung stellen, damit meine App mir diese Informationen in meiner fiktiven, offiziellen Muttersprache Sorbisch zur Verfügung stellen kann.

Und damit nun der Übergang zur DFS-FIS-App: Wenn ich wie durchaus ein paar Mal im Jahr nach England fliege, fliege ich durch die Lufträume von DE, NL, BE, (FR) und UK. Meinst Du ernsthaft, ich würde 5 Apps starten, von denen zwei nur in französisch sind, 2 nur durch Google zu finden, eine nicht funktioniert, jede einen Registrierprozess hat, um mir einen längeren Einleitungsanruf zu sparen? Wenn ich in Europa fliege, fliege ich mit SkyDemon. Und andere mit anderer Software. Wenn ich Öffis benutze, dann versuche ich, das über GoogleMaps zu regeln. Wenn ich ein Taxi will, möchte ich Uber nutzen - einfach, weil es da, wo es funktioniert, halt funktioniert, und ich nicht in Paris betteln und hoffen möchte, an der Taxihotline auf jemanden zu treffen, der mich bruchstückhaft versteht und dem ich irgendwie vermitteln kann, wo ich bin. Oder Bolt. Aber ich installiere doch nicht die lokale Dorf-App für Taxis!

Deswegen: Versucht doch perfekterweise, Standards zu schaffen - gemeinsam mit anderen FISen! Aber auf jeden Fall geht eine API vor jeder App! Und Geld spart es obendrein. Denn nein: Niemand von uns Piloten wird ein anderes Verhältnis zur ZÜP entwickeln, weil man jetzt die ZÜP ganz einfach über die ZÜP-App beantragen kann, mit dem großen Vorteil, alle 5 Jahre rechtzeitig einen Reminder zu bekommen und ganz einfach per Apple-Pay zahlen kann.

Apple Pay

Who ordered that?

24. Mai 2019: Von Stefan K. an Georg v. Zulu-eZulu-schwit-Zulu

Ordentlich Mühe gegeben mit der Antwort, leider am Thema vorbei. Noch einmal, es geht nicht darum, ein neues Flugplan System zu erfinden, sondern den Großteil der VFR Piloten eine Möglichkeit zu geben vor Flugbeginn WhatsApp mäßig Rufzeichen, Uhrzeit, Start und Ziel zu senden.

Beim Initial Call wird das Rufzeichen in den elektronischen Streifen geschrieben und er wird mit den Daten automatisch ergänzt. Aufgegeben FPL können natürlich auch berücksichtigt werden.

24. Mai 2019: Von Chris B. K. an Stefan K.

Noch einmal, es geht nicht darum, ein neues Flugplan System zu erfinden, sondern den Großteil der VFR Piloten eine Möglichkeit zu geben vor Flugbeginn WhatsApp mäßig Rufzeichen, Uhrzeit, Start und Ziel zu senden.

Genau darum geht es doch wohl allen hier. Die Frage ist bloß wie man das umsetzt?

Der überwiegende Teil der VFR-Piloten dürfte mit SkyDemon (SD) und Co. unterwegs sein. Diese Software kann schon automatisch Flugpläne generieren, auch wenn das wohl ab dem 20. Flugplan (oder so ähnlich?) kostenpflichtig wird.

Der Hintergedanke der API ist, daß die Navi-Software-Anbieter dann ihre System an die Api dranhängen können und der Rest dann vollautomatisch läuft. SD erkennt z.B. automatisch, ob man noch am Boden steht oder fliegt. Da könnte man dann die Software so programmieren, daß sie bei der Feststellung "ich fliege jetzt" automatisch die geplante Route inkl. geplanter Marschgeschwindigkeit und aller Wegpunkte, die Startzeit sowie den hinterlegten Flugzeugtyp und Kennzeichen per mobiler Datenverbindung abschickt.

Da ist dann jede APP, die man extra noch mit irgendwelchen Daten füttern muß, Mehrarbeit.

24. Mai 2019: Von Johannes König an Stefan K. Bewertung: +2.00 [2]

Hi Stefan,

Aufgegeben[e] FPL können natürlich auch berücksichtigt werden.

Diesen Eindruck habe ich heute nicht. Die letzten Flüge, bei denen ich "D-E..., departed 2 minutes ago, with flight plan" reingerufen habe, bekam ich - salopp gesagt - ein "mir egal, den lese ich nicht, du musst mir deine Daten trotzdem geben" zurück.

Es mag ja sein, dass Flugpläne bei euch im Büro mehr Arbeit machen. Damals, als man sich das System ausgedacht hat, hatte auch noch keiner die heutigen technischen Möglichkeiten im Sinn. Für uns Piloten sind Flugpläne jedoch ein sehr praktisches Mittel. Längere Flüge macht heute praktisch niemand ohne SkyDemon/ForeFlight/... und da fallen die FPL automatisch raus und werden digital übermittelt. Und zumindest Landemeldungen kann ich in SkyDemon auch automatisch übermitteln. Das heißt 2 von 3 Funktionen, die du angesprochen hast (Streckeninfo, Start- und Landemeldung) kann SkyDemon heute schon als "Abfallprodukt".

Um vielleicht einen Kompromiss zu finden, denn ich denke die Argumente sind hier zu Genüge ausgetauscht worden: Wenn ihr schon eine DFS-App für solche Dinge erstellt, dann macht das bitte so, dass man bei der Meldung zwischen "Short Notification to FIS" und "ICAO FPL" wählen kann.

Ansonsten kann ich euch zu eurem elektronischen Streifensystem nur alles Gute und eine reibungslose Umsetzung wünschen. Es ist schon einigermaßen kurios, dass im Jahr 2019 mir FIS zwar das METAR von Honolulu geben kann, aber nicht die Daten meines über die DFS-Website aufgegebenen Flugplans automatisch vorliegen hat.

Grüße

Jo

24. Mai 2019: Von Tee Jay an Stefan K. Bewertung: +3.00 [3]

WhatsApp mäßig....

Bitte keine weitere App, die auch noch Crashlytics-Daten mit Nutzungsverhalten mitsamt Geopositionierung an Google, Apple & Co sendet. Und mit Sicherheit wird diese nicht Open Source und landet auch nicht bei F-Droid, oder?

Weisst Du, immer wenn jemand mit einer neuen Idee um die Ecke kommt, einer App für etwas, wo es längst etablierte und bekannte Verfahren gibt, die vielleicht nur angepast oder implementiert werden müssten grabe ich diese Grafik hervor:

Ich finde FPL gar nicht mal so schlecht. Ein besseres Web-Interface bei der DFS, eine offene API und andere organisatorische Abläufe und alles gut. Bitte keine nächste App...

24. Mai 2019: Von Stefan K. an Tee Jay

OK, dann lassen wir das ganze..... immer schön alle Daten am Funk geben, dafür fallen halt ein paar Verkehrsinfos weg und manche kommen gar nicht durch.

Thema beendet....

24. Mai 2019: Von Tee Jay an Stefan K. Bewertung: +2.00 [2]

Bist Du jetzt eingeschnappt? Deswegen?

Flugplan im übersichtlichen Web-Interface (nehmt Euch mal ein Beispiel an den Schweden) aufgeben,meinetwegen auch per SD, Jeppesen & Co. Dieser liegt Euch mit allen Infos vor. In der Luft wie auf Radar mit Kennung (und auch nur mit Kennung) einmal kurz reinrufen, Squawk erhalten und Ruhe ist.

Ich wette einige von uns würden sofort mehr FPL filen, wenn damit die Aussicht auf eine solche vereinfachte Bearbeitung besteht.

Und das mit den sichergestelten Landungen könnte man als Ausnahme von der Norm laufen lassen, z.B. per Klickkästchen im Formular bei der Flugplanaufgabe (oder wie auch immer). Da gibt es doch auch Nuancen. Während z.B. die Franzosen sich sträuben einen FPL in der Luft zu schliessen, stellt das hier kein Problem dar.

24. Mai 2019: Von Daniel @RunwayMap an Stefan K. Bewertung: +2.00 [2]

Hi Stefan, ohne Statistik im Rücken, aber gefühlt handeln die meisten Funkbelegungen bei Euch vom Einleitungsaufruf mit Typ, Start/Ziel, Standort und bei den Abfragen ob irgendwelche ED-R aktiv ist. Das mit den ED-R kann man ja jetzt schon bei der Bundeswehr abrufen, bzw. einfach mal einige Sekunden bei Euch reinhören und aufschreiben was andere Fragen, wenns da ne offizielle API gibt, dann integriere ich das gerne bei uns in RunwayMap. Was den Einleitungsaufruf angeht, so wäre eine API auch nicht schlecht, dann könnte ich bei Abflug einfach einen Knopf drücken und ihr hättet die Daten. Und wenn sich was ändert im Flug, dann kann ich ja das anmerken. Also aus Sicht eines Softwareentwicklers, ich wäre PRO API ;-) kann aber auch mit Status-Quo leben. Gruss, Daniel.

24. Mai 2019: Von Sven Walter an Stefan K. Bewertung: +4.00 [4]

Moin moin Stefan,

ich bin ja immer dankbar für die ausführlichen Forenbeiträge, erstellt in deiner Freizeit, gegenüber einem öfters mal polemischen Haufen. Aber hier verstehe ich es nicht:

Also wenn der Flugplan mittelalterlich ist, Start und Landung gemeldet werden müssen, und wir uns die verstopfte Frequenz an den wichtigsten VFR-Sommerwochenendflugtagen das größte Sicherheitsproblem ist, wiese kann dann kein AIS diese Frequenz durch das Durchsehen der Flugpläne entzerren? FPL enthält nur wenig mehr als den App-Bestandteil, vermute ich.

Ich sehe hier nur (aus meiner Laien- und Nutzersicht) sinnvolle Beiträge von ITlern, und hab noch kein Gegenargument gesehen, was ich nachvollziehen kann.

Rechtliches? Würde ich verstehen, anteilig, aber das kann man ändern.

Was macht CPDLC, grob vereinfacht gesprochen, denn außer Frequenzentlastung für Normal-Ops, größere Sektoren, out of range, was man anteilig auch für FIS runterbrechen könnte? Listening Squawk ist ja auch sinnvoll für diverse Anwendungen. Hauptsache die Frequenz wird freier und die entscheidenen Dinge zur Vermeidung von Airprox wird an den Hammertagen möglich.

Technisch? Würde ich noch eher verstehen, aber wenn eine App schon ausreichen soll, ist es dann nicht doch eher ein Enthaftungsproblem? Es sind nur wenige Zusatzpflichtfelder im FPL enthalten. Fast alle haben ein Schlaufon oder Tabletrechner/ EFB. Wir haben Transponderpflicht und Halbkreishöhen - man muss ja nicht mal träumen von Transpondervergabe vorm Start wie bei IFR...

Arbeitsbelastung und Arbeitsfluss? Kann ich von der anderen Seite nicht beurteilen. Aber du um so besser. Wann habt ihr nochmal den Pilotentag in Langen?

Danke weiterhin für den exzellenten Service, und die guten Beiträge hier im Forum. Nur das hier, das verstehe ich noch nicht.

P.S.: Pilotentag wohl immer Mitte November. Und - für Luftraumbeobachtung sind ja immer noch wir PICs verantwortlich, insfern sehe ich hier kein Haftungsrisiko für die Flugsicherung. Denn SAR liegt ja beim Nutzer, der den Plan nicht schließt.

24. Mai 2019: Von Matthias F. an Stefan K. Bewertung: +7.00 [7]

Hallo Stefan,

vielen Dank für Deine Mühe hier zu schreiben.

Aus meiner (IT)-Sicht wäre es wirklich wünschenswert, wenn die DFS nur die API zur Verfügung stellt und keine weitere App entwickelt.

Eine API für:
- Abfrage von NOTAMS
- Abfrage der Status der ED-R Gebiete
- Aufgabe von Flugplänen (in von Dir gewünschter kurzer oder langer Form)

Aus meiner Sicht haben einzelne Apps noch nie wirklich zum Ziel geführt. Jeder hat seine eigenen Präferenzen und nutzt das Tool seiner Wahl. Das beste Beispiel ist Eure NOTAM App. Die habe ich ein paar mal benutzt und dann nie wieder, da ich lieber die NOTAMs in Jepessen Mobile Flight Deck auf der Karte anschaue.

Durch die zur Verfügungstellung von APIs könnte die DFS:
- massiv Kosten einsparen (die sonst für eine App-Entwicklung und Pflege notwendig wären)
- einen großen Mehrwert für viele Nutzer unterschiedlichster Apps/Software schaffen
- Eure Arbeitslast dadurch erheblich reduzieren
- nachhaltig die Sicherheit erhöhen

Wenn Du diese APIs bei Euch anregen könntest oder mir einen Ansprechpartner nennen könntest, den ich dies vorstellen könnte, wäre ich Dir sehr dankbar.

Viele Grüße

Matthias

25. Mai 2019: Von Georg v. Zulu-eZulu-schwit-Zulu an Stefan K.

Heute noch mal nachgedacht: Eigentlich ist m.E. gar nicht so spannend, Start und Ziel zu übermitteln.

Ob App oder API: In jedem Fall nutzt es ein konkreter Pilot von seinem Handy, nicht vom Vereinshandy. Damit bietet es sich eigentlich an, zusätzliche Informationen freiwillig zu übertragen, die statisch in der App hinterlegt sind. Die man aus gutem Grund über Funk nicht übermittelt:

D-EXYZ, is a DA40 with the pilot Franz Müller, capable of speaking German (preferred) and English, IFR-rated. In case of emergency and another broken ELT or if unsure, why radar signal disappeared, try to call me or localize my mobile +491721234567. In case of severe problems with my flight please inform a), b)...

Es würde auch bedeuten, dass man die Idee des Listening-Squawk wegen der Language Preferences auch zu einem "asynchronen vollen Login" auf FIS machen könnte, im Sinne von einem "D-EXYZ - you are identified in 2.300 ft on QNH 1015", das ja durchaus auch 2 Minuten später kommen kann, wenn's gerade betrieblich besser passt.

try to call me or localize my mobile +491721234567

Wobei man das dann auch noch weiterspinnen könnte in Richtung "Zweiter Kommunikationskanal im Flug."

Derzeit strahlen ja alle Mobilfunk-Antennen nach unten ab, so daß man relativ schnell nach dem Start keinen Empfang mehr hat. Würde es auch einige wenige Mobilfunkantennen geben, die nach oben abstrahlen, könnte man wohl den ganzen Luftraum bis FL100 auch damit abdecken. Hindernisse bei der Ausbreitung der Funkwellen, wie es sie am Boden gibt, findet man dort oben ja eher weniger.

Ich denke da an so Dinge wie die ED-Rs. Da könnte man automatisch im Umkreis von 10NM um eine ED-R allen Handys eine sms schicken, daß die ED-R aktiv ist. So als zusätzliche Warnung, auf das eben niemand da rein rauscht.

Per API könnte die Warnung dann auch an die Navi-Software gehen.

25. Mai 2019: Von  an Georg v. Zulu-eZulu-schwit-Zulu

Ich verstehe das Problem nicht. Das DFS Portal bietet heute eine übersichtliche Möglichkeit Flugpläne aufzugeben. Alternativ kann man den entstehenden Spaghetticode auch direkt per Fax vom Handy senden, dafür braucht es weder API noch APP. Alle Lösungen aus Navigationsprogrammen heraus basteln vielleicht Eurocontrol konforme Flugpläne, aber bei dem manchmal kryptischen DCT Geschwurbel kann ich nachvollziehen dass die Lotsen die nicht mehr anschauen. Da hat die "Digitalisierung" vielleicht einen guten alten Vorgang auf dem Gewissen.

25. Mai 2019: Von Tee Jay an 

Das DFS Portal bietet heute eine übersichtliche Möglichkeit Flugpläne aufzugeben.

Nein bietet es nicht:

Daß es woanders nicht nur anders sondern auch besser gelöst ist, das zeige ich mal examplarisch an der schwedischen AIS. Dort wird zumindest der Versuch unternommen einen Anwender an die Hand zu nehmen und durch die Eingaben zu führen und nicht gleich wie bei uns mit einem Wust an Eingabefeldern zu erschlagen:

Ich bin der festen Überzeugung, daß eine besseres UI Design und ein wenig mehr Fokus auf den Anwender auch weniger Fehler und späteren Korrekturbedarf auf Seite der Lotsen bedarf. Gleichzeitig hebt es die Akzeptanz des Systems und erhöht die Bereitschaft auf Pilotenseite dieses auch zu nutzen. Erst recht wenn nachher auf FIS alle Informationen vorliegen und nur ein Reinruf nur mit der Kennung ausreicht. Ist es makaber, wenn ich in diesem Thread schreibe, daß es auch helfen würde Leben zu retten?

Alternativ kann man den entstehenden Spaghetticode auch direkt per Fax vom Handy senden, dafür braucht es weder API noch APP. Alle Lösungen aus Navigationsprogrammen heraus basteln vielleicht Eurocontrol konforme Flugpläne, aber bei dem manchmal kryptischen DCT Geschwurbel kann ich nachvollziehen dass die Lotsen die nicht mehr anschauen.

Genau diese von Dir beschriebene Funktion besteht woanders. Hier erneut ein Screenshot aus dem schwedischen AIS:

Es würde mich sehr stark wundern, wenn es zwischen den JSP Skripten im AIS Portal der DFS keine APIs für die dahinter stehenden Systeme existieren würden. Die hier geforderten Public APIs dürften demnach in einer mehr oder minder guten Qualität bereits bestehen. Von daher denke ich, daß es eher eine politische denn eine technische Frage ist. Will man sich öffnen oder schachert man lieber einem politisch Genehmen einen lukrativen Auftrag zu?

Naja immerhin verzichtet man auf den üblichen Tracker, Google und 3rd-Party Mist, der von minderbemittelten Werbeleuten und hippen Webdesignern immer eingebunden wird (Webbkoll-Link). Soll hier positiv hervorgehoben werden.

25. Mai 2019: Von Lutz D. an 

Das DFS Portal bietet heute eine übersichtliche Möglichkeit Flugpläne aufzugeben. Alternativ kann man den entstehenden Spaghetticode auch direkt per Fax vom Handy senden

Das ist Satire, richtig?

25. Mai 2019: Von  an Lutz D. Bewertung: +3.00 [3]

Nein, das ist völlig ernst gemeint. Ich finde das DFS-Portal tatsächlich gut. Es ist überschaubar, einfach zu bedienen und tut was es soll. Natürlich muss man sich einmal die "Mühe" machen eine Vorlage für sich zu erstellen, aber dann ist die Eingabe auch von unterwegs eine Sache von wenigen Minuten. Seitdem auch die Benachrichtigungen aus dem Prozess per Mail kommen - was will man mehr? Die paar Daten aus der Routenplanung aus einer APP übergeben zu "müssen" ist doch Mimimi. Weshalb z.B. ein Skydemon oder ForeFlight nicht einfach aus der APP die Daten an den Nachrichtenversand auf dem Gerät gibt, oder die DFS .jsp Seiten einfach direkt ansteuert bleibt allerdings mysteriös.

25. Mai 2019: Von  an Tee Jay Bewertung: +1.00 [1]

Das verstehe ich auch nicht. Das Design des DFS-Portal stammt vielleicht noch aus einer Zeit als am Ende der Seite "optimiert für Netscape V2" stand und dürfte Auflösungen voraussetzen die jedes Smartphone heute bietet. Klar ist das dann klein in der Darstellung, aber das ist dann eher eine Frage der richtigen Lesebrille.

Wer unbedingt mit einem Stift auf dem Tablet arbeiten will, kann das auch tun, entweder über die Handschriftenerkennung des Tablets die Felder füllen (ok, funktioniert bei allen Betriebssystemen immer noch nur eingeschränkt) oder einfach das ausgefüllte Formular per E-Mail schicken.

Hat sich eigentlich einmal jemand die Mühe gemacht den Ablauf auf dem DFS-Portal auf Programmebene anzuschauen? Ich vermute mal ins Blaue, dass es gar keiner weiteren API bedarf, sondern nur jemand das mal genau anschauen muss, um dort direkt zu filen.

Entschuldigung, aber ich kann ein Problem irgendwie nicht entdecken.

25. Mai 2019: Von Wolfgang Lamminger an  Bewertung: +1.00 [1]

Das verstehe ich auch nicht. Das Design des DFS-Portal stammt vielleicht noch aus einer Zeit als am Ende der Seite "optimiert für Netscape V2" stand und dürfte Auflösungen voraussetzen die jedes Smartphone heute bietet. Klar ist das dann klein in der Darstellung, aber das ist dann eher eine Frage der richtigen Lesebrille.

Erinnert mich irgendwie an die Zeit meiner IFR-Ausbildung, als ich Flugpläne über das (damals brandneue) DFS-Portal aufgab, dann mit AIS telefonierte und der dortige Sachbearbeiter mir sagte "guter Mann, können Sie uns die Pläne nicht lieber telefonisch oder per Fax schicken, denn wenn Sie den Plan über das Internet aufgeben, bekommen wir das per Fax (!) und da sind die Buchstaben soo klein, dass man die nur mit einer Lupe lesen kann..."

Ich gehe davon aus (und hoffe), dass heute die Systemintergration einen Schritt weiter ist... ;-)

Warum allerdings aktuelle VFR-Pläne bei FIS nicht vorliegen, bleibt ein Rätsel. Die Begründung mit "Adressierungen" der Flugpäne kann in der heutigen vernetzten Zeit doch kein Argument sein...

25. Mai 2019: Von Tee Jay an 

Das Design des DFS-Portal stammt vielleicht noch aus einer Zeit (...)

Du verstehst nicht, Design != User Interface

...dann eher eine Frage der richtigen Lesebrille.

What? Dir ist das Konzept einer responsive auf die jewilige Bildschirmgröße angepassten Anwendung bekannt?!?! Das hat nichts mit Lesebrillen zu tun...

...Stift auf dem Tablet...

Stift? Soweit sind wir noch nicht einmal. ich wäre froh wenn das Ganze mit Touch und Finger funktionieren würde. Das Interface ist ausschliesslich auf Desktop + Maus ausgelegt. Mit Touch kommst Du hier nicht weit oder versuch einmal ohne die Klickkästchen darüber und darunter da etwas zu treffen. Und offensichtlich ist das Teil auch für einen Windows Internet Explorer ausgelegt mit sichtbaren Scroll-Leisten. Denn in normalen Browsern und Systemen werden diese ausgeblendet, so daß man auf dem ersten Blick nicht sieht, daß eine Seite unten noch weiter geht.

Hat sich eigentlich einmal jemand die Mühe gemacht ...
Entschuldigung, aber ich kann ein Problem irgendwie nicht entdecken.

Ja habe ich, nur - Entschuldigung - Du scheinst es nicht zu verstehen.

25. Mai 2019: Von ch ess an  Bewertung: +2.00 [2]

Hast du schon mal SD oder FF genutzt ? Klingt naemlich nicht so.

Die versenden direkt aus der APP an die eurocontrol Adressen. Dazu braucht man dann die DFS Maske nicht mehr, die tut naemlich dasselbe.

Nutzt aber alles nix, denn die FPs liegen trotz theoretisch einfacher Rueckuebersetzmoglichkeit bei FIS nicht vor.

Heute wieder die Alternative - Sarajevo, Banja Luka Info, Zagreb, Maribor, Graz, Wien Info, alle hatten den FP vorliegen, d.h. "Please confirm next WP" / "Proceed acc to FP". Interessieren tut nur noch SQ, QNH und wo ich gerade bin.

Nur bei uns geht das irgendwie nicht. Und wenn man das diskutieren will, gehts in den Modus "mag nicht mehr". Dabei liefert FIS klasse Service. Nur dieser Punkt ist irgendwie komisch

26. Mai 2019: Von Chris _____ an ch ess

Das FIS die Flugpläne nicht vorliegen, kann bei der anerkannt guten Arbeit der Controller eigentlich nur die Ursache haben, dass es sie nicht wirklich interessiert, was da drin steht.

Also dann doch bitte auch nicht mehr den ewig langen Einleitungsruf schulen, und bitte auch keine Fragen mehr nach dem Abflugort.

Nur Position, Typ und Destination.

26. Mai 2019: Von Chris B. K. an Chris _____

Nur Position, Typ und Destination.

Wobei ich mich da gerade frage wofür die den Typ wissen müssen? Sollten die den mit der Registrierung oder der 24bit Transponder-Adresse nicht eh haben?
--> https://www.lba.de/SharedDocs/Downloads/DE/Formulare/T4/Formulare/LBANr02.pdf?__blob=publicationFile&v=1

Wenn ich mir das Formular so angucke, könnte man sich den Einleitungsanruf wohl komplett sparen. Sobald die entsprechende Transponder-Adresse auf dem Radar auftaucht, hat die Flugsicherung damit automatisch das Kennzeichen und den Flugzeugtyp. Der "Flugplan" ist ja schon automatisch während des Startlaufs von SD und Co. übermittelt worden.

Da hätte man dann die Einleitungsanrufe komplett los und niemand müßte zusätzlich die Flüge irgendwo in irgendeinem Web-Portal eingeben.

Und was die Destination angeht, sage ich nur "Kalkutta". ;-)
Irgendwo hatten wir hier doch mal die Diskussion, inwieweit man Start und Ziel nennen muß und das sich da jemand bei der Startfreigabe geweigert und "Kalkutta" angegeben hat. *grübel*


  457 Beiträge Seite 18 von 19

 1 ... 18 19 
 

Home
Impressum
© 2004-2024 Airwork Press GmbH. Alle Rechte vorbehalten. Vervielfältigung nur mit Genehmigung der Airwork Press GmbH. Die Nutzung des Pilot und Flugzeug Internet-Forums unterliegt den allgemeinen Nutzungsbedingungen (hier). Es gelten unsere Datenschutzerklärung unsere Allgemeinen Geschäftsbedingungen (hier). Kartendaten: © OpenStreetMap-Mitwirkende, SRTM | Kartendarstellung: © OpenTopoMap (CC-BY-SA) Hub Version 14.22.03
Zur mobilen Ansicht wechseln
Seitenanfang