Open dneuge opened 4 years ago
Flight plan revision numbers overall seem rather unreliable. It may make sense to add a counter for the reset iterations to revision numbers on graph entities to count up every time the revision moves backwards (JST20: 1.4 => 2.3).
Before splitting a flight, track data should be checked if available. Most times inappropriate splits can be observed, aircraft are on ground with no movement in between (JST20). If last and first track point are both in-flight during a reconnect (BAW47C), range of movement should be checked for plausibility (range of geocoords based on GS over time passed). Joining flights by plausibility of movement should be limited to a maximum constant and a reasonably short time frame (10 minutes max.).
Flight plan revision numbers have been removed from JSON v3 format and graph import needs to be adapted to work without that information in the future (#13). That change in processing may result in this issue being solved for legacy files as well. #13 will check compatibility for old and new data files.
Currently, any reset of flight plan revision read from data files will trigger a new Flight. That simple approach leads to unnecessarily split flights, for example: