I would be interested in alerts when a particular value combination arises in the forecast.

The overall alert condition is a combination of several subexpressions.

let me lay out the idea by example:

given:
location1, location2, location3, time-of-day1, time-of-day2
maxtemp

if  (temperature(location1, time-of-day1, surface) < maxtemp) AND
    (wind(location1, time-of-day1, surface, IconEU) < 10km/h) AND
    (wind(location2, time-of-day2, FL180, ECMWF) > 80 km/h) AND
    (wind_direction(location2, time-of-day2,FL180, ECMWF) between 290 and 20 degrees)) AND
    (wind(location3, time-of-day3, surface, IconEU) < 10km/h) AND
    (temperature(location2, time-of-day1, surface) < maxtemp)

then
   create alert("Alps crossing possible")

having this done once nightly looking into the future as far as models provide that would be super useful.

I admit the parameterization is complex and probably pushing the envelope for a mobile gui - it might be more productive to address the issue algorithmically (plugin idea!)

thanks for this great tool!

Assuming the average alert user is as clueless about Javascript as I am:

a framework feature for generating alarms, and a set of predefined, selectable (possibly user-contributed) JS fragments (really condition expressions) which can be parameterized:

that would go a long way without the complexity of a full-blown programming language based solution

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!

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 thought you might like this:

a local flight in Styria last month:
https://cesium.com/cesiumjs/cesium-viewer/?source=https://static.mah.priv.at/cors/stiwoll-muggauberg.czml

two balloons crossing the Alps late last year:
https://cesium.com/cesiumjs/cesium-viewer/?source=https://static.mah.priv.at/cors/filzmoos-treviso-oesoe-oesfy.czml

the trajectory lines are generated from the GPX files the windy-traj plugin offers as download, the flight tracks are actual GPS data

motivational screenshot of the latter flight:

and here is a 360° video of that flight:

note the whole animation is encapsulated in a single CZML file and just uses the public CesiumViewer service from the Cesium project

• Michael

ps: for the curious: this documents arguments to the CesiumViewer

Re: anybody working on a trajectory plugin?

I neither need nor want the detail map on zooming in as it clutters the view

how can I get rid of the detail background map?

suggestions:

• in settings->Change background map provide option: "coarse map" or somesuch to avoid the detail-switching
• or right hand side menue - "no map detail on zoom in"/"retain coarse map"

is that planned to work eventually?
will it never work for some reason?

thanks! pawed through the FAQ and articles - couldnt find an answer

a summary of my experience using Windy for hot air ballooning

slides for this talk:
https://static.mah.priv.at/public/windy-for-balloonists-2022 - online HTML version
https://static.mah.priv.at/public/windy-for-balloonists-2022.pdf - PDF version

• Michael

The most prestigious gas balloon race in the world is the annual Gordon Bennet Cup

Pilots stay aloft for several days and might cross the continent

To get an idea, here's a video of the tracks flown this year:

The teams have (and need!) a ground crew which advises pilots on weather and tactics

This year, windy and traj were part of the games - in the ground support for the Belgian, Spanish and US teams - Kolja Packard wrote up a field report (he was part of the support team and worked the weather forecasts):

(this is still german-only, I will post an english translation shortly and notify here):

https://blog.mah.priv.at/index.php/2019/10/01/erfahrungsbericht-einsatz-von-windy-beim-gordon-bennet-cup/

In particular, have a look at the very first image in the blog post - this was the track forecast 20 hours (!) before takeoff

compare that to the youtube video above - the match is amazing!

Many thanks to Kolja in writing this up!

New Pressure Difference Plugin for the Alps region: Foehn, Bise, Bora, Ora, and Peler forecasts

@wetterheidi has developed a pressure difference plugin for the Alps region, covering the major Foehn lanes, Bise, Bora, Ora, and Peler.
It shows forecasts using ICON-D2, ICON and ECMWF

Give it a try by: Menu -> Install Windy Plugin -> Load plugin directly from URL and paste the following URL:

https://windy-plugins.com/1042730/windy-plugin-pressure-difference/0.0.4/plugin.min.js

Then it's accessible as Main -> Pressure Difference Charts

Please direct comments to @wetterheidi , I am just the PR agent tasked with conveying the good news.

For issues and pull requests: github repo is at https://github.com/wetterheidi/windy-plugin-pressure-difference

can I ask for review and listing on the gallery?



Dear Windy team:

can we have a postwar method of reporting and tracking bugs?

reporting bugs on a forum just to met with silence and fall off the cliff eventually is pretty 80ies

The github issue tracker has been invented, and signing up for github is free.

Please.

starting with a sounding - can change forecast models just fine
switch to nearest radiosonde ascent - appears
click away the radionsonde ascent - view changes back to ECMWF sounding
changes to weather model have no effect in sounding view anymore
title is wrong - sounding, not radiosonde

here is a visual bug report:

Michael

@kekert I see, thanks for providing the definitive point of reference

I assume the use case I laid out would impair specifically 4.6.1 "... and/or downloading of significant portions of the Content" in your view, correct?

Michael

I am looking for a definitive answer to the question "what data can be downloaded from a plugin under which conditions"

I am aware of the T&C for ECMWF data, so let us talk about non-ECMWF data from hereon. I am also aware of the Point Forecast API and have a key for that.

the context: a plugin being built for parachuting purposes

it gives the option to download the vertical profile for a given time, location and model
the vertical profile is then used for predicting a glide path with another application

a comparable tool which inspired us - and we want to improve upon: https://markschulze.net/winds/ - great, but only GFS data

My question is: can we do better than windsaloft without violating WIndy T&C?

I would appreciate a definitive answer - searching the forum so far has yielded only fuzzy answers.

Thanks in advance - appreciated.

Michael

@Xutao-Guo I was bitten by this too

I would like to express my gratitude to the team - in particular @Filip_K - for picking up this loose end and coming up with a significant improvement of the "Rain,Thunder" layer as well as improved icons !

I reported this on our ballooning whatsapp group and there were quite a few cheers

thank you!

Michael

New Pressure Difference Plugin for the Alps region: Foehn, Bise, Bora, Ora, and Peler forecasts

@wetterheidi has developed a pressure difference plugin for the Alps region, covering the major Foehn lanes, Bise, Bora, Ora, and Peler.
It shows forecasts using ICON-D2, ICON and ECMWF

Give it a try by: Menu -> Install Windy Plugin -> Load plugin directly from URL and paste the following URL:

https://windy-plugins.com/1042730/windy-plugin-pressure-difference/0.0.4/plugin.min.js

Then it's accessible as Main -> Pressure Difference Charts

Please direct comments to @wetterheidi , I am just the PR agent tasked with conveying the good news.

For issues and pull requests: github repo is at https://github.com/wetterheidi/windy-plugin-pressure-difference

can I ask for review and listing on the gallery?



what @wetterheidi reported is a bona-fide bug: your app is trying to predict convective activity using the ICON* models, and reproducibly fails to do so

I consider this misprediction actually a safety issue since it fails to predict dangerous situations while it actually could - and that has happened to, and was observed by several people. To me, two days ago.

A prudent responses would have been "we will look into this and try to reproduce", "can we have more examples to figure what exactly is going on" or "how could we improve this"

to be candid @Suty : a "generic" repsonse (and that is a kind characterisation) like yours to such an issue is verging on the irresponsible - we are not talking about a typo; for instance, basing a flight decision on such a forecast is a recipe for trouble.

I wish you understood that, and you obviously dont.

To the other folk reading this thread and scratching their heads what is going on, please try the following to reproduce:

if you have a gut feeling there could be significant convective activity the same day:

• observe meteograms for ECMWF, GFS, METEOBLUE and any applicable ICON* model
• take screenshots of same
• record radar/precip/lightning activity
• then evaluate which of the meteograms actually reflected reality

You guys should take this issue serious.

I want to extend the Foehn and Bise example plugin as an exercise to work along any two points - not just Zurich and Lugano

for that I need two points (ie markers) on the map with a line draw between them; line follows if end markers moved - exactly what Leaflet.DraggableLines does (demo)

however, this is pretty much already in "Distance and Planning":

Could anyone point me to an example how this is done with the current Windy Leaflet version? none of the public examples I perused do anything like that

Is there a list of "blessed" already-used Leaflet plugins I can safely reuse?

thanks in advance
Michael



certified js/web idiot here.

I wrote up some notes on getting the plugin examples to work on MacOS/Chrome

https://github.com/mhaberler/windy-plugins/blob/new-plugin-scheme-macos-tests/NOTES.md

happy to add hints for other platforms and browsers

if there's a warm place for such stuff on https://docs.windy-plugins.com/getting-started/ - happy to make it into a PR