Yes, geopotential height is not available for Arome, via Windy. I use calculated values, which is not ideal.
Would you recommend that I leave it out, or use ECMWF?
@rittels said in windy-plugin-radiosonde:
Hello, I'm not sure if this belongs in the Bug reporting topic or on here but ever since about a week or so ago, both the forecast and observed soundings look very compressed vertically compared to what they used to look like, no matter what web browser I use. Has this been intentionally changed recently?
I've attached a couple of before and after screenshots to illustrate my point:
The reason why altitude parameters are not shown with AROME is because Windy use the 1.3km version of this model. The 2.5km version includes altitude parameters. But difficult to imagine Windy showing both.
Thank you. I fixed the flat skewt a few days ago, but another bug crept into extra settings. Will fix later.
Thanks, I have removed altitude values from AROME, more honest than using calculated values.
guy_bottlaender | Premium last edited by
@rittels I think that's better to leave it out, sorry for that.... What about downloding ARPEGE data wich are free on data.gouv.fr?
guy_bottlaender | Premium last edited by
To the development team that put together this plugin "windy-plugin-radiosonde"....top shelf - great effort!!
From a Prof Met's perspective....this is a very useful tool and one I only recently discovered and now use continually....so a BIG thanks!
One issue: could you take a look at the numerical wind speed values within the Skew-T diagram when you mouse over a level. It appears the numerical values are displaying speed in metres/sec when there is a knots value displayed. For comparison, the wind barb notation is correct in units of knots.
Wind barb is ~60kts....numerical wind speed is 30.3 m/s (and not kts as displayed). Could you correct the numerical value to "knots"?
Otherwise, great work! Highly appreciated.
PS: If you could incorporate real-time sonde data (during the balloon flight) from Sondehub into the Skew-T diagram up until the completion of the sonde (with the data then replaced by completed sonde data - as currently displayed), then that would be a GOLD medal in my books.
😳 Oops. Thank you for picking that up.
@stitch Michael here, author of the radiosonde backend
re sondehub realtime data integration: that was always planned and I'm in contact with the sondehub team since over a year towards that end.
From an integration perspective it looks reasonably straightforward. However, server side things would not be as easy as the current radiosonde backend which is basically serving static files. Also, data quality is an issue - data from sondehub might not be validity checked as the data from meteo aggregators is.
Currently this backend service is running on my hosted server, and its future is undecided as of now.
@mhaberler Hi Michael. I appreciate the challenges that go with developing these products. And, as I have mentioned, this plug-in has been beneficial to my work. Can I include another request? Within the skewT diagram, are you able to plot the wind speed numeral values beside the wind barb? This would conveniently illustrate the wind speed without needing to mouse over each level.
Thanks, . . . .
The plugin loads, but doesn't show any stations. Is it broken or it's something on my end?
@rittels .......you are a champion!!!
This plugin just went up another few rungs. And I noticed you have plotted the 1000hpa level wind/temp on the skewt when this is not available on the main window viewer....bonus.
Thankyou (big time)
@mhaberler .....see my comments above to @rittels
A big thankyou for your work putting this plugin together. 👍😁
Aadesh Garg Chile alerta last edited by
Wow its good
service is currently degraded, investigating
Service is back to normal
several station locations have been fixed
to explain the little hiccup yesterday:
the radiosonde backend is essentially a database which maps a station ID to a series of radiosonde ascents tagged by time
the station ID is assumed to be globally unique, assigned be the WMO, and hence can be used as primary key.
Or so goes the theory.
In practice, all sorts of junk data comes in, like this beauty
search for 'station_id' and well... its just blanks. And there went the primary key.
The code has been fixed to skip such stations, so we have to live without Tunis/Carthage for now until they fix things there.
Another problem creeping up from time to time is: there is no single, well curated source of WMO station information; there are station lists kept by different organisations in varying degree of accuracy and state of rotting. And sometimes those entries are plain wrong - for instance, wrong coordinates.
this manifests itself by a circle on the map at location X, and when you click it, the trajectory shows up elsewhere on the map.
If you find such a station, please file an issue or pull request against this file.