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

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

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

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"

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!

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

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?



@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

via:

@ivo
from a technical perspective I actually agree with your decision to deprecate plugins in their current form.

Sometimes technical developments invalidate past decisions, and that seems to be one of those cases.

Let me also remark that the 'tens of users' numbers you cited seem deceiving, as can be seen by the reaction in this forum. There is a rather simple explanation for this in the trajectory case:

Trajectories mostly are run, downloaded as GPX, and made into a shareable link with https://gpsvisualizer.com to bring this into presentable and permanent form. That link is then shared by Whatsapp, mail, social media and whatnot like so: https://static.mah.priv.at/cors/example.html . Those links routinely get dozens of clicks, sometimes in the hundreds at a large event. I know because I host those links.

That said, plugins are API's, and API's are promises - something users and developers rely on to be upheld. If you are about to break that promise, then I would suggest in the minimum a migration path be offered to not leave users without functionality they relied on - of course assuming you want to retain those users.

I do not see much of a migration path being offered in your post.

Let me therefore outline options, first from a Windy perspective.

(1) you go ahead and drop plugins wholesale, without replacement option as you announced.
(2) you take the minimum required functionality of the trajectory plugin, transplant it to your backend and add that as a standard layer in the frontend.
(3) you drop trajectories altogether, but you make the Point Forecast API to support all weather models - the current functional set is unsuitable.

The minimum required functionality IMO is:

• a set of forecast models
• a set of altitudes
• duration of flight
• forward/backward option
• path download option.

Everything else which is not essential, not important to be configurable, low usage to start with or can be had differently can go or replaced by fixed parameters: Airspaces, interval times, ascent/descent simulation etc.

While I hesitate to call this effort 'trivial', it is not particularly complicated either.

Now, speaking for my community, I envisage the following outcomes:

as for (1), you will likely see a mass defection to Meteoblue, and I am certainly prepared to get in touch with Meteoblue and communicate our needs more clearly.

If this were the outcome, I would pursue - in parallel - a homegrown solution the same way the radiosonde effort started fairly soon, and there is existing work to give us a headstart.
While more work for us it would also enable us to be more fit for our purpose, for instance finer altitude resolution. Since I am aware of, and in touch with a part of the European Defense community (paratroopers)
I envisage a possible cooperation and maybe even ongoing funding option for such an effort.

(2) would IMO be the best option for Windy: it gives you a free hand to develop the frontend, it is functionally a superset as to what Meteoblue and others offers and you both gain a competitive feature while lowering your maintenance load.

(2) would also be best for the ballooning community, as we get a stable function and on mobiles.

(3) would be tedious for us as we need to build a replacement service based on an improved Point Forecast API, and we would still have to trust that this API promise not to be broken again - which, as things stand - I am uneasy with.

However, it would enable you to pursue business opportunities as mentioned which seem to be off the radar as of now. Those opportunities exist - see DarkSky, but pursuing them needs a significant effort on your part on the API front.

My recommendation is option (2).

Your call.

Michael Haberler