Air Traffic Controller Discussion With a Global Perspective
By Andrew Morkunas 1017951
#533423 @Ross

In my experience as a 'virtual' pilot and controller (I have no real world experience in these areas) weather in the simulated environment is not universally applied. Pilots have been known to turn weather settings off, generate their own, fly in the daytime when it is night etc. Unless the pilot tells the controller we do not know what he is experiencing. The norm has to be real world weather, we do that now. It is worth mentioning, I am sure we all have accommodated that VFR pattern request at a Class B airfield during IMC conditions.

In my situation this past weekend I was working a center position when I received a hand off from a neighboring ARTCC. I checked the flight plan and noticed that the filed STAR is normally used for arrivals coming from the west. This aircraft was coming from the east. I informed the pilot of his potential error. He informed me that he filed this route for weather deviation. His weather cleared and I was able to assign a proper STAR from his current position. The pilot was less than pleased in the way I handled his request.

SkyVector does provide some valuable tools for the controller. I use it for route validation. The discussion here is the application of the SIGMETS and weather overlays in our controlling sessions. If I had plotted his route as filed and used the appropriate weather overlay I could have easily seen why he was flying the route he filed. I do not think that we expect this level of proficiency from the average VATSIM pilot.
By Dhruv Kalra 878508
#533428 Having spent almost a year on the floor at a Center, now, I have to say that even being able to just call precip off the NEXRAD feed directly on a scope would be nice. I can eyeball off SkyVector all day, but even r/w weather advisories are a VERY inexact science. We’ll often find ourselves calling depicted precip that is nowhere to be found. Conversely, pilots will often request deviations around buildups with no embedded precip, which we therefore don’t depict on radar.

Giving us the tools to at least issue the advisories would be worth it IMO. At the end of the day, it’s the pilots’ prerogative whether or not they want to deviate.
By Ryan Geckler 1104849
#533445
Richard Gerrish 1029296 wrote:And the hardware and tech have to be there, if the RW can't depict it accurately as Dhruv is saying, then virtually it's neigh on impossible


... to be 100% accurate, and you are correct. Aircraft radar can see what's in front of them more accurately than what a controller's radar sees, but controllers can see behind the cell and provide better information to the pilot.

I don't think from a technical standpoint it's impossible - you would basically set a dbz level to correspond to moderate, heavy, and extreme precip returns and then depict then on the scope.
By Nick Warren 813047
#533449 I'm not a real world controller, so I definitely appreciate the insight from those on here. Recently I was on a SWA flight returning home. My home field has parallel north/south runways. Arrivals that day were south. Flow dictates that aircraft ariving from the south will fly west of the field for right traffic per say and land south. On this particular day, there were thunderstorms in the area. Being a RL pilot in the area, I know what I am seeing out the window quite well so I was intrigued to see us flying well east of the field. The cause of this was a heavy cell sitting just west of the field which precluded standard flow. I suspect that while this would have been on the pilots radar, that the flow was altered because of what ATC saw on their scope. It provided the situational awareness and big picture to give a safe deviation. I certainly see value in providing this capability on the network.
By Ross Carlson 887155
#533453
Nick Warren 813047 wrote:I'm not a real world controller, so I definitely appreciate the insight from those on here. Recently I was on a SWA flight returning home. My home field has parallel north/south runways. Arrivals that day were south. Flow dictates that aircraft ariving from the south will fly west of the field for right traffic per say and land south. On this particular day, there were thunderstorms in the area. Being a RL pilot in the area, I know what I am seeing out the window quite well so I was intrigued to see us flying well east of the field. The cause of this was a heavy cell sitting just west of the field which precluded standard flow. I suspect that while this would have been on the pilots radar, that the flow was altered because of what ATC saw on their scope. It provided the situational awareness and big picture to give a safe deviation. I certainly see value in providing this capability on the network.


The big problem with this is that we cannot control where storm cells are physically located in the pilot clients, with any reasonable level of consistency. So in your example (which is a great example for why it would be awesome to have consistent storm cell placement on VATSIM) you could end up with half the pilots with the storm cell west of the field, and the other half with the storm cell east of the field.

