(not quite a) Feature request

[Javier Larroulet]

Hi Ross,

First and foremost: Thanks for the much appreciated VAT-Spy update! 

There's something I'd like to pitch to you.

Browsing the old VATSpy forums on your site, I found that VATSpy parses callsigns and identify facilities as "everything up to the first underscore" and the facility type as "everything after the last underscore" (so for example SCEZ_N_CTR is parsed as a Center covering the SCEZ FIR)

There's a new overland special center (similar to Eurocontrol) in South America (south america control... https://fss.vatsa.net/ ), whose UIR sectors are called SAM_S_FSS, SAM_W_FSS, SAM_N_FSS and SAM_E_FSS.

When I tried to put these in the [UIR] section of the vatspy.dat file, I noticed that online controllers manning this facilities are not recognized or shown on the map because even if I enter them as SAM_S/SAM_W/SAM_N/SAM_E, Vatspy would only read until SAM (because of the "until the first underscore" parsing rule).

I made some more tests and if I connect as SAM-S_FSS (hyphen instead of the first underscore) and make the appropriate changes in the .dat file everything works, but since the facility is configured as SAM_S in the AFV database, by doing that the controller is unable to use the special HF frequencies that are on AFV.

Is is possible to consider allowing VATSpy to detect SAM_S_FSS, SAM_E_FSS, SAM_W_FSS and SAM_N_FSS if correctly entered in the .dat file, regardless of the first underscore? or the only solution would be that VATSA changes the callsigns to SAM-S, SAM-E, SAM-W and SAM-N and reconfigure AFV?

Best regards, and again, thank you!

[Ross Carlson]

1 hour ago, Javier Larroulet said:

There's something I'd like to pitch to you.

I can assure you you're not alone in this request. In fact, this was requested back when I first wrote VAT-Spy over a decade ago, and it has been suggested occasionally in the intervening years, including a couple times recently due to this update.

The main reason why it wasn't done back then is that the "middle" section of the callsign is very often used in somewhat unpredictable ways. Sometimes users put an S there to indicate a student controller. Or they put an I to indicate an instructor. Or an M to indicate a mentor. And then during shift changes, they will add a numeric suffix, like BOS_1_CTR, or SAM_N1_FSS, to use your example.

I'm all for making this change, but we have to be careful to take into consideration the fact that the middle portion of the callsign is not standardized across all of VATSIM.

What does South America Control do when there's a shift change? What does the incoming controller use for a callsign? And how does AFV handle it?

[Javier Larroulet]

Hi Ross,

Thanks for the quick reply. I totally understand the difficulties and the plethora of edge cases that can arise from this and the fact that the middle part is not standardized. Didn't know it had been pitched before.

Sadly I don't have the answer to your questions (I'm just a visiting controller for South America Control, but I don't have any insight on the AFV part other than my own trial-and-error when I was trying to get these sectors to be displayed in VATSpy). Since the whole FSS is new, I still haven't encountered a case when there's a shift change, but apparently (from my trials) it seems that AFV is set up for the exact callsign only (SAM_S_FSS, SAM_W_FSS, SAM_N_FSS, SAM_E_FSS) so I couldn't say if during a shift change a second controller logging in as say SAM_S2_FSS would be able to get AFV to work. It would be great to have the facility engineer's insight here.

I'll see if I can get a hold of the facility engineer and point him to this thread so he can give us a little bit more depth on how this is set up.

Thanks again for replying!

[Ross Carlson]

Sounds good, definitely let me know about the shift change question.

One thing I've considered in the past is to do away with the underscore parsing altogether, and instead use pattern matching. So instead of listing the prefix and suffix in the VAT-Spy data files, you would put in something like SAM_N#_FSS. The # represents an optional digit. So that pattern would match either SAM_N_FSS or SAM_N1_FSS or SAM_N2_FSS, etc.

