ATISes and other forms of automated weather and aerodrome information. On VATSIM, it’s also a very good way to inform pilots of any VATSIMisms relevant for the airport. Later last year there was even an update to the Frequency and Information Management policy which made it possible for controllers to connect up to four ATISes instead of just one. However, I wonder if ATISes couldn’t be done better on the network, so I wanted to put out a few thoughts here.
Continuous text ATISes vs abbreviations
While voice ATISes obviously can’t and don’t use many abbreviations, text ATISes IRL are usually heavily abbreviated, particularly in the weather section. Here on VATSIM, however, text ATISes are usually a continuous text due to a limited amount of available abbreviations for the TTS system. This has some drawbacks:
- The ATIS can quickly become very long, especially when information beyond the weather and runways (or even if the weather is simply very poor) is added which can not only make it quite confusing to read but also increases the chance that pilots don’t pay attention to everything in the ATIS and/or inadvertently overlook important information.
- The voice ATIS may not correctly output what’s written in the text, particularly when non-English words, abbreviations unknown by the system, etc. are used. While I would assume that most pilots nowadays don’t even listen to the ATIS and instead just read it, e.g. on SimAware, voice ATISes are still a fundamental part of IRL aviation and there are also many pilots who prefer to listen to the ATIS for realism or convenience purposes - that group is forced to potentially go out of their way to access the text ATIS.
The only way to circumvent this that I’m aware of is to use vATIS which uses its own TTS system and - crucially - separates the text ATIS input from the voice ATIS input. While vATIS certainly isn’t perfect, I think this particular feature is something that should be the norm. If an ATIS set up directly through VATSIM (i.e. from the controller client) would work the same, this could vastly improve the quality of the voice and especially the text ATISes on the network. It would also make it easier to comply with 5.3.2.3 of the policy.
Number of ATISes
As mentioned in the beginning, controllers are currently allowed to connect up to four ATISes. While I’m sure a lot of thought has gone into this number, I fail to see why more ATISes are not possible. Whether one controller is responsible for two sectors and hosts eight ATISes or those two sectors are split between two controllers and either one puts up four ATISes would have the same effect, wouldn’t it?
I think the interesting thing to look at would be the maximum amount of ATIses needed at the same time by a singular controller. What station that a singular controller would be allowed to open has the most ATISes and what is that number? Seeing as - the way I understand it - ATIS connections are only allowed for simulating actual ATISes and not things like ASOS or AWOS, I would imagine that number to be rather low or at least that there are very few outliers that would need a very high amount of ATISes for full coverage.
Making a full or near-full ATIS coverage possible would reduce the time spent on frequency relaying weather information, runway in use, expected approach, etc., particularly on bigger, bandboxed positions where frequency time is at a premium anyway, and increase the service level at smaller, secondary airports.
Information in VATSIM ATISes
vACCs usually try to make their ATISes as close to real life as possible. However, the policy prohibits inclusion of any information that is not relevant on VATSIM - nevertheless, I often see such information, e.g. danger of bird strike, reference to call a flight service station that is not actually staffed, etc., but what I don’t see very often is information on various VATSIMisms. Some places include the current airborne frequency at airports with auto-handoffs, but many don’t or only do so under certain circumstances. I also rarely see information on which controller to contact for topdown coverage (sure, one can often correctly assume that the controller hosting the ATIS is also the one providing coverage, but we also often see underlying controllers come online or splits happening while the ATIS remains with the controller who had it originally) even though it would be a great help to pilots in figuring out which controller is responsible for them. There are many more little pieces of information that could be beneficial to host in a VATSIM ATIS: short links to available pilot briefing material, information that pilots are expected to communicate to ATC, if local language service is currently not available, etc. Even if information is technically already in the charts, many pilots seem to struggle with a lot of it and the ATIS can be a great way to still communicate the most important pieces of information.
Multilingual ATISes and non-standard ATISes
Many places that use local languages on top of English for aviation communications have ATISes in both the local language and English. In my opinion, offering local language use wherever possible and realistic is a great way to include people who are not that good with English in the VATSIM community. Particularly when there are ATISes for both English and the local language, I think it would be amazing if VATSIM made it possible/easier for these vACCs to set up local language ATISes.
Similarly, there will occasionally be ATISes that don’t communicate normal weather information, cover more than one airport, and/or simply don’t fall within the combined, departure, or arrival category; e.g., I know of examples where there’s an ATIS directly aimed at VFR traffic and/or specifically glider traffic. These often communicate information that in other cases is part of the normal ATIS but has been put in a separate ATIS in these specific cases to avoid cluttering the normal ATIS with lengthy passages that are not relevant to a significant portion of the traffic (in case of the glider ATISes, for example, some airports only have two or three glider sectors in the TMA so making the information part of the normal ATIS doesn’t create too much clutter, but in some cases there is such a large number of glider sectors that it made more sense to authorities to add an additional ATIS just for communicating this specific information - the reasoning is ultimately the same as for making separate departure and arrival ATISes at some airports). Just like with the multilingual ATISes, I think it would greatly add to the network, this time for pilots who prefer flying VFR etc. and it would be a win for everyone if the policy would be expanded to explicitly allow these types of ATISes on the network as well.
Miscellaneous
I also have a few other, shorter thoughts:
- The policy forbids Tower controllers from hosting an ATIS at more than their primary airport. However, in the rare situation that a Tower controller is indeed responsible for more than one airport and the secondary airport has an ATIS IRL, it would be particularly helpful for pilots if the Tower controller could put up an ATIS at this airport as well as it would clearly communicate that the airport is covered (otherwise, pilots will always assume that a controller only logged on as _TWR is not responsible for more than the airport whose ICAO code is in their login). It may be worth rethinking this point to allow all controllers to set up ATISes for multiple airports - after all, the rule that controllers can’t set up ATISes for an airport they don’t cover still applies.
- The policy also forbids Ground and Delivery controllers from setting active runways and approach types with the ATIS. Not only is it relatively hard to remove that information from all ATIS setups that I’m familiar with, it also completely disregards the fact that in many places around the world, SIDs are runway-specific, so a sole Delivery controller would still have to decide on an active runway, and since a Ground controller has to give taxi instructions towards an active runway (and is also responsible for traffic taxiing on currently inactive runways in many places), they have to decide on an active runway even when SIDs are not runway specific. Having this information in the ATIS makes life easier for everyone.
Alternatively, training policies could be changed to remove the cut between GND and TWR, but that’s a topic for another time. - 5.3.1.2 states that the ATISes have to be set up for the primary airports, but in the exceptions, it says that “any other reason the ATCS determines” allows for a deviation from this policy. This essentially makes the entirety of 5.3.1.2 before this point irrelevant. Don’t get me wrong, I think this level of flexibility is great, but it nevertheless makes no sense to make a rule on how controllers have to decide which airports get an ATIS only to then basically say “do what you want”.