Air Traffic Controller Discussion With a Global Perspective
By Nick Warren 813047
#504353 Thank you Ross for your response. I understand and respect your viewpoints as a programmer and maintaining the overall vision of the product. Could it be generally said though, that for the most part a "cell" or a thunderstorm a size requiring some form of routing deviation would generally show up regardless of weather client though? I understand no 2 pilot's clouds are going to show up in the exact same spot and what not, but I would think something sizeable would show up in some form roughly, somewhat, similar between clients. Just like visibility, cloud ceiling, and other general phenomena. Just spitballing here.
By Nick Warren 813047
#504354
Randy Tyndall 1087023 wrote:Josh,

I use Skyvector all the time and get sigmets and the outline of the affected area, but I have yet to see an option to show weather cells like your screenshot shows. What the heck am I missing? PM me please so I don't force this thread too far off track. :D

@Zachary,

Sorry to hijack your thread, even if only momentarily, I apologize.

Randy


Randy,

On SkyVector, Click on Layers, then under Radar and Satellite, Check Weather Radar.
By Ross Carlson 887155
#504355
Nick Warren 813047 wrote:Could it be generally said though, that for the most part a "cell" or a thunderstorm a size requiring some form of routing deviation would generally show up regardless of weather client though?


The only honest answer here is that I don't know ... there are a number of variables here, and the question of whether or not we can achieve something workable within the given constraints is a subjective matter. "Good enough" or "close enough" aren't the same from one user to the next.

It would certainly be helpful for someone to do some experimenting with the FSX/P3D weather system and see exactly what kind of control and consistency is achievable. Then we'd have some empirical data on which to base a go/no-go decision on implementing an official realistic weather system for VATSIM, on both sides of the scope. I'm afraid I don't have the time at the moment, so someone else will need to do that part of the heavy lifting.
By Nick Warren 813047
#504356 That's certainly fair and reasonable. I think if we can set up some testing forum and committee it would be a worthwhile experiment. I can test FSX default engine against REX. I guess the first step is to gather interest to see if this can even grow legs.
By Simon Kelsey 810049
#504357
Ross Carlson 887155 wrote:The likely mismatch between what the controller sees and what the pilots see (and indeed the mismatch from one pilot to the next) is the main reason I haven't bothered to implement any weather radar overlays in my clients. It would be a fair amount of work, for the payoff of a half-baked feature. I know that some would rather have a half-baked feature than no feature at all, but I'm very much not in that camp.

If there was a way to get the majority of our pilots all using the same weather engine, and that weather engine provided consistent placement of storm cells from one pilot to the next, then I think we'd have a path toward a viable solution. Maybe it's possible now ... I don't know. I haven't put the (presumably considerable) time into figuring out if the FSX/P3D weather system can be coerced into consistent placement of storm cells. I read somewhere that it doesn't give you that level of control, but that was several years ago, and I don't recall the validity of the source.

Sure would be nice ... and we could maybe solve the winds aloft problem along the way.

And a solution so that X-Plane users aren't left out in the cold (vague pun intended) would be a bonus.


I don't have any direct empirical data for you -- but what I can say is that having spent a fair bit of time flying in a shared cockpit environment in aircraft with airborne weather radar, my experience is that the paints are very, very similar (certainly when both using the same weather engine, i.e. ASN) -- similar enough that I can point out a bit of weather painting on the ND at a given range and 99% of the time my copilot will be able to see it as well.

As others have mentioned, I suspect that it would be "close enough" to be a good guide to at least knowing where pilots are likely to start scattering, and any pilots using the ASN-driven weather radars on board most of PMDG's (and now FSLabs) latest offerings should be seeing very similar returns.

Of course, it's not going to be absolutely perfect for everybody but it never will be unless, for instance, we ban pilots from using custom weather settings etc (and, frankly, I imagine that the returns that a controller sees in real life could easily differ from those seen/interpreted on airborne weather radar equipment anyway). It ought to be, however, a good guide for those who are using real-world weather, especially in areas of high station density -- it might be a bit more flaky in remote areas where the weather engines are doing more interpolation, but I would think that most places with high traffic densities on VATSIM will have a reasonable concentration of weather reporting stations.
By Ross Carlson 887155
#504358
Simon Kelsey 810049 wrote:I don't have any direct empirical data for you -- but what I can say is that having spent a fair bit of time flying in a shared cockpit environment in aircraft with airborne weather radar, my experience is that the paints are very, very similar (certainly when both using the same weather engine, i.e. ASN) -- similar enough that I can point out a bit of weather painting on the ND at a given range and 99% of the time my copilot will be able to see it as well.