Where that doesn't work so well is with places that don't use the middle character for anything but shift change, such as BOS_CTR. The pattern BOS_#_CTR would not matching BOS_CTR ... it would only match something like BOS_1_CTR. One way to deal with that might be to enclose optional characters in parentheses, such as BOS_(#_)CTR. However, that pattern wouldn't handle the student/instructor/mentor variations like BOS_S_CTR.

And I just remembered that a lot of places in the US use numeric sector numbers when they split an ARTCC into multiple sectors, such as ABC_47_CTR. (Just making that one up.)

Another method I've considered is to just have the FE list all the possible variants, like BOS_CTR, BOS_1_CTR, BOS_S_CTR, BOS_I_CTR, BOS_M_CTR. Those would cover the most common cases where a single controller is covering the entire Boston ARTCC. For when the ARTCC is split into multiple sectors, there would be other entries in the file like BOS_NW_CTR (for a northwest sector), or BOS_SL_CTR (for a south low sector), etc. I haven't thought that one through, but it might work.

[Mateusz Zymla]

Ross, 

Thanks for pointing out this topic in original post.

According to Europe: Most of the time _T_ is an trainee, and mentor/examiner is usually _M_/_X_. Second examiner would be _Y_ or _Z_. Regarding shift change: Most of the time we just do _1_, _2_, and so on.

In my mind I have few ways that we could solve it out:

1) "Use default as long as I don't see a specified one" method - So, let's say, EPWW_CTR and all the variants covers EPWW in general (because I have two "FIR" definitions overlying - general EPWW and specified, EPWW-S, EPWW-N, EPWW-W, just to give an example). EPWW_CTR, EPWW_A_CTR, EPWW_1_CTR and so on would light up entire FIR, but only if specified are "found" (like EPWW_S_CTR, EPWW_N_CTR, EPWW_W_CTR) - this would light up only a certain one. Yes, I know we lose it in situation where "_1_" logs in, but that is not a common thing - only during the events. With automatically pushable updates to the sector, and a bunch of community working on the updates on Git, that would be a VACC/Community responsible, to define these sectors. Everything remains "by default" the same, as long as the specified "subsectors" are not defined and then identified by VATSpy,

2) Use EuroScope way - identifing sectors with combination of the station code (EPWW_ ... _CTR, whatever is in between) with a Primary frequency. This would require to add all the frequencies. to the definitions, then. Or - to have a safe "fallback" and backward compability - unidentified freq (not set in "new" .dat file) automatically lights up entire FIR, only specified found - lights up only the particular part. Again - VACC/Community responsible to fill it in.

[Trevor Hannant]

Thinking way outside of the box here Ross but could there be some recognition of the frequencies which may help with the sector being covered?

[Trevor Hannant]

4 minutes ago, Mateusz Zymla said:

Regarding shift change: Most of the time we just do _1_, _2_, and so on.

 

There are also occasions where a double underscore is used, i.e. LON_N_CTR handed over to LON_N__CTR

[Mateusz Zymla]

Just now, Trevor Hannant said:

There are also occasions where a double underscore is used, i.e. LON_N_CTR handed over to LON_N__CTR

That is true, and sometimes "losing" a middle char is also used (LON_N_CTR -> LON_CTR), because EuroScope in our example would recognize the sector by frequency anyways. And that is what you and me (in 2nd point) proposed.

[Ross Carlson]

This just goes to show how non-standardized callsigns are on VATSIM. The more I think about it, the more I think the data file would simply have to list all the possible callsigns that apply to a given boundary definition.

Perhaps this list, along with frequencies, could be used as the official document that would drive not only maps like VAT-Spy, but also AFV.

[Mateusz Zymla]

Well, VATEUD is already (trying to) handle all the frequencies.

https://fsmine.dhis.org/vateud8/

It would be nice to motivate other regions to do the same and/or unite in it.

Your point is right. In this matter (as in many others) centralisation - as a data center - while updated by the locals, would be benefical.

Edited November 20, 2020 at 05:19 PM by Mateusz Zymla

[Logan Waldman]

Would it be possible to light up a sub sector if it is known, otherwise just show the entire sector?

