Feedback Estimations?


Well-known member
Aug 31, 2009
Maybe I missed it, but what is the intended use of the (what I believe are) new estimated taxi and block times? Are the taxi estimates dependent on airport? Anticipated LGA taxi times are drastically different than MDW taxi times.

What I see while using is a lot of amber times for every flight. Sometimes because I taxiied for 25 minutes and the APDL estimate was for 10, so now the estimates show me 15 minutes late. All this despite the fact that the flight was planned for 30 minutes of taxi, and I'll still be early. I can see the utility of this capability, but for it to display in a place I go on every flight to log times adds confusion. I don't want to edit the estimations on every flight just to get more accurate info in APDL when it's not needed. Can we make it optional or in another screen to be accessed if needed?


Sent from my iPad using Tapatalk
Sorry about all of the posts. Welcome back from Thanksgiving weekend!

Sent from my iPad using Tapatalk
You could leave 15 minutes early and the estimates are orange. I believe all estimates are orange, even if you are estimated to be early.

You can tap on the estimates section to modify the values. This replaces the What-If function.
That's my point. Even if you leave early (& then I wouldn't expect many/any legality issues) times are orange. They will always be orange unless you push at exact time. Always signaling there's an issue, but not usually is one. I don't want to have to do extra work to modify the times when there is not expected to be an issue. As I see it anyway. Seems excessive.

Sent from my Pixel using Tapatalk
It seems we are running into an issue of capability vs convenience.

One of the things we have with the estimations feature is an improvement to the previous “projected mode”. Previously, projected mode would only take out time and add block time to it. This was not considering any off or on times and if you were flying out of LGA for example where taxi times are known to vary widely, you could potentially get off the ground much earlier than planned by your company and then arrive much earlier than the block time would suggest. Projected mode had no concept of planned taxi time so the projections could be off a little bit.

Now we have added through the estimations feature, the ability to input planned taxi times which allows for a calculation from off time which will correct for the above mentioned short/long taxi issue. This brings us to an interesting point where we have the ability to upgrade projected mode to be much more accurate, however, APDL has no way of knowing what the actual planned taxi time or flight time is for any given flight since that information isn’t available from our cloud resources. So we have to start with a default value. If your planned taxi time is close to the default, the new projected times will be more accurate, if it isn’t, they will be worse.

So the feature itself is more accurate, it all depends on the accuracy of the data it has to calculate from. Taxi time being the variable in this case.

The second part of this issue becomes desired usage by users. Projected mode is obviously nice to have when it projects how the remainder of our day will look as a result of a delay or something similar. As a user, typically we don’t want to have to manually enable something every time we want to view it. So we want it to happen automatically. That’s how projected mode has always been prior to now. Given the circumstances here, taxi time will never be known to APDL without the user manually entering it. So if we want this more accurate feature to be automatic, we have to make an assumption.

This means if you don’t enter the specifics, it’s possibly gonna be a little off. If you don’t NEED it to be super precise on that leg/day, then it’s just an estimate and can be ignored. The benefit is when you are in a tight situation and need to know the exact values, you are able to enter all known information, including the expected taxi time, and hopefully avoid the “back of a napkin” calculation.

So the trade off as I see it for this scenario would be:
1: turn off automatic projected mode/estimations so it doesn’t show inaccurate predictions. This REQUIRES you to manually enable the feature and/or enter specific times EVERY TIME you want to see projections. Lose the quick glance rough estimate ability
2: leave it as is and if you don’t enter specifics it’s automatic and close and you can ignore it if desired, yet when you do enter specifics it’s more accurate than before.

I personally like the idea that it is as automatic as possible and works in the background for quick glance situations, which is the vast majority of cases for me. If I look at a projection, I know it’s just an estimate and usually that’s plenty good. If I want to know more precisely, then I’ll go enter the necessary data and get the more precise values. The times I really need to know Uber precise times is extremely rare compared to the times I don’t. Less than 1% in my experience.
The enroute times have always been very close to planned, I had just assumed that you guys were taking actual completed flights and calculating an average. Granted flying at .68 is going to be much longer than flying at .82 but I just assumed you guys had some metrics going on in the server.
I think there’s a setting for default taxi time somewhere. Can’t look right now. Enroute time is block - taxi in - taxi out

I looked, and couldn't find anywhere I could set a default taxi time. I did find a setting in the settings to toggle off "enable taxi time." I turned that off, and will see if I like that better.

Sent from my iPad using Tapatalk
Thank you for the excellent explanation behind the feature of estimated times, Andy!

To your point of only being pertinent maybe 1% of the time (which I agree with), I guess I would rather not see it at all the other 99% of the time. For me, timing issues sometimes sneak up on me. Other times, you absolutely know it will be an issue. If you frequently create a situation where the time is highlighted, the user will learn to ignore it and could miss the time when it is pertinent. I thought the old projected method was sufficient, but I rarely ever used it. I admit that I don't have any ideas for a better solution. I will think on it though. Thanks for all of the work you guys do!

Sent from my iPad using Tapatalk
Enable taxi time is something different. That’s for logging FAR 1.1 flight time if you choose to do so. It allows you to enter an additional time “taxi time” which is the first time the aircraft moves under its own power. Separate from block out time. This would only be used
1. If your airline uses taxi time instead of pushback time for legality calculations or
2. If you want to extend your FDP by a few minutes here and there in order to complete your duty day legally where it wouldn’t have been legal if you used pushback time for each leg. I highly suspect you can’t just do that all Willy nilly without company concurrence, but according to the regs I think it could technically happen.
Ahhhhh, yes I never used that either, so just as well that I turned that off too. I still don't think that creating a feature and teaching the user to ignore it by default is necessarily a good idea. But, I'm just a pilot, and not a software designer. Overall, the product is awesome!

Sent from my Pixel using Tapatalk