This is why I have yet to add weather radar depiction in my ATC clients. At the end of the day, it would amount to little more than eye candy for the controller, and a little bit of ear candy for pilots when the controller gives weather advisories over the air. I see it as very similar to when pilots give ride reports, wind shear reports, cloud base reports, and other PIREPs to the controller, and the controller reads them to the next aircraft ... there's a very good chance that the next aircraft won't experience similar conditions, so it's little more than ear candy. The big difference between the PIREPs and adding weather depiction to the ATC clients is that PIREPs come at zero development cost. :)
By Nick Warren 813047
#533454 And you, as the author, have the final discretion on inclusion of weather into the clients. I understand your point of view, but also understand the other points of view in favor of. My example was quite localized to the terminal if not the local environment. As one gets more into the latter terminal and enroute environments, I believe whatever ambiguity between clients becomes more acceptable. I have, and continue to appreciate your willingness to be open minded on this topic. Through a good discussion and many convincing arguements, it still doesn't appear we are there yet in your view. That is to say, that not being a developer, I have no idea how much squeezing goes into it, but it doesn't sound like the glass of juice at the end is worth it from a developer standpoint.
By Ross Carlson 887155
#533459
Nick Warren 813047 wrote:My example was quite localized to the terminal if not the local environment. As one gets more into the latter terminal and enroute environments, I believe whatever ambiguity between clients becomes more acceptable.


I agree ... our sensitivity to errors/variance in storm cell placement definitely increases the closer you get to the airport. Up in the flight levels, it doesn't matter as much. Even if two aircraft on the same route request weather deviations in different directions (one deviates left, one deviates right) it wouldn't normally cause a big problem for the controller. (Not so in the terminal environment as in your example.)

For that reason, if I ever do find the time to add the eye candy, it'll probably only be in vERAM. :D
By Simon Kelsey 810049
#533461 I agree that the issue is the lack of consistency in depiction on the pilot side.

My suggestion would be that one way of achieving something that may stand a fighting chance of matching up would be to utilise the Activesky weather radar API for the precipitation data. This would at least be using the same information as pilots are having injected and should be pretty consistent with what pilots are seeing on their own radars (as the vast majority of FS weather radar implementations also use Activesky).
By Ross Carlson 887155
#533470
Simon Kelsey 810049 wrote:My suggestion would be that one way of achieving something that may stand a fighting chance of matching up would be to utilise the Activesky weather radar API for the precipitation data. This would at least be using the same information as pilots are having injected and should be pretty consistent with what pilots are seeing on their own radars (as the vast majority of FS weather radar implementations also use Activesky).


Are you talking about the API provided by the activesky app on the pilot's computer, or is there an open public API that we could make use of in controller clients? I only know of the former.
By Simon Kelsey 810049
#533472
Ross Carlson 887155 wrote:Are you talking about the API provided by the activesky app on the pilot's computer, or is there an open public API that we could make use of in controller clients? I only know of the former.


The API provided by the Activesky app; the downside would be that controllers wanting to use it would need Activesky (but are there lots of controllers who don't also fly?). As I say though, it would make the most sense in that pretty much all of the pilots with functional WXR will be using it.

Unless of course HiFi could be persuaded to provide some sort of feed for this purpose which would make it universal from an ATC point of view.
By Ross Carlson 887155
#533473
Simon Kelsey 810049 wrote:The API provided by the Activesky app; the downside would be that controllers wanting to use it would need Activesky (but are there lots of controllers who don't also fly?).


Every controller would need to be running a flight simulator and active sky ... I don't see that happening. Also, doesn't the API only provide weather data around the local area where the pilot is flying? If that's correct, in this case, the "pilot" would be the controller, so you would only get weather local to the airport where the controller parked his plane during his controlling session. (And it still wouldn't match what other pilots are seeing, even if they are also running active sky.) I certainly give you points for creative thinking, but it seems to me that this would be a step in the wrong direction.
By Simon Kelsey 810049
#533475 Hi Ross,

No, you misunderstand - you can run Activesky without a flight sim running so it would just be controller client + Activesky (which as I say I would imagine a large proportion of controllers would probably own anyway).

AS downloads the entire globe's weather as far as I know and exposes the radar data specifically (so it should be pretty much ready to go with little interpretation required) on a TCP port I think (though I'm starting to get a bit hazy - I'll have a look for some documentation tomorrow).