So as an example, NY_CTR connects, and shows all of ZNY. NY_W_CTR connects, and shows as covering just the west side. then NY_W1_CTR connects, but because you don't recognize it, it shows up over all of ZNY. I think that could work, even though it won't always be totally accurate, it should always be at least somewhat accurate

[Ross Carlson]

1 hour ago, Logan Waldman said:

Would it be possible to light up a sub sector if it is known, otherwise just show the entire sector?

So as an example, NY_CTR connects, and shows all of ZNY. NY_W_CTR connects, and shows as covering just the west side. then NY_W1_CTR connects, but because you don't recognize it, it shows up over all of ZNY. I think that could work, even though it won't always be totally accurate, it should always be at least somewhat accurate

I think it would be better to encourage the ZNY FE to add NY_W1_CTR to the list of known callsigns for the western sector. Because it gives the wrong impression to the VAT-Spy user if they see NY_W1_CTR covering the entire ARTCC when in fact their area of responsibility is smaller.

[Logan Waldman]

27 minutes ago, Ross Carlson said:

I think it would be better to encourage the ZNY FE to add NY_W1_CTR to the list of known callsigns for the western sector. Because it gives the wrong impression to the VAT-Spy user if they see NY_W1_CTR covering the entire ARTCC when in fact their area of responsibility is smaller.

Okay, that's fair. I was thinking to do what I said as a fall back, but if you are going down that route, you are right, might as well just add every possible callsign. My thinking was that it is most important to show that a given area is covered, and the second priority would be to show which sub-sector is being covered in particular. Because I figure regardless of what you plan for, someone is probably going to connect as an unrecognised sub sector. But I agree that what you said would probably be a better idea in the long run

[Ross Carlson]

42 minutes ago, Logan Waldman said:

Okay, that's fair. I was thinking to do what I said as a fall back, but if you are going down that route, you are right, might as well just add every possible callsign.

There is a downside to the approach I'm suggesting. It means that if a facility is planning to use a new split configuration (with new callsigns) for an upcoming event, then they have to get the new callsigns into the VAT-Spy data files prior to the event. They would have to know for sure what the callsigns would be ahead of time, and they wouldn't be able to come up with callsigns at the last minute to accommodate an unforeseeable change in the configuration. I'm not sure how often that would happen, but it's worth considering.

Which is the lesser of two evils? Showing nothing at all, or showing whole airspace covered even when the actual coverage is much smaller?

This brings up another potential problem with sector-specific callsigns. It's fairly common near the end of an event for one sector to log off and the other sector to stay online and assume the airspace of the controller that just signed off. Now the map is only showing the one controller's sector as covered, even though their actual coverage is much larger.

One way to deal with that would be to handle it the same way it is handled in some real facilities. There is a sector consolidation plan that dictates which position has responsibility for a given sector when that sector is not staffed directly. This could get very complicated for facilities to maintain. And sometimes the consolidation rules would need to be different for different configurations, like for different types of events with different traffic flows.

[Niels Voogd]

Hey Ross as posted in the other thread, i think the majority of these issues can be dealt with by keeping your current system in place, but before applying the current logic, see if there is an exact match up to the second dash in the vatspy data.

Example, someone logs in as EDGG_X_CTR:
not found in the vatspy data, light up EDGG as is done now.

someone logs in as BOS_1_CTR:
not found in the vatspy data, light up BOS as is done now.

Someone logs in as EDGG_P_CTR:
found in the vatspy data, that specific sector is shown.

or the student mentor example, same thing applies:
logged in as BOS_S_CTR:
specific suffix not found, entire BOS is shown online.

That way you don't run into issues with the numbers or specific suffixes added after that and we're still able to light up individual sub sectors.
and even if the guys from the US would include the subsectors in the vatspy data using the 1,2,3 suffixes, it would still apply since it would find an exact match for those in the vatspy data.

 

 

[Ross Carlson]

