ericberman
commented
4 years ago Three separate issues here; I fixed what I consider to be the bug here.
The first is multiple codes for the same airport. KGPI is the current ICAO code for Glacier, KFCA must have been a prior one. But - and this is key - there are NO airports with multiple ICAO codes. KFCA no longer exists, period; it is not (currently) a valid ICAO code. I keep KFCA around precisely for historical reasons (so that prior airports map correctly), but there is no longer an ability to fly to KFCA. Indeed, if you log a flight to KGPI and then a flight from KFCA, it would (until issue #2 below) show in visited airports as two visits to KFCA (because I do dedupe by latitude/longitude). But as in Lord of the Rings, "There can only be one ICAO to rule them all". KFCA is deprecated, and as soon as it gets assigned to a new location, KFCA will unambiguously mean that new location.
The 2nd issue is how to resolve multiple airport codes for a single airport. Maui is OGG (IATA) and PHOG (ICAO); Heathrow is LHR (IATA) and EGLL (ICAO); San Francisco is SFO (FAA) and KSFO (ICAO), etc. Note that MANY (most?) airports in the database have an ICAO but not an IATA, or an FAA but not an ICAO, some have all 3, some have only 1, some have none! (e.g., private fields with a made-up name). For this reason, I don't even bother labeling the code as IATA/ICAO/FAA; it's just a 3- or 4-letter(digit) code. My current solution for this is to have multiple airports in the database under different codes and to mark one of them (typically the ICAO, if available) as "Preferred." I think this is the right solution: when you hit "nearest" in the app to pick up the airport closest to your departure/landing position, it will pick up the "Preferred" airport.
In the case of KFCA/KGPI, I had both (erroneously) marked as preferred. I just fixed that - that was a data error (good issue, thanks for bringing to my attention!). KGPI is now marked as preferred because that is its current identifier, and is the correct one to use. Nobody should currently be logging flights to KFCA, but there's no reason to change historical flights to KFCA to reflect something different.
And that leads to the 3rd issue: giving users the ability to define aliases for existing airports, or to pick non-preferred aliases, or to modify old entries to use updated aliases. I do not support this as a feature. If I support +KGPI, then I also am supporting +KFCA, and there is no reason to support the entry of new flights with an obsolete code - especially since that obsolete code is at (high?) risk of being re-assigned to a new location at some point in the future, at which point I will resolve it unambiguously to that location. It's obsolete, you shouldn't be using it any more.
Which begs the question: when an airport code becomes obsolete, should I modify your prior entries to reflect the new code? (What happens if an airport closes?) My answer to this is "No." I do not believe I should modify people's logbooks, that's not my job, and it's got infinite potential downsides for very limited upsides. When you see an airport in your visited list that's wrong due to an airport code reassignment, it is (a) your choice to edit the old flights to reflect the new code, or (b) just ignore it - your entry was valid at the time, it's still valid, it's just obsolete. I wouldn't presume to decide that on anybody's behalf, for the route of flight or for any other data.
The problem you raise is a valid one, but the correct solution is to have any new entries use the new code, not the old one. Some data management is absolutely required for this, but I think that's a manageable problem and the right solution.
KGPI and KFCA are two codes for the same airport. I would prefer that they always be displayed as KGPI, even if I entered KFCA when the flight route was entered or edited.
It is reasonable to minimize development effort and avoid database changes in the implementation strategy. Here's an idea ...
When entering a new flight's route, a user could prefix an airport code with a special character (e.g., +KGPI). That code will become the preferred code for that airport for that user. For a given user, there would be at most one preferred code designated in this way. If the user enters a new flight indicating a different preferred code (e.g., +KFCA), that code becomes the preferred code.
Now, to avoid requiring any new data structures to record this preference, MyFlightBook would silently update all the user's flights (previous or newer) involving the indicated airport to use the preferred code (if/when one is entered). This method ensures that all the user's routes visiting any given airport use the same code. This also automatically takes care of displaying routes with the preferred code.
Users are unlikely to visit airports with multiple codes (since few exist), and when they do, they are likely to enter the preferred code each time (and not use the prefix character), so automatic editing will happen infrequently.
When the user enters a route, MyFlightBook would (always) look to see if the airport has multiple codes. In the infrequent case where it does, MyFlightBook needs to see if the user has previously visited the airport using the newly entered code. If so, don't make any changes in the entered route, allowing the user to sometimes use one code, and other times use another. If not, but a prior flight visited that airport with a different code, replace the entered code with the code the user has previously entered for that airport.
Now, I didn't program this or even try it with sample data and pencil and paper, but I think it works ...