Request: Optional Frequency for each sector

[Phil061995]

Hey there,

would it be possible (maybe with the new data format) to add an option to specify an optional frequency for each individual sector? That may help to identify a specific sector even if he is not logged in with the correct callsign (e.g. after shift change).

Example:
Sector Kitzingen (EDGG_K_CTR) is one of the main sectors and is doing just a specific area with the FIR. After several hours a new controller will continue to control this sector and will log in as EDGG_1_CTR, as the other login is already used. As this login is not definied, the entire FIR will be displayed as online (what is not the case, other main sectors are still offline).

If the freq is definied for a sector as well, tools that are using these datas may look at the prim freq and the FIR (in this case EDGG) to display the correct center. In the example above EDGG_1_CTR would be displayed exactly the same as EDGG_K_CTR, because they have the same freq and FIR. Maybe this could help to improve the accuracy that is helpfull especially within european airspace with several sectors available on a daily basis.

[Adrian2k]

It has been discussed internally before and the concern has been that having a database with frequencies as well will require a lot of "maintenance" to keep up to date across the whole world. In VATSpy this would not (at least currently) have a difference as it does not display a separate sector regardless. Since VATSIM now allows up to 12 letter logons, could also logon as EDGG_K__CTR as the relief, which would (for the VATSpy users) make it more obvious what sector you cover.

[dneuge]

Does EuroScope handle that situation correctly or is it just a generally confusing scenario? Semantically EDGG_1_CTR is a replacement for EDGG_CTR and not some other EDGG_?_CTR station but I assume a more logical EDGG_K_1_CTR or EDGG_K1_CTR callsign would be invalid by policies and break most tool support? I would expect that the semantic confusion between EDGG_K_CTR and EDGG_1_CTR leads to issues in many more tools including those used on ATC side. Identification via frequencies would probably also have some practical issues, such as misidentification of "observers" listening in on another one's frequency or just helping another controller out for a very short period (I had both those cases often while controlling two years ago).

Using just the "primary frequency" may have yet another problem. Note that I am just a simple user, not staff and not involved in any direct technical discussions or decisions, so please correct me if anything changed from what I last heard as a simple user regarding that topic: AFAIK the meaning of primary frequencies was supposed to be "removed" at some point after Audio for VATSIM had been introduced? Although we currently still have them (at least presented on v3 JSON status files) that semantic, AFAIR, was supposed to be deprecated and all frequencies of a client should be treated equally? I think opening up the detailed AFV status information on the API was part of that effort and we only have the "primary" frequencies shown in data files for legacy applications (although that seems like weird legacy data to carry around as data files were switched to a new format anyway)?

[Adrian2k]

Euroscope only looks for the ICAO + Type + Frequency (EDGG + CTR + Frequency) to determine what sector you cover.

[NelisV]

It's an interesting topic, you could run your mapping application on transceiver-data.json, instead of the normal vatsim-data.json. Would make the mapping on the European side a lot more realistic. How is this determined with the US ATC clients?