Are you saying the location of cloud formations was the same even when NOT using the same weather engine? Any chance the shared cockpit system was syncing the weather? We would certainly need to run these tests without any shared cockpit or multiplayer connection between the systems being compared.

I think the only way this will work, in my opinion, is if we can control the size and placement of cloud formations within about 10 miles. Let's say we have two pilots cruising along on the same route, and they both see a storm cell ahead, but one of them sees it in a location that would require a deviation left of course, but the other sees it in a location that would require a deviation right of course, then that will greatly erode the immersion level for both pilots, and also for the controller, especially if the controller sees the weather in such a way that one of the pilots ends up flying directly through the radar return when the controller grants the pilot's deviation request.

So I think it all boils down to whether or not different weather engines actually use real world weather radar data to determine storm cell placement (rather than just using a METAR and randomly placing the appropriate cloud formations within some preset radius of the METAR reporting station), and whether or not they do so with a level of resolution that results in the placement being within about 10 miles consistently from one pilot to the next. (Implementing near-perfect accuracy in the ATC client won't be a problem ... the achievable accuracy is only unknown to me on the pilot side ... I don't know what level of control you get with FSX/P3D/XP.) We may find that this would only be doable if we build our own weather engine ... and the chance of getting everyone to use a new weather engine (which likely won't be as good or full-featured as the existing engines on offer) is pretty slim.

Anyway, I'm obviously not optimistic, but more testing of the popular weather engines is needed and worthwhile.
By Simon Kelsey 810049
#504359
Ross Carlson 887155 wrote:Are you saying the location of cloud formations was the same even when NOT using the same weather engine? Any chance the shared cockpit system was syncing the weather?


To clarify, I think all the shared cockpit flights I've done have been with people using the same weather engine (ASN). However, I can confirm that the Aerosoft Connected Flight Deck system explicitly does not sync the weather radar returns (or the weather in the sim), as confirmed by the developers. The Aerosoft radar, for what it's worth, reads weather directly out of the sim and not from the ASN API as most other models do.

Ross Carlson 887155 wrote:I think the only way this will work, in my opinion, is if we can control the size and placement of cloud formations within about 10 miles. Let's say we have two pilots cruising along on the same route, and they both see a storm cell ahead, but one of them sees it in a location that would require a deviation left of course, but the other sees it in a location that would require a deviation right of course, then that will greatly erode the immersion level for both pilots, and also for the controller, especially if the controller sees the weather in such a way that one of the pilots ends up flying directly through the radar return when the controller grants the pilot's deviation request.


I see what you're saying, but this would/will/does happen whether or not the controller had the information on their display. Since the development of the ASN radar API, almost every payware add-on model now comes with a weather radar implementation of some description, and there are various freeware options/retrofits etc as well. So pilots (or at least those who know how to use the radar and/or give a toss about flying through CBs) will be (and are now) seeing airborne WXR returns and asking for deviations which could conflict with each other anyway.

I know ASN uses real-world SIGMET data for turbulence etc. I don't know how it works in terms of storm cell placement, but that's why I would suggest that the better route to go down might be to use (or at least give the option to use) the ASN API -- granted, not all controllers will necessarily own ASN, but for those that do the advantage would be that rather than trying to overlay real-world radar data that may or may not be well-depicted in the sim, they would be looking at data derived from a weather engine which has a very high probability of correlating well with that of any pilots in the airspace that have WXR functionality (as ASN is a prerequisite for 99% of current FS airborne weather radar implementations).
By Ross Carlson 887155
#504360
Simon Kelsey 810049 wrote:To clarify, I think all the shared cockpit flights I've done have been with people using the same weather engine (ASN). However, I can confirm that the Aerosoft Connected Flight Deck system explicitly does not sync the weather radar returns (or the weather in the sim), as confirmed by the developers.


That makes sense ... it's not at all surprising that the same weather engine would result in similar placement of weather for multiple pilots.

Simon Kelsey 810049 wrote:The Aerosoft radar, for what it's worth, reads weather directly out of the sim and not from the ASN API as most other models do.


There are weather radar gauges that don't rely on ASN, such as the one from RealityXP. I believe they use the same method (reading from the sim.)

Simon Kelsey 810049 wrote:I know ASN uses real-world SIGMET data for turbulence etc. I don't know how it works in terms of storm cell placement, but that's why I would suggest that the better route to go down might be to use (or at least give the option to use) the ASN API -- granted, not all controllers will necessarily own ASN, but for those that do the advantage would be that rather than trying to overlay real-world radar data that may or may not be well-depicted in the sim, they would be looking at data derived from a weather engine which has a very high probability of correlating well with that of any pilots in the airspace that have WXR functionality (as ASN is a prerequisite for 99% of current FS airborne weather radar implementations).


I see where you're coming from, but there's pretty much no way I'll invest any time developing a feature that ties the system to a specific payware weather engine.
By Josh Glottmann 1275389
#504361 I'll make this point. What if a controller is referencing weather based off a skyvector feed? One pilot might still need to deviate left and the other right, it's just now the controller could at least see half of the picture? I don't see necessarily how the controller client having a weather engine is connected to the pilots' weather engines. Pilots will always have incorrect weather in relation to that of what might actually be happening, and a controlling client with a weather feed won't change that.

Something else to consider is that even in the real world, weather is sometimes significantly lagged. At this current time, Miami Center has a 15ish minute update time on their weather radar. Knowing Florida, that's the difference between a hurricane and a nice calm day. If they see a cell, they'll try to vector a pilot around it, and if the pilot sees something, they'll report it and the controller take note of the new relative cell location.

This isn't a perfect science, not even in the real world.
By Ross Carlson 887155
#504367
Josh Glottmann 1275389 wrote:I don't see necessarily how the controller client having a weather engine is connected to the pilots' weather engines. Pilots will always have incorrect weather in relation to that of what might actually be happening, and a controlling client with a weather feed won't change that.


If the controller is getting weather from the same feed as the pilots, then it would match. As you said, pilots will always have incorrect weather related to reality, but the controllers would have equally-incorrect weather. This would be a significant improvement over the status quo.

Josh Glottmann 1275389 wrote:Something else to consider is that even in the real world, weather is sometimes significantly lagged. At this current time, Miami Center has a 15ish minute update time on their weather radar.


Very true, but lagged weather is a very different thing than "randomly placed" weather. With lagged weather, the controllers can still judge the direction of movement and have a good idea of where that weather is currently. Contrast that against the VATSIM scenario where pilots have varying, randomly-placed weather, and then you've demoted the weather overlay on the controller's scope to mere eye candy. The controller would not be able to use his weather radar for vectoring or realistic weather advisories. He would only be able to respond to pilot requests for deviations, and more often than not, those requests would not match what he's seeing on his scopes. Thus, the weather overlay is just eye candy, and the situation is no better than what we have today on VATSIM.

This is why I feel that adding weather data to our ATC clients isn't worth doing unless there can be some consistency between what the controller sees and what the pilots see.
By Alex Bresnick 949351
#504369
Simon Kelsey 810049 wrote:(and, frankly, I imagine that the returns that a controller sees in real life could easily differ from those seen/interpreted on airborne weather radar equipment anyway).


That is absolutely the case. The NEXRAD feed we get at centers is delayed by less than 15 mins (can't remember the exact figure). It also only displays moderate or greater precip. If a fast moving/changing storm is blowing through your sector, that precip overlay can be useless. And then there are times when we have no precip depicted on the scope for the entirety of the sector and pilots still request to deviate over buildups (and when it happens over an arrival fix to a TRACON that won't answer the line....gahhhh).

I don't control on VATSIM but Skyvector overlay seems to be a great solution until a client solution is (or never is) developed.
By Dhruv Kalra 878508
#504376
Ross Carlson 887155 wrote:The likely mismatch between what the controller sees and what the pilots see (and indeed the mismatch from one pilot to the next) is the main reason I haven't bothered to implement any weather radar overlays in my clients.


I understand the sentiment, Ross, but to be quite honest, the real-world NEXRAD WARP that ERAM gets is pretty low resolution to begin with (and somewhat delayed as confirmed by the previous posts). Such low resolution, in fact, that often times what we see out the windows and what the controller's 2D representation depicts can be wildly inconsistent. I've had controllers express outright shock that I've gone through what on their scopes appears to be heavy or even extreme precipitation with no ride or precipitation issues, and vice-versa.

Color me in the camp of strongly in favor of even the most generalized available weather picture on the scopes. It would greatly reduce the workload in having to match up and ballpark positions and distances using the skyvector method described by ZB above.
Last edited by Dhruv Kalra 878508 on Fri Sep 09, 2016 12:12 pm, edited 2 times in total.
By Simon Kelsey 810049
#504377
Ross Carlson 887155 wrote:I see where you're coming from, but there's pretty much no way I'll invest any time developing a feature that ties the system to a specific payware weather engine.


That's understandable, though I wouldn't so much look at it as tying it to a particular engine (which would imply some level of compulsion) as providing an extra feature for those who already own said weather engine. In an ideal world, I guess there'd be the option of the free NEXRAD data, or pulling the Activesky (/insert any other engine here that can provide the appropriate data) data for those who wish to do so, but I can see how that would increase the programming workload!

I don't know much about ATC displays (and even less about US ATC displays!) but I would assume the weather is generally an overlay that can be turned on or off -- in which case, if in a particular situation it is becoming distracting/particularly out of step with what pilots are experiencing then the controller could just turn it off. Even the NEXRAD data in theory should provide some sort of indication of the general state and location of the weather, which should be replicated to a reasonable extent in the vast majority of weather engines, if not exactly aligned (but then again -- as Alex and Dhruv say, it's unlikely to be in real life either).

As I say, you'd probably obtain the most accurate (for the VATSIM world) results from linking to some sort of weather engine, but I can completely understand why you might be reluctant to do that.
By Josh Glottmann 1275389
#504379
Simon Kelsey 810049 wrote:That's understandable, though I wouldn't so much look at it as tying it to a particular engine (which would imply some level of compulsion) as providing an extra feature for those who already own said weather engine. In an ideal world, I guess there'd be the option of the free NEXRAD data, or pulling the Activesky (/insert any other engine here that can provide the appropriate data) data for those who wish to do so, but I can see how that would increase the programming workload.

I think the best solution would be using a NEXRAD (or some free weather feed, there are plenty of them in use [such as the one on VATTASTIC]). Better keep all the controllers on the same page than every controller and every pilot having their own engine.

I don't know if either of these are worthwhile looking into. I just found them with a quick search.
NEXRAD on AWS
NOAA Weather Display and Conversion Tools
Iowa State's NEXRAD (US Only). This is what VATTASTIC uses.
What the XP NOAA Weather plugin uses
By Ross Carlson 887155
#504380
Dhruv Kalra 878508 wrote:I understand the sentiment, Ross, but to be quite honest, the real-world NEXRAD WARP that ERAM gets is pretty low resolution to begin with (and somewhat delayed as confirmed by the previous posts). Such low resolution, in fact, that often times what we see out the windows and what the controller's 2D representation depicts can be wildly inconsistent. I've had controllers express outright shock that I've gone through what on their scopes appears to be heavy or even extreme precipitation with no ride or precipitation issues, and vice-versa.


