APDL and Logbook Pro for Android are now in public beta. Click here to join the public beta and install the latest versions today.

Reply to thread

Message: [QUOTE="Andy Adams, post: 40202, member: 3283"] 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. [/QUOTE]

Verification