[FEAT REQ.] - Drop trailing F from fix-drawing aliases

[erikquinn]

Related: #20 (original implementation)

Describe the solution you'd like I know the effort to clearly differentiate between chart-link-opening (.******C) and fix-drawing (.******F) aliases by using the -C and -F extensions was a conscious one, but I'd like to open a discussion about trading away the verbosity in exchange for shorter aliases.

From my perspective, the far more common use case is to draw the fixes on the scope, compared to opening the chart. I propose removing the -F aliases, and replacing with the formatting below:

.MIAHILEY .FF FIXXA FIXXB FIXXC...
.MIAHILEYC .OPENURL http://link.to.chart/for/hileyArrival

Describe alternatives you've considered

• Instead of using the extensionless aliases for fix drawing, they could be used to bring up the chart, but given the commonality of bringing up the fixes compared to bringing up the chart,
• Take no action, and leave the -F and -C suffixes.
• Support both the nondiscrete and verbose options, by mapping the extensionless aliases to the verbose ones, ie adding .MIAHILEY .MIAHILEYF.
• If no changes were adopted, this could be post-processed at the facility level to replace -F with extensionless, as my facility would absolutely do (and I expect others would do the same). I would much rather avoid the need for downstream re-modifications for the sake of consistency and ease of use of the NASR2SCT output data, by simply handling it with the tool.

[KSanders7070]

The F suffix comes from the distinction of our local facility having a command that draws the lines diagram for the procedure, for example:

.TPADADES

Would draw the DADES6 departure out of TPA lines on the scope.

This isn’t used much anymore so now we kept the F because of the long time standing of the syntax and keeping a “standard” if you will, with having the distinction there.

I also want to keep the base (no suffix syntax) open to possible future developments or bringing back the line-draw feature that automatically sets that up for the facility.

I recognize that I may have a bias view on it, I am open to further discussion on it.

[Nikolai558]

I like your thinking however I do agree with @KSanders7070 on this matter. I am open for discussion on it as well. Here is perhaps a solution that could work and would be relatively "easy" to implement.

I could include a "settings" option. Think of this as like a checkbox (when checked, it would include the "F"; unchecked, it wouldn't include the "F"). However, I feel like I would need more "setting options" in order to feel like this is worth doing. It could be done. I am open to other Ideas as well.

I don't think I want a lot of "customizable" settings in this tool because it is made with the idea that most, if not all, ARTCC's will be using the same "standard." I do realize every ARTCC is going to have custom data and custom alias files for their own needs, but with the data provided from the FAA there are a lot of variables that should be kept to a standard format. That is what this tool has achieved, for the most part.

[Raajheer1]

What if you had it so the general command did both?

.LAWGRF - Pulls up the Fixed .LAWGRC - Opens the Chart .LAWGR - Does both( .LAWGR .LAWGRF .LAWGRC <- how it would look in the alias)

That way if the controller is completely unfamiliar they can quickly get access to both.

[KSanders7070]

I've tried that. Combining certain aliases that use arguments after it don't work with the software.

[MacMinnS]

I generally prefer the -C and -F syntax as it is clear and obvious what you are aiming to do. Ultimately both do it in a similar fashion so the main concern about removing the affix -F is in the future if we need to add additional commands, not everything follows the same syntax.

This falls back to the use of the facility specific ISR. We have changed the ISR to follow the same formatting, so we have .seasummadel so having .seasummaf and .seasummac makes sense. Removing the f may add confusion as it breaks the clear formatting structure.

[KSanders7070]

Skylar put it better than I.

To be honest, when we use to have the base command without a suffix to draw the lines, I didn’t like it. I felt like it violated the continuity.

We will keep this open to allow further discussion, though.

Erik, thanks for your feedback!

[erikquinn]

The F suffix comes from the distinction of our local facility having a command that draws the lines diagram for the procedure, for example:

.TPADADES

Would draw the DADES6 departure out of TPA lines on the scope.

This isn’t used much anymore so now we kept the F because of the long time standing of the syntax and keeping a “standard” if you will, with having the distinction there.

Okay, that explains where it comes from. Personally, I would show the fixes rather than drawing a line which has no labels, so from my perspective drawing the fixes alone solves both needs in one.

I could include a "settings" option. Think of this as like a checkbox (when checked, it would include the "F"; unchecked, it wouldn't include the "F"). However, I feel like I would need more "setting options" in order to feel like this is worth doing. It could be done. I am open to other Ideas as well.

Sure, that could be a good solution, and going with a simple config file that you'd read in (rather than building out more UI) could be a more straightforward way to support it, for those who want the output to be shaped differently from your standard.

I don't think I want a lot of "customizable" settings in this tool because it is made with the idea that most, if not all, ARTCC's will be using the same "standard." I do realize every ARTCC is going to have custom data and custom alias files for their own needs, but with the data provided from the FAA there are a lot of variables that should be kept to a standard format. That is what this tool has achieved, for the most part.

Yep, agreed 100%. 😃 In fact, the reason I opened this issue in the first place was to make a case for changing it-- rather than quietly reconfiguring at the facility level. As much as possible, the format should be consistent throughout the division because... why not. As an new outsider with no preconceived notions, the -F suffixes jumped out the most as being strange to me. And I felt strongly enough that it warranted reconsideration.

.LAWGR - Does both( .LAWGR .LAWGRF .LAWGRC <- how it would look in the alias)

As Kyle mentioned, this wouldn't work, as VRC can only process a single embedded alias command. So the above would execute .LAWGRF and then type out .LAWGRC as text. And it also wouldn't be the desired behavior-- an alternate option listed in the issue description was to do what I think you're suggesting though-- to map the extensionless command to the -F command, like this: .MIAHILEY .MIAHILEYF, making the same result achievable both for those who want to type the extra letter and for those who don't see the advantage.

---

In general as I see it, there are only three things an alias could do with SID/STAR data (for example):

1. Toggle all its fixes
2. Open the chart by url
3. Toggle the map from View --> Diagrams

I get the sense maybe others' use is different, but for me... Probably 95% or more of the usage would be from the first point alone, with almost all of the rest of the use coming from bringing up the full charts. In my day to day, it is very rare that I need a chart, and very common that I want to pull up fixes on an arrival/approach for various reasons. So given that I'm far more interested in toggling fixes than in any of the other stuff, that's the reason I would advocate for giving it the shortest variant. Short of a new ATC Client (which may come), there really is no other behavior that could be added-- and anything to be added later could just take a new suffix letter, as appropriate for its function. But given that I'd be typing .MIAHILEYF potentially hundreds of times before ever doing a .MIAHILEYC, my preference would be toward making the command I use easier to use. Note: Currently we have this mapped to .HILEY7, and moving to .MIAHILEYF would be 50% more keystrokes for the same functionality. A price worth paying, absolutely, but I go all 🤨 at the necessity of specifying "i want fixes!" when it's literally all I ever want ever. 😉 Think of airways too! Charts aren't even available, so the F is doubly redundant in those cases, which are possibly just as common as SID/STAR fix toggling. (.Q77 over .Q77F )

I'd be interested to hear if others really do pull up more charts than we do, or if I actually am somehow in the minority. Because if so, we can definitely handle the transformation at the facility level if we're the weird ones, I'd just really rather not have to add another step to each update. No worries either way though, just wanted to start the discussion really.

[MacMinnS]

The biggest thing that would add confusion is for ZSE and ZLC's ISR or In-Scope-Reference. Currently, we would have these commands: .seasummaf -- draws the fixes on the summa departure .seasummac -- pulls up the charts .seasummadel -- provides an ISR private message with relevant details for the delivery controller. We have variants on this for all arrivals and departures for all of our towered fields and they follow the same syntax. So any Ground or Tower or Departure, Center or Approach would follow the same syntax IE .seasummagnd , seasummatwr, .seasummadep, .seasummactr. https://i.imgur.com/OghBCWJ.png

So keeping the F when everything else has an extension for a reason makes sense from a continuity perspective. You will always know that it is .APT[SID/STAR]F for the fixes and .APT[SID/STAR}C for the chart. And then our Approach procedures are the same .SEAI6LF .SEAI6LC for Seattle ILS 16L fixes and charts.

I understand that not EVERYONE has this and most will not want to do the immense legwork to setup the ISR to begin with, but it matches the syntax and keeps things with a similar logic profile. F for fixes, C for charts, 3-letter for your position (del/gnd/twr/dep/app/ctr) for ISR commands.

[KSanders7070]

Erik,

That is a very well written response and helps us see why you would want that more and I would consider this a valid request.

I myself find myself bringing up the CHARTS more than the fixes lol... Anytime I need some sort of reference, it is usually out in the middle of nowhere that nobody ever flies so I feel better glancing at the chart and getting the idea of how it works and I usually don't need the fixes. Everybody has their own flavor I guess haha...

Unfortunately, as you and Skylar noted, trying to make a standard is more of our goal right now than removing a letter in a syntax to make it easier to type. After a few rounds of controlling, it tends to grown on you as a muscle memory and the SYNTAX seems to be more intuitive with the F at the end... because then you look at the chart recall... and you see that C there and you are like “Well.. ya.. of course it has a C at the end because the Fix command is built the same way.”

Creating some of these commands, I wasn't happy with it and I tried numerous different ways of doing this but what we have done here is built a very inclusive system that works FAA-Wide lol... this was one heck of a project... A successful compromise is one that nobody is completely happy with... the syntax is a compromise and I think it is a good one.

When students first come in and they see the length of some of our commands, they usually a little intimidated until they get the breakdown for it. Then after only a single session, they are able to complete the same command for thousands of different procedures, regardless of the airport or region/ARTCC it belongs too within 2-3 seconds. They then have the “Ah Ha!” moment and they just get it from that point.

We knew that these type of requests would eventually come in and we are thankful for them because we do not assume we have the best way to do something but we do know what our goals are so please keep them coming. If you suggest something that maintains a standard in a more efficient way and takes as many procedures (FAA-Wide) into account as possible, that is when we will most definitely go back to the drawing board but with this particular request, this may be something that is converted at the facility level.

Facility level conversions are obviously completely fine... but if we have a bunch of facilities doing things slightly different to do the same thing, that would somewhat be counterproductive.

But again... completely up to you.

Nik- I would still like to keep this thread open just in case someone has some other trick to get this done the way he is suggesting. At least until VATUSA starts using it.

[erikquinn]

Unfortunately, as you and Skylar noted, trying to make a standard is more of our goal right now than removing a letter in a syntax to make it easier to type. After a few rounds of controlling, it tends to grown on you as a muscle memory and the SYNTAX seems to be more intuitive with the F at the end... because then you look at the chart recall... and you see that C there and you are like “Well.. ya.. of course it has a C at the end because the Fix command is built the same way.”

Sure, my suggestion was based on my usage of almost exclusively fix drawing, with little interest in the rest, which is the reason to propose it being so fix-drawing centric. I would explain to my people as To bring up the fixes for a SID/STAR, specify the airport and procedure name without the number, like ".MIAHEDLY" or ".MIAHILEY", or airways with ".Q77" / ".Y280" / etc. If a chart is available, you can bring it up by adding a C to the end, like ".MIAHEDLYC" or ".MIAHILEYC".

Deeper features like facility specific ISR (.seasummadel) are just not something we would be likely to implement. Our sole interests would be in:

• having easily updatable nav data
• aliases to bring up SID/STAR/IAP/AWY fixes
• aliases to bring up SID/STAR/IAP/APD charts

Given that all we want is fixes and charts (and usually just fixes), saying add a C if you want the chart to me seemed no less of a reasonable how-to for new users. I do still think adding an additional alias to support this behavior has no quantifiable downside, i.e. .SEASUMMA .SEASUMMAF. But regardless, for now we can handle the change at our facility level.

[KSanders7070]

We shall take this under advisement and it might be a future feature with a configuration file. Until then lol... Find: F .FF Replace: .FF

[erikquinn]

Yep! 👍

[KSanders7070]

After a lot of consideration and asking around, this would break continuity that is already established for many who use these files and isn't the direction we want to take. I appreciate the feedback!