Yes – a direct comparison of the route distance shown by different tools is not always possible due to the sid/star distances which are sometimes outrageous… I think there is an option to display the sid/stars.
An attempt to create a route from Enstone EGTN with a “semi-legal” ICAO code (present only in some databases) first substitutes it with ZZZZ and then reports “Error: unknown identifier ZZZZ”.
Hi Achim,
Yes, this control is … not that great. You have to press enter after filling in a field. I’ve had many hours of fun programming with jqGrid but I’m now too heavily invested in it to dump it I’ll see if I can improve the experience.
No need, once you get to know it it works fine. All I’d change is to put a remark in the text.
Good point. Fuel, W&B, landing and takeoff distance is not full implemented yet. This will come at a later point with all the bells and whistles.
Great. If I can help do not hesitate to call on me. I once did the same thing (program a flightplanner) so I have a few ideas if you need them. And they did include planes up to the 747. you have my mail if you need it.
Another good point, I’ve created a ticket for this.
Another thing I noticed is that the flight plans do not have EET/ for the FIR boundaries. I believe they still are required, so that is another item to be addressed.
Great. Really like your work here. Are you in Friedrichshafen by any chance?
Best regards
Urs
FIR boundary EETs are required on VFR flight plans only.
Well – I hope so because that’s what I’ve been filing since 2006 
Peter,
FIR boundary EETs are required on VFR flight plans only.
Ah, I’ll have to check this, we have it for every flight plan. Certainly they are required for some countries. In our planning system as well as the one I used at the airline they are still there. Maybe make it optional for now? I’ll talk to some people about it from the AIM here, they should know.
Edit: Ok, just had a chat with our AIM here:
- FORMALLY: The EET/ groups are still valid and have never really been disbanded. According to the book, they are still a part of a normal flight plan.
- INFORMALLY: Within Eurocontrol the EET/ groups are not regarded as a “reject” criteria anymore, however, they are required for flights to Eastern Europe, for the NATL and for “several” countries in Asia and Africa. According to my information, most airline planning systems have them and use them out of principle. The way I understand it, while CFMU won’t bitch when they are not there, the formally correct way would be to include them.
- They are required for VFR plans and for plans which include VFR parts however.
We had them in our system because we didn’t know that CFMU doesn’t care about them. By principle and if you ever plan into places outside the immediate EU area I’d say it would be valid to put them in there at least optionally.
we have it for every flight plan.
Same here. PPS generates them and whether or not they are required, they obviously don’t harm.
An attempt to create a route from Enstone EGTN with a “semi-legal” ICAO code (present only in some databases) first substitutes it with ZZZZ and then reports “Error: unknown identifier ZZZZ”.
The ZZZZ support is not complete yet. I’ll create a ticket to track progress.
Another thing I noticed is that the flight plans do not have EET/ for the FIR boundaries. I believe they still are required, so that is another item to be addressed.
There is one version of the flight plan with EETs to all waypoints, this also includes the FIR boundaries as they usually have a waypoint. As Peter said, there is no need to specify them for IFR flight plans. However, I’ve logged a ticket for this as a feature request. It could be nice.
Another bit I noticed:
I notice that we get a lot of level changes. If you can think of a way to avoid them where possible, e.g as a “flatten” function (selectable). We had that and what it did was to seek out the lowest flight level which could be kept for a certain amount of time or distance and then go there and stay there.
I notice that we get a lot of level changes. If you can think of a way to avoid them where possible, e.g as a “flatten” function (selectable). We had that and what it did was to seek out the lowest flight level which could be kept for a certain amount of time or distance and then go there and stay there.
That’s a tough one. One can follow the strategy and go for the shortest/fastest route and hope to not have to do the level changes en route or go for a longer route with fewer level changes. We do use the aircraft’s model to estimate the cost of a level change but it can still be beneficial in our model. Internally we assign “penalties” to such things and we can freely adjust the weight of the penalty but at this point we do not offer this configuration option to users because it is rather sophisticated. This input is good though as we plan to play more with our optimization targets to better meet user expectations.
they are required for flights to Eastern Europe, for the NATL and for “several” countries in Asia and Africa
That’s probably true, but then once you go outside the Eurocontrol zone, all flight plans are treated the same whether IFR or VFR. They are just messages sent A to B on the AFTN. There is no database storage (other than a country’s own “national security related” storage, like e.g. the UK runs) and there is no validation. And they disappear the same way, on a bad day
I notice that we get a lot of level changes
That, unfortunately, is an integral part of the game which lower airway pilots have to play with the Eurocontrol software, to get good routings. The original routing tools do/did the same thing. ATC ignore these changes – except for the caveats I mentioned earlier.
