Hot Air Balloon Pilots

21/04 festival 2022

https://www.windy.com/upload/626705ee4e1a1e3115fb7f7e

Upload your own KML, GPX, GeoJSON file at https://www.windy.com/uploader

23/04 FESTIVAL 2022

https://www.windy.com/upload/626704df4e1a1e3115fb7f7d

Upload your own KML, GPX, GeoJSON file at https://www.windy.com/uploader

RAPOSA DIA 18/04/22 Praia

https://www.windy.com/upload/625f0c3cbda822921441ce1b

Upload your own KML, GPX, GeoJSON file at https://www.windy.com/uploader

@korina in case the feed is in place, but the station numbers are missing and that happens to be the reason why the stations are not shown:

I feel with you as getting an official and well-curated list of WMO station id's and related information is next to impossible, it is a real mess - I started my own curated list for the radiosonde project, adding missing stations piecemeal

However, there is an interesting project which already maintains such a list of stations in JSON format and I'm considering using this list, after adding any missing pieces and then switching to it

Maybe you'd want to discuss internally if you want to switch as well, or fork it at https://github.com/windycom ?

this list is pretty comprehensive, easy to process and it should be in pretty good shape if maintained by several parties

Hi @Korina

@wetterheidi and me looked a bit more into the issue

In case the raw data feed is missing:

the German SYNOP reports are available via https://gisc.dwd.de/wisportal/ via the subscription German_Reports_SYNOP ("Internet Subscriptions -> Default Carts -> German_Reports_SYNOP"). Those are in the BUFR (FM94) format, very similar to what @Filip_K is already retrieving for the radiosonde data

here is one example member of the German_Reports_SYNOP dataset - it contains two of the stations Heidi mentioned to be missing:

can be found on https://gisc.dwd.de/wisportal/ via the search term "GTS Bulletin: ISID03 EDZW - Observational data (Binary coded) - BUFR (details are described in the abstract)"

Chieming is in "GTS Bulletin: ISGD09 EDZW - Observational data (Binary coded) - BUFR (details are described in the abstract)"

Michael

@korina just noting these are still missing

there's a ton of personal weather stations, but then those are not a good replacement for the quality-controlled SYNOP stations

I am pretty sure you would get those via the DWD feed, but I dont envy anyone working with https://gisc.dwd.de/wisportal

@rittels suggested to use https://windy.com/plugins on iOS to get at the list of blessed plugins

long press this link and choose "open link" does work on iOS/Chrome

still... error reporting for windy needs some love

up until a few days ago one could visit https://windy.com and use it like on the desktop (with Hamburger menu and all)

the Hamburger menu is gone on iOS both with Chrome AND Safari, it still works on Android

means: use of plugins impossible - why?

was that intentional? or just an accident?

where can I find a list of changes over time so I can avoid asking here and check myself first?

what is the proper place to report this? This category? Any category?

what about an issue tracker for changes and defect reports instead of littering this stuff over dozens of themes and categories?

I created this for my hot air balloon community fellows, but it might be useful for others:

https://static.mah.priv.at/public/windy-for-balloonists-2022/#0

feedback welcome

Michael

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!