windy-plugin-radiosonde
-
@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.
- Michael
-
@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. 👍😁
-
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 beautysearch 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.
thanks
- MIchael
-
@rittels Thank you for this great job !
Could you please explain what is exactly the "THRM Top" please ? -
Thermal top: The top of the thermal reached, for the selected parcel temperature. This is indicated by the top of the green line, following the dry adiabatic lapse rate.
Should convective clouds form (thus the isohume line from dewpoint and dry adiabat line from surface parcel intersect, the lapse rate will follow the moist adiabat line), the Thermal top then equals the cloudbase. The CLD top will then indicate where the evaporating parcel stops rising
-
-
I am happy to announce a significant improvement to the data quality availability through the windy radiosonde plugin, related to the backend service
in summary:
we have MUCH better coverage in high-resolution ascents since two days, as well as new stations appeared which had no coverage at all so far
this is thanks to a patch developed by windy's formidable Mr Karpíšek @FILIP_K which is running in the backend now - congratulations, Filip!
the gory detail:
radiosonde ascents are distributed in two formats, a telex-oriented legacy format called FM35, and a more recent high-resolution format called FM94 (or BUFR in meteospeak)
due to redundant data feeds, we receive both formats for many stations - if for a given station a high-res view is available, that is given preference - if we do not have something else, we fall back to the legacy format
I've been running this backend service for close to a year or so, and I always wondered why for some stations we have a strange form of coverage: sometimes we get hi-res data, but in many cases just legacy format. And there was no obvious pattern recognizable why this is so. My initial suspicion was that this was just an artefact of some data feeds which we have no control over, so have to live with it.
This manifested itself most visibly in Russian radiosonde ascents, but - as we later found out - has affected data from many other countries as well.
Following an in-depth exchange with helpful friends in Russia, it became clear we better search for errors in our software. I detected a smell in a central piece of code, and Filip came up with a key improvement in no time flat.
I very happy to have that mystery resolved.
You can probe yourself:
- Hohhot ZBHH (China, WMO id: 53463) - visible in hi-res since two days, no previous data
- same for Lhasa ZULS (WMO id: 55591), Ezeiza Aero SAEZ (WMO id: 87576), Neuquen Aero SAZN (WMO id: 87715)
- Bechar DAOR (Algeria, WMO id: 60571) - hi-res now, previously only legacy format
- all Russian stations are hi-res now AFAICT
- ascents distributed via NMC Denmark and Meteo France als improved in quality
I am pretty sure this service is now best-of-class as far as publically accessible sources of radiosonde ascents worldwide go!
-
This is a great plug in! Thank you so much for your work. Are the 750hPa, 650hPa, and 550hPa levels of data available for the GFS and ACCESS? Would be awesome for thunderstorm fore
casting? -
I ivo referenced this topic on
