Weather Advisories, the VATSIM Way!

[Evan Reiter]

 

It was a very, very rough attempt. There's a difference between how VRC "projects" the Earth vs. how the NEXRAD feed does, so there's some 3D transformation going on that's not right. I accounted for the -13.75 degree rotation on the VRC scope, but that's about it. Plus, you can see the color I chose for transparency (magenta) bleeding through around the edges of the NEXRAD imagery.

 

Like I said, rough. But sometimes I get bored and want some nerdy side-project to work on, so who knows.

This is actually fantastic! How long until something like this could be shared? I know it's something we have ALL been aching for. Fact is, quite often, airborne weather radar picks up a different area of precipitation than what's seen on the ground. A bit of variation between clients would be just fine.

 

Another thought to consider (not sure how easy it is with the GUI overlay you're working with) would be that most of the FS weather radar simulations are powered by ActiveSky. I wonder whether there's a way to use that same API for your application, so controllers and pilots are both seeing weather powered by ActiveSky. It's possible there will still be some variation but it may be closer because it's coming from the same source.

 

Please keep working on this! Can't tell you how much I've wanted to be able to bring realistic weather simulation onto the network.

[Bradley Grafelman]

Welp, I gave it the ol' college try, but I think I'm about ready to shelve/abandon this side project. Here's an updated screenshot followed by an explanation of the script's current capabilities and pitfalls:

 

 

Capabilities:

• Automatically "learns" the current center/zoom of the VRC scope
  
• Automatically adjusts to VRC window size and "fills" the viewable scope (padding added for button bar at top and command line at bottom)
  
• Supports customizable margins (e.g. in case you like to keep the Arrivals & Departures, Controllers & Chat, etc. windows opened arranged along one side of the scope).
  
• Supports customizable brightness of the weather radar overlay
  
• Pressing Ctrl+F7 while VRC is the active window will draw the overlay on top of it

 

Pitfalls:

• First and foremost, it's not very accurate when it comes to drawing the weather at the correct place.
   
  The weather tile service uses a spherical mercator projection, whereas VRC is more of an equirectangular projection. I don't know if that's a major contributor (meaning I would need to post-process the image tiles with something like gdalwarp to do a re-projection) or if I've just goofed up the math that calculates VRC's pixels-per-latitude scale.
   
  Either way, the weather isn't stretched/positioned correctly. Zooming in/out yields different results during the same NEXRAD cycle. I've got an idea or two left to try, but the guesswork combined with the other pitfalls is making me rapidly lose interest.
  
• Because VRC has no "hooks" (that I know of), I wrote all of this in an AutoHotKey script rather than creating some sort of application or, better yet, plugin for VRC. The TL;DR is that there's a bit of mouse-moving/screen-flashing whenever the weather is drawn. If you have epilepsy, I wouldn't recommend staring at it.
  
• Continuing from above, I don't have a good way to track changes in the scope (either panning or zooming), so for now I've just tried to detect such changes and remove the overlay. If you want to pan/zoom and see the weather, you'd have to hit Ctrl+F7 to redraw the overlay again. (I could probably automate the redraw, but the flashing/mouse-moving would get exponentially more aggravating.)
  
• Again as an artifact from above, I can't play with the "z-layering" of the overlay vs. items on the scope. Most notably, this means I can't slide the overlay in between the scope background and the targets depicted on it. You can see this in the screenshot above; both the target and datablock for an aircraft are partially obscured by the weather overlay.
  
• The method I'm using to get the lat/lon coords causes the text chat to be filled with 4 lines of "Mouse coordinates copied to clipboard" messages. Could probably cut this down to 2 or 3, but still...
  
• Several other things I'm almost certainly forgetting.

 

TL;DR: Probably abandoning this soon. It was a fun exercise in staving off boredom in my free time, but in the end I think any approach that doesn't involve support from the ATC client developer isn't going to be very feasible/usable.

[Matthew Kosmoski 891361]

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

I know I'm very late in responding to this, but it's worth noting... NEXRAD isn't stored in GRIB/GRIB2. I spent most of my early career doing weather development. You'll see most of it in BUFR or NetCDF, which means wgrib2 is of no use. Also, if you're incorporating the data, wgrib2 is one of the least efficient manners to play with the data. Native grib2 libraries (or reading the spec and just dealing with it... it's only JPEG2000) are the correct route. First time I dealt with large quantities of GFS, I tried using wgrib2 and the -spread flag to get the data to a place where I could import it to our databases... that was a mistake

[Nick Warren]

Little bit of keeping the thread alive and also sharing a short video from the Air Safety Institute and NATCA. Basically the nuts and bolts go to say that ATC may not see what the pilots see as far as Wx goes. I'm biased, but I think it supports the argument of implementing something consistent on the ATC end without as much worry for what the pilot may be seeing.

 

[Nick Warren]

So the issue of weather, deviations, etc. and ATC's role have popped back up in a few forums/chats recently. Just wondering if implementation of weather has been given any more thought over the last year and a half, or if this topic and thought is dead.

[Andrew Morkunas]

Now if only we could get a weather radar on our clients

 

Yep - I just got negative feedback from my last control situation because I did not handle a weather deviation properly. Skyvector looks like the way to go to keep things real.

 

Weather on our radar clients. I think that is coming after the new voice codec.

[Nick Warren]

Weather on our radar clients. I think that is coming after the new voice codec.

 

Not sure what one has to do with the other, but do you have a source for that info?

[Andrew Morkunas]

Just adding humor to conversation.

[Nick Warren]

Just adding humor to conversation.

 

And humourous it was :

[Ross Carlson]

Yep - I just got negative feedback from my last control situation because I did not handle a weather deviation properly. Skyvector looks like the way to go to keep things real.

 

Andrew, can you elaborate on that? What did you do, what should you have done, and how would using Skyvector have helped you avoid the negative feedback?

[Andrew Morkunas]

@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 Cl[Mod - Happy Thoughts] 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 [Mod - Happy Thoughts]ign 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.

[Richard Gerrish]

All the sims will create the weather we see differently from the same data.

[Dhruv Kalra]

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.

[Richard Gerrish]

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

[Ryan Geckler]

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.

[Nick Warren]

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.

[Ross Carlson]

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.

[Nick Warren]

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 gl[Mod - Happy Thoughts] of juice at the end is worth it from a developer standpoint.

[Ross Carlson]

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.

[Nick Warren]

As me, a vSTARS terminal guy softly cries in the corner

[Simon Kelsey]

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).

[Ross Carlson]

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.

[Simon Kelsey]

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.

[Ross Carlson]

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.

[Simon Kelsey]

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 docomeentation tomorrow).