Is there a reason for a VFR flight plan not to file at the airport, just before getting in the plane?
Usually you would be right but there are a few cases where somebody does look at a VFR FP and it can be better to find out before you get airborne. Not often in the N European scenario but “down south” they do sometimes get chucked out (cancelled) if somebody doesn’t like e.g. the route. It’s happened to me, a long time ago.
Noe wrote:
Is there a reason for a VFR flight plan not to file at the airport, just before getting in the plane?
Yes. See e.g. this quote from Hungary AIP ENR 1.10:
Unless special circumstances require a flight plan shall be submitted prior to taxi for taking off not earlier than 24 hours and not later than 60 minutes before Estimated off Block Time (EOBT).
Of course its enforcement varies. For domestic VFR flights entirely in uncontrolled airspace, I have filed the flight plan 15 min before EOBT and it was accepted and I received flight information services as a flight with a flight plan. But good luck with crossing an international border or trying to get clearance to a controlled airspace if you do not submit it in the specified time frame without being in special circumstances.
Peter wrote:
Usually you would be right but there are a few cases where somebody does look at a VFR FP and it can be better to find out before you get airborne.
Not a “few” cases, but down here (Hungary, Slovakia etc.) somebody does look at all the VFR flight plans and having one will do some good things for the lowly VFR pilot. Less busy CAS simply “disappears”, because they coordinate transitions based on your planned route 99% of time and for the busier CAS (like Budapest TMA) your chance from getting entry improves from 0 to something much higher.
Thank you for all the replies.
As a small time recreational pilot I have a simple question. How is the flight plan transmitted to the addresses ie the airfields etc. Is this by email?
John
VFR flight plans use the AFTN which is a very old comms network that used to run on the Telex system, and probably still does so in remote parts of the world.
Nowadays it is mostly implemented on leased lines (not the general internet, apparently, for security). Several years ago I was on a visit at NATS and they had a diagram on the wall showing the various leased lines and their bandwidth… some were really slow e.g. 1200 bits/second, from vague memory. You may be able to find that network diagram on google.
Also have a look at this
I have just heard back from EuroFPL.
They do not delay the injection of VFR FPs into the AFTN. So your /DOF has to be correctly implemented by the addressees otherwise the FP is likely to get lost.
They recommend:
I come here every now and again to gauge what the general perception of SkyDemon is, and I came upon this thread.
As far as I know, this (Corridor A9.1 missing a frequency) has never been brought to our attention directly… Nonetheless, I looked into it just now.
Interestingly, it seems that this area is defined only in ENR1.4 of the AIP, and unlike other airspaces (as defined in such pages as ENR2.1) it does not give any kind of frequency, callsign, or ID reference… Obviously, if that data is absent then our tools and processes cannot pick it up.
I a writing to the Swiss AIS to ask how they determine the frequency for this corridor (and also its cousin, A9.2). If there is no formal promulgation of this data (such as – a guy just writes it onto the chart), we will probably continue to omit it since we need to have a clear understanding of how any data is updated before we allow it into SkyDemon. With any luck though, we will start to see these corridors promulgated in a more sensible way, as proper airspace definitions with clearly outlaid frequencies as well as the usual other associated data – to the benefit of everyone.
Rob – do you never incorporate pilot reported data in Skydemon?
And it isn’t just pilot reported data that a usable flight planning app needs. Far from everything is in the AIP. A lot of data especially for smaller airfields is not in the AIP and comes from all sorts of unofficial publications.
The other issue with not incorporating e.g. pilot reported data is in the opposite sense: it forces you to disregard reports of errors if the AIP contains the wrong data. And there is a dilemma…
This is a bit tricky, because in some cases it is pretty clear that SUPs are used lazily, and we don’t really want to be introducing manual processes to control for something that is ultimately the AIS’s responsibility to get right; it will only encourage them to be even more lazy, and thus increase our workload to an untenable level over time. It is also true that sometimes SUPs are published with no trigger NOTAM at all so the optimal solution would seem to be for some oversight at the promulgation phase to ensure that bad SUPs and NOTAMs never actually get published…
We are a very small team, running an incredibly lean operation, and we achieve that by using automated processes wherever possible. Manually checking and making a decision to override the actual date on a NOTAM would be laborious AND introduce room for human error on our side. To be frank, that sounds an unsustainable and retrograde step, extremely unlikely to be actioned.
I will write to the Czech AIS now and beseech them in this case to just publish a NOTAM that lasts for the duration of the SUP. Unfortunately, only a massive outcry by users – complaining to the actual promulgators of this data – is going to affect whether or not a future SUP is published like this… I use my leverage as best I can, but I can only have so much impact if the problem is systemic.
We do not simply integrate data based on a single report, because there needs to be a clear vector for us to update that data later – otherwise our software would become bogged down with out of date nonsense. There are countless well meaning crowd-sourced airfield info websites with this problem.
When a pilot comes to us with new data, we tend to verify it and establish exactly where that data is promulgated so that we can introduce the source into our AIRAC processing. Sometimes that source might be un-official but still reasonably reliable (such as the published VFR flight guides, or the actual owner of a private airfield) which we can then return to for confirmation, or which ideally push updates to us on a regular basis.
When pilots report problems with AIP data, we do not simply disregard it! We go back to the AIS unit that produced the error and work with them to resolve it – I have personally done this countless times, not just for the benefit of SkyDemon users, but for users of RunwayHD, PocketFMS and all the others! We all rely on the data, and we need to trust that all elements of its provision is being thought about carefully before being published. Sometimes things go wrong (it is inevitable) but it is important that the response to that is not just to shrug and say “that’s how it is…” but to understand how the problem occurred and to try and make sure it doesn’t happen again.
Rob,
I am in touch with Czech AIS unofficially. They are just following the guidelines by ICAO – NOTAM can´t be re-issued and must be converted into AIP SUP when it´s more permanent nature. So they can´t go against what they have to do. TRIGGER notam was published but it has a limited duration by guidelines as well.
I understand this is manual work but I already suggested to volunteer to let you know when the AIP SUP is cancelled. I see no other way how to handle that.
