Closed KayRJay closed 4 years ago
ericberman
commented
4 years ago Can't do this for a variety of reasons. But one thing you can do is use the merge telemetry tool in the playpen to create a single lowest-common-denominator flight telemetry file.
KayRJay
commented
4 years ago Ok. Thanks.
Too bad, though, as it would be handy, since I assume many flights do visit multiple airports.
On May 23, 2020, at 3:58 PM, Eric Berman notifications@github.com wrote:
Can't do this for a variety of reasons. But one thing you can do is use the merge telemetry tool in the playpen to create a single lowest-common-denominator flight telemetry file.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/606#issuecomment-633145804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBRDECYMZGHPILFWPRGWGDRTBBGTANCNFSM4NITUCQA.
ericberman
commented
4 years ago Indeed - I also frequently visit multiple airports in a single flight (flight entry). Why not do it all in one telemetry file? That's what I do. Several ways you can do this: a) just record from start to finish, optionally pausing while you eat lunch. That works great, and is what I do. (E.g., if you use the iOS or Android app to record). Or you can record using Foreflight in the same way, or using a GPS logger... b) Flightaware is just giving you KML or GPX, so you can merge them using https://myflightbook.com/logbook/playpen/MergeTelemetry.aspx without losing data (well, at least without losing data that I could do anything with).
Mostly I'm not clear what advantage multiple files have over a single file.
Some of the reasons I can't do multiple files:
KayRJay
commented
4 years ago I agree that if I remember to record my flight in MFB or Foreflight, I’d get a single file. But I don’t always use one of those methods during a flight.
In fact, I’d like the various telemetry files for a multi-segment flight to be one telemetry file if it's not captured during flight. Flightaware doesn’t have a feature to combine segments. (Now, that would be nice!)
I mis-stated my intention … I don’t really want multiple telemetry files per flight. I’d like an easy (not-manual) way for MyFlightBook to combine the telemetry files.
Since you have an existing tool, I’m suggesting you integrate it into the process of adding telemetry to a flight. It would work in a simple way: if the flight already has a telemetry file, and another is added, ask if the user wants to (automatically) stitch them together. This need not work for bulk upload.
ericberman
commented
4 years ago So it becomes an "Append telemetry" (or "merge telemetry") feature? hmmm...
KayRJay
commented
4 years ago Yup!
On May 23, 2020, at 4:33 PM, Eric Berman notifications@github.com wrote:
So it becomes an "Append telemetry" (or "merge telemetry") feature? hmmm...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/606#issuecomment-633149107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBRDEBAU5GQZQ4P4KTCDULRTBFMJANCNFSM4NITUCQA.
ericberman
commented
4 years ago Thinking about this a bit more: because I have to go to least-common-denominator, append/merge is destructive in the general case (part of why I put it into the playpen in the first place). I'm not wild about that. E.g., if the existing data is CSV from your panel and includes things like EGTs/CHTs/Oil Pressure/etc., and you upload GPX, then you will lose the engine data. Or, if you had speed in the original data and the new data lacks speed, then you will lose speed.
I am not inclined to do this. Merge the data in the playpen and verify that you like the result before you replace your existing data.
KayRJay
commented
4 years ago Makes sense. Or, offer the merge/append only when the new track log is in the same format, and advise the user otherwise that he must manually pre-merge.
Sent from my iPhone
On May 24, 2020, at 11:11 AM, Eric Berman notifications@github.com wrote:
Thinking about this a bit more: because I have to go to least-common-denominator, append/merge is destructive in the general case (part of why I put it into the playpen in the first place). I'm not wild about that. E.g., if the existing data is CSV from your panel and includes things like EGTs/CHTs/Oil Pressure/etc., and you upload GPX, then you will lose the engine data. Or, if you had speed in the original data and the new data lacks speed, then you will lose speed.
I am not inclined to do this. Merge the data in the playpen and verify that you like the result before you replace your existing data.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
KayRJay
commented
4 years ago Seems you do know the type of file previously listed (per issue #608) so can’t you auto-merge if the new telemetry file is if the same type as the existing file?
ericberman
commented
4 years ago No, it's not just a function of common file format, it is really a function of common data schema. Think about CSV, for example: it's a common format (rows of comma separated values), but there is no schema at all. So one CSV could be latitude/longitude/timestamp from your iPhone, while another could be a bunch of engine parameters from your panel. KML has a schema, but it's completely optional what's included: it might have speeds, might not; it might have timestamps, might not, might not even have a path (or it could have multiple paths, with no indication of which one to use, or what order they should be in). And so forth. (GPX, at least, is pretty structured and guarantees timestamped latitude/longitudes. But even it doesn't guarantee a speed).
So my merging algorithm doesn't even try to figure out what things they have in common. It does a star architecture: for each file to be merged, see if it can extract time-stamped positions (I'd have to look at the code to even see if I try to preserve speed). I do that for each file to be merged, sort them, and then produce a GPX file. Not accidental that GPX is the merge output; it matches the only subset I look for.
Solving this in a more general case is hard and a ton of work for only minimal incremental value.
KayRJay
commented
4 years ago Got it. Thanks.
Sent from my iPad
On May 24, 2020, at 10:48 PM, Eric Berman notifications@github.com wrote:
No, it's not just a function of common file format, it is really a function of common data schema. Think about CSV, for example: it's a common format (rows of comma separated values), but there is no schema at all. So one CSV could be latitude/longitude/timestamp from your iPhone, while another could be a bunch of engine parameters from your panel. KML has a schema, but it's completely optional what's included: it might have speeds, might not; it might have timestamps, might not, might not even have a path (or it could have multiple paths, with no indication of which one to use, or what order they should be in). And so forth. (GPX, at least, is pretty structured and guarantees timestamped latitude/longitudes. But even it doesn't guarantee a speed).
So my merging algorithm doesn't even try to figure out what things they have in common. It does a star architecture: for each file to be merged, see if it can extract time-stamped positions (I'd have to look at the code to even see if I try to preserve speed). I do that for each file to be merged, sort them, and then produce a GPX file. Not accidental that GPX is the merge output; it matches the only subset I look for.
Solving this in a more general case is hard and a ton of work for only minimal incremental value.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
if a flight visits multiple airports, it should be possible to record multiple track logs. I added a Flightaware track log, and the second one I uploaded overwrote the first.