I don't see resolution as a concern. With poor resolution, the weather is still in the right location relative to the route of flight. Sure, it may be delayed, but delay can be compensated for in the controller's mental picture.

Even with resolution differences, delayed data, and other factors that we haven't even mentioned yet such as radar shadowing, the weather depiction on a controller's scope can still allow the controller to provide weather advisories that will be useful to the pilots in the area.

Remember that in the real world, controllers have another source of weather data: pilots. The pilots all get the same weather. And the weather reports that they give, or the weather deviations that they request, are all additional data points that improve the controller's overall picture.

I think of all these things as factors that contribute (positively or negatively) to the overall validity and utility of the weather picture for both pilots and controllers. You can also think of them as factors that move the "error bars" in or out.

That's real world ... now, step into the VATSIM world. You've just introduced a new factor that does not have an analog in the real world: your pilots have different weather. This is a negative factor that is potentially very large. It pushes those error bars much further apart. I say potentially because we don't really know how much variance there is from one pilot to the next and from one weather engine to the next. This factor makes the weather overlays on the controller's scope potentially much less useful.

I liken it to the usefulness of things like ride reports and wind shear reports on VATSIM. It is highly unlikely that the smoothness of the ride or presence of wind shear is going to be consistent from one pilot to the next. For the most part, these reports are just ear candy. They add a bit of realistic flair to the experience for both pilots and controllers. Certainly the same is true of weather overlays on the scope ... it would add realism for both pilots and controllers. However, there is one HUGE difference: ride reports require no software engineering. They are "free". Not so for weather overlays.

So unless we can get consistent weather on the pilot's side (and again, someone needs to do the testing ... we may already be "close enough") then weather overlays on the scope are effectively just eye candy, and, in my opinion, not worth the engineering cost.