Right, Niels, that's one of the two evils I mentioned above. If there's no specific match, you either show the whole airspace lit up even though the actual airspace is much smaller, or you show nothing at all. Both outcomes somewhat defeat the purpose of sector-specific data.

I generally don't like to add a feature unless it can be done right. I don't like to add half-baked features. I.e. features that only work some of the time.

And then there's still the issue of consolidation that I mentioned above. I'm not sure how to deal with that, and that scenario is pretty common at the end of an event.

[Niels Voogd]

2 hours ago, Ross Carlson said:

you either show the whole airspace lit up even though the actual airspace is much smaller, or you show nothing at all. Both outcomes somewhat defeat the purpose of sector-specific data.

Nice incentive for the FIR's to add their subsectors to the Vatspy data right 🙂.
But joking aside, it would already improve the situation for the folks that have added their subsectors to the data, and for those who haven't yet, there's no change vs what Vatspy does now.

Edited November 21, 2020 at 06:48 PM by Niels Voogd

[Ross Carlson]

3 minutes ago, Niels Voogd said:

But joking aside, it would already improve the situation for the folks that have added their subsectors to the data, and for those who haven't yet, there's no change vs what Vatspy does now.

Yeah, I think for the most part it would be the lesser of two evils to fall back to the current behavior. But there's still the issue of consolidation. That issue still means this would be a half-baked feature.

[Trevor Hannant]

On 11/20/2020 at 4:56 PM, Ross Carlson said:

This just goes to show how non-standardized callsigns are on VATSIM. The more I think about it, the more I think the data file would simply have to list all the possible callsigns that apply to a given boundary definition.

Perhaps this list, along with frequencies, could be used as the official document that would drive not only maps like VAT-Spy, but also AFV.

Could there be a "central" way that Regions/Divisions can update the sector names and/or frequencies and VAT-Spy will read that rather than the local file?   Of course, this would only work if they matched the FIR boundaries list...

[Niels Voogd]

The consolidated sectors can be, and already are in some cases, defined in the firboundaries. EDGG in the case EDGG_P and EDGG_E are combined, or LFEE when _S and _N are combined, all as separate sectors. OBBB is another good example. Further splits are used on vatsim, but the vacc's here compromised to show the 2 splits most used by their controllers and most important to know for a pilot. Really digging in to the specific sector ownership under all different possible scenarios would of course be awesome, but i think impossible without having some sort of API for it on the vatsim side, which on itself would require a central way of dealing with sector files. If you go that direction there's also the topic of split sectors based on altitude.

There's no way of making it perfect with the data that is available now, but adding processing for what is already in the firboundaries would be an improvement.

 

Edited November 21, 2020 at 07:50 PM by Niels Voogd

[Adrian Bjerke]

As someone mentioned an alternative solution would be making it look for ICAO + frequencies, like how Euroscope does? And if that does not match then it revert to displaying the whole FIR. In my opinion if we only had the option to not display or display it all when no data is matching I would prefer the whole airspace to be light up.

[Ross Carlson]

1 hour ago, Niels Voogd said:

The consolidated sectors can be, and already are in some cases, defined in the firboundaries. EDGG in the case EDGG_P and EDGG_E are combined, or LFEE when _S and _N are combined, all as separate sectors. OBBB is another good example. Further splits are used on vatsim, but the vacc's here compromised to show the 2 splits most used by their controllers and most important to know for a pilot. Really digging in to the specific sector ownership under all different possible scenarios would of course be awesome, but i think impossible without having some sort of API for it on the vatsim side, which on itself would require a central way of dealing with sector files. If you go that direction there's also the topic of split sectors based on altitude.

There's no way of making it perfect with the data that is available now, but adding processing for what is already in the firboundaries would be an improvement.

 

How does that address the consolidation issue I raised above? For example, if Boston Center is currently online and split between north and south, with callsigns BOS_N_CTR and BOS_S_CTR, and then north logs off and south assumes the entire ARTCC, how would mapping programs like VAT-Spy know that BOS_S_CTR should now be rendered as the entire ARTCC rather than just the southern half?

Edited November 21, 2020 at 09:19 PM by Ross Carlson

[Logan Waldman]

14 minutes ago, Ross Carlson said:

how would mapping programs like VAT-Spy know that BOS_S_CTR should now be rendered as the entire ARTCC rather than just the southern half?

The easiest solution is probably similar to what Australia does now, in that they don't show consolidated sectors. If one center sector is covering another (as is common practice) they just have a note in the controller info that says what other sectors they are controlling. The obvious downside there is that now you have airspace being controlled, but looks on vatspy like it is uncontrolled.

I suppose that you could highlight adjacent sectors based on the controller info line (eg have a line in BOS_S_CTR's info that states "also covering BOS_N_CTR"), but now we are getting into rather major changes to how vatspy works, as well as whole load of ways that could be broken or exploited.

My last suggestion would be to have a way of defining sector ownership priority, a la Euroscope. So to use your example again, for the southern half of ZBW, BOS_S_CTR would be shown if it's online, otherwise BOS_CTR, and if no one else is online, then BOS_N_CTR would be shown covering both N & S. again, that is a fairly major change, but also probably the most robust in terms of accurately showing who is covering what

[Mateusz Zymla]

Ross, 

 

BOS_W1_CTR has one, extremely major issue - it will work only for 3 letter station codes. In Europe, and many other places, where we use 4 letters, the callsign would be too long - you can't log into EPWW_W1_CTR. 

Regarding frequencies - well, I get your point with overlapping sectors. You'd need to build entire sector ownership system just like the ATC apps does, and that is not effective for the purpose. 

IMHO, the option to leave entire FIR as long as specific sector lights up seems the most reasonable, and least invasive/revolutionary(?) at the same time

[Ross Carlson]

1 hour ago, Logan Waldman said:

The easiest solution is probably similar to what Australia does now, in that they don't show consolidated sectors. If one center sector is covering another (as is common practice) they just have a note in the controller info that says what other sectors they are controlling. The obvious downside there is that now you have airspace being controlled, but looks on vatspy like it is uncontrolled.

That's not a solution to the problem ... that's just ignoring the problem. 

1 hour ago, Logan Waldman said:

I suppose that you could highlight adjacent sectors based on the controller info line (eg have a line in BOS_S_CTR's info that states "also covering BOS_N_CTR"), but now we are getting into rather major changes to how vatspy works, as well as whole load of ways that could be broken or exploited.

This would rely on controllers keeping their controller info up to date as sectors consolidate. I don't think this is a workable solution either.

1 hour ago, Logan Waldman said:

My last suggestion would be to have a way of defining sector ownership priority, a la Euroscope.

This is what I suggested earlier ... make it work like the real world equipment does. The real facilities have a sector consolidation plan that determines which working position "owns" each chunk of airspace, based on which positions are staffed. They also have the ability to manually control the consolidation using keyboard command entries. Here's what I said about it earlier in the thread:

23 hours ago, Ross Carlson said:

One way to deal with that would be to handle it the same way it is handled in some real facilities. There is a sector consolidation plan that dictates which position has responsibility for a given sector when that sector is not staffed directly. This could get very complicated for facilities to maintain. And sometimes the consolidation rules would need to be different for different configurations, like for different types of events with different traffic flows.

 

1 hour ago, Mateusz Zymla said:

BOS_W1_CTR has one, extremely major issue - it will work only for 3 letter station codes. In Europe, and many other places, where we use 4 letters, the callsign would be too long - you can't log into EPWW_W1_CTR. 

I've been developing VATSIM clients for a long time ... I'm aware of the callsign length limitation.  That's a separate issue from what we're discussing here.

 

1 hour ago, Mateusz Zymla said:

IMHO, the option to leave entire FIR as long as specific sector lights up seems the most reasonable, and least invasive/revolutionary(?) at the same time

 

I'm not understanding your suggestion here. Can you rephrase or elaborate?