Reasonableness checks for numbers of landings

[KayRJay]

Need additional checks on numbers of landings:

• Very high number of landings
• Number of power off and stop-and-go landings vs total landings

It's now possible to record hundreds of landings for a single flight. A check for reasonableness might be <=1 landing every n (n=2?) minutes?

[ericberman]

Lots of people use catch-up flights to record bulk historical things. Yes, I suppose I could check for a rate-of-landings (# of landings divided by time of flight), and I could put that into the checkflights, but I don't think this is problem in the data today.

[KayRJay]

Since the flight check is really optional, and you can record flights with "bad" data, it doesn't seem a problem to make these three checks. People who are using it for catchup sums would simply add the flight anyway.

[ericberman]

I dunno, part of the reason I did the flight check feature is because there are surprisingly few "error" cases that are actually error cases. Over the years, I've added lots of them, and removed almost all of them because they are actually legitimate.

And because you could be adding flights via web service or bulk entry, something is either an error or it isn't; I can't do "hey, are you sure about x?". Something is either truly an error, or it belongs in flight check. I can't be an arbiter of bad data other than truly erroneous data; merely suspicious isn't enough.

[ericberman]

Doing this in flight check isn't a bad idea, but I don't know what the right check for reasonableness is. When I got my float plane rating, for example, I could absolutely do 1 landing every 2 minutes, easily. Actually, I could easily do more than that - I remember flying along at 25mph (yes, mph, not kts!) just a few feet above the water and gently touching the floats to the water every few seconds, then lifting them.

Helicopters too.

Inevitably, I find there are legitimate scenarios. So a flight check is the only place this can work. But even there, I need a more reliable definition of "suspect".

[KayRJay]

It’s very easy to make a typo in number of landings. Enter 1 in Total Landings and 2 or 10 in stop-and-gos. Slip of the finger, really. It’s not a matter of suspicion then, it’s simply wrong ... or at least very probably wrong. But again, it’s only a warning.

You already make similar checks (total landings vs. full stop day and night). I don’t see a good reason to not do so for stop and gos or power-off landings. Consistency and thoroughness are usually considered positives.

I don’t often add flights via bulk entry. In fact, never. I try to keep my logbook reasonably current, so it’s easy just to enter a few flight(s) when I get back from my lesson(s).

I don’t understand this comment:

Something is either truly an error, or it belongs in flight check.

Isn't this exactly what we're talking about here? This (more power-off landings than actual landings, for example) is something that looks like an error and most likely is an error. Since the three scenarios here may or may not be errors, it seems it does belong in flight check.

I'm having trouble imagining the "catch-up" scenario here. It seems a catch-up flight wouldn't be a real flight, but a bogus flight that simply includes values that should contribute to totals, and not be a subset of values for an actual flight. Also, the most common thing being added (and checked) is an actual flight. Seems quite sensible to catch (possible) errors early (at the time the flight is added), rather than never at all.

[ericberman]

More power-off landings that total landings can indeed be an error. I do similar checks for approaches: you list the total number of approaches, and then you can describe various subsets, but none of those subsets can be greater than total. There are currently 71 (yikes!) different landings properties I'd have to do this sort of check for, and they can combine/overlap in ways I'm not sure of.

Lots of people do bulk entry; in many cases, it's how they first come to the system, either from another logbook or their own spreadsheet. E.g., at the moment, I have 4.4M flights that have been imported, and another 4.6M flights that came via webservice (i.e., the mobile apps), out of 9M flights. The two subset counts overstate things (the import one in particular) because they get incremented on import/web-service add, but don't get decremented when you bulk delete flights (not uncommon for people to mess up a bulk edit or import and do a bulk delete - that can be thousands of flights in/out at a time). But my point is that these are not minor paths to flight entry.

I had proposed doing something here in flight check, I thought you had pushed back on that, that they were legitimate errors. E.g., when you say "at the time the flight is added", that sounds like "display an error or warn & confirm", not flight-check, and that's where I go very conservative on what is and isn't valid; I've backed out almost all "semantic" checks over the years because inevitably they cause more harm than good. (And because of so much bulk entry and web service, "warn and confirm" is simply not an option).

Catch up flight is indeed a placeholder flight, but it is a flight like any other; it is not "bogus" in any sense of the word except; it is an aggregation of many flights. There's nothing magical about it except it typically has "large" values. If you use Logbook->Starting Totals, it creates these flights for you. But once created, there is no magic flag that would tell me to treat it differently from any other flight.

[KayRJay]

Of course it's a judgement call to decide how many of those 71 properties to cross-check. It seems likely that the users of the more "esoteric" landings properties know what they're doing. But for "basic" properties (landings vs. full-stop vs. power-off vs. stop-and-go's), it would seem appropriate to make the additional checks.

I'm sure bulk loading is important, and clearly would be the source of the majority of flights if people are transitioning from other e-logbooks. I wonder though how many users continue to use bulk load after their initial import? Maybe most do use the life tracking. But there have to be some like me who enter their flights manually. (And thanks by the way, for cleaning up the data entry pages for new flights ... much better!)

When I said "at the time a flight is added", I really was referring to the magnifying glass icon, which I am prone to click on before adding the flight. So, I'm not suggesting you do automatic sanity checking, which could get burdensome. The current model works well to give people the choice.

I wasn't trying to imply that a catch up flight should be treated differently by the system. It is almost certainly treated differently from a normal flight by the user. That's why it's fine to allow 100s of landings for a 0-hour "flight" (and by allow, I mean flagging it IF a user choses to "check" the flight, which he can then add). But except for that rare occurrence of adding a catch up flight, it would seem to do no harm, and some good, to flag such a condition.

[ericberman]

Warning added, will be live when I get around to taking out an update.