Small Request: Add prefix for Airports as waypoints without considering them visisted

[fkrauthan]

I have a very small request/idea. Let's assume I have a route like this in my route screen:

CZBB CYXX CYCW CYPK CZBB

the route system currently assumes that I have visited all airports. It would be great if I could indicate that I only really landed/touched down on CZBB and CYCW but only used CYXX and CYPK as waypoints overflying them. This would also allow me to use water airdromes as waypoints (if they are close/along my route) without getting warning in the flight checker that I landed on a Water airdrome (even though now we can already hide them from the verification page thanks to the new feature).

My suggestion would be for example:

CZBB +CYXX CYCW +CYPK CZBB OR CZBB @CYXX CYCW @CYPK CZBB

to indicate that CYXX and CYPK are just waypoints but I did not land there.

Areas that (based on my knowledge) would be touched are:

• The route view of an individual flight
• The Flight Checker
• The Visited Airports page

[ericberman]

I think that would only affect the visited airports page (and maybe the flight checker). You'd absolutely want to map it if you used it as a waypoint, no?

Anyhow, @xxxx already works. Try exactly that. The "@" prefix tells me to explicitly look for a non-airport (navaid), so it's ignored for things like visited airports and flight checker. As for route, it will also suppress them from the route view (unless there is a corresponding navaid); probably OK if the point is to specify that you went from A to B. And if you attach your telemetry, you can see what you overflew...

[fkrauthan]

Sorry yes I want it to show up on the route as a waypoint but not on the bottom of the map where it lists all the visited airports. Thats what I was referring to with required change on the route view of an individual flight.

My @ suggestion was more in regards of if you expand the logic to not just check for navaids with that name but fallback to airports if there is one matching to draw the route then the @ might work perfectly with the least amount of changes.

Otherwise to ensure that it works for everyone without drawbacks using a new prefix in this case might be the better option?

[ericberman]

Coded up today putting an airport in brackets to exclude from visited airports, but at the moment counts in every other way (gets mapped, gets treated as a destination for ratings progress, "Check flights" probably will make some errors as well), so I'm not sure I like that approach. It's actually kinda tricky because it's not just changing the behavior of visited airports, it affects a lot of places. Would be simpler if A-[B]-C just ignored B, but you want mapping to work for that. So still playing with this.

Note that this isn't a function of the particular syntax (prefix, brackets, whatever). It's that a bunch of places in the code say "here's the route as a string of text, parse it out and tell me the corresponding airports. So they really would need to indicate whether they want to include flyover airports or not in that, and that's where it touches a bunch of code paths and a lot of functionality.

[ericberman]

Ooh, realized there's another more insidious problem: searching for "non-local" flights (i.e., 61.1 basic cross-country). This is done by looking literally at the pattern in the route field of either "A" or "A-A" (with some allowance for an optional K - e.g., "SFO-KSFO" is non-local). I do this without looking up airports because it would slam the database to do so. But "A-[B]-A" is not technically 61.1 basic XC because it doesn't actually land at a 2nd airport. So I'd need to remove [B] before doing that check. (And probably should remove any @B as well).

[ericberman]

Perhaps the right way to do this is to follow the @ model when resolving the airports themselves, and to resolve this to an ad-hoc fix at the airports location rather than to an airport. Could be efficient that way. Still doesn't address the basic-cross-country issue, though, but neither does @###N####W. Gotta dive into the bowels of the code to remember how that works.

[ericberman]

OK, that's what I did. So here's how it works. Only the last line below is changed behavior.

Airport search term	returns
XXX	Airport XXX, IF it's a perfect match.
XXX	Navaid XXX, IF there is no airport/heliport/seaport that is a perfect match
KXXX	XXX (allows for US airports where the "K" prefix is not uniformly followed)
@###N###W	Adhoc fix at the specified latitude/longitude
@ XXX, XXX is a navaid (even if XXX is also an airport)	Navaid XXX
@ XXX, XXX is an airport and is NOT a navaid	Ad-hoc fix at location of airport XXX

So the @CYXX above should do the trick, as long as there's no navaid/airspace fix called "CYXX".

This may be something of a hack, but I like it because it's clean, touches very little code, and doesn't create any new semantics (it simply extends the existing "@" prefix semantics to go beyond just navaids.)

[ericberman]

This is not yet live on the website, but will be in the next few days.

[fkrauthan]

Nice thank you so much once again for the quick turnaround time. Can't wait to try it out. Btw just to verify it is going to be @ directly followed by the airport code (e.g. @CYXX) and not with a space between the @ and the airport identifier like the two last entries in the table above?

[ericberman]

Correct. The space in the table above was so that I wasn't referencing an actual github user named "xxx"

[fkrauthan]

You could try adding <!-- --> in between the @ as that should not mention someone but in the browser it should be displayed as expected just in case someone stumbles on this ticket and tries it with a space and wonders why its not working.