Closed apps4av closed 7 years ago
For base ambiguity, use full ICAO code for example, KMFR
Fixed
The "Type" column should use strings {NDB, VOR}, not {Navaid, Navaid} -- that would have at least made this ambiguity self-describing.
NDB Vs. VOR not fixed.
I noticed one weird thing: on the middle leg, RBG said "navaid" on the plan page, but drew the course line to the airport (KRBG). In this case, it was conspicuous, because the VOR is displaced 5nm or so from the field. Trivial to repro: enter "SLE RBG MFR" in the plan box, and Create. MFR will get converted to "base" (I'd prefer to see "KMFR" in that case, actually, as it's a quick cue -- not sure that UI extends well outside the US, though.) SLE and RBG will show as Navaid.
SLE shows up at the SLE NDB (there's no SLE VOR, apparently). I don't see it charted, but perhaps RBG has an (uncharted) NDB... sure enough. And, indeed, if I use "add waypoint to plan / search", I have the opportunity to select the VOR, and that all works correctly. Conclusion:
When a plan substring is ambiguous, I probably meant the VOR, not the NDB. (I use the plan string input method heavily -- it's the fastest way to insert a new waypoint into the plan! Just poke the cursor to the right place, type a waypoint, and create it over the old one. And Activate it. So I heartily don't want a modal disambiguation dialog.
The "Type" column should use strings {NDB, VOR}, not {Navaid, Navaid} -- that would have at least made this ambiguity self-describing.