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

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!

have you considered turning off notifications for a start?

@rittels Thanks for this phenomenal job!

this is already very useful - will do a balloon ride tomorrow early morning and see how that fares relative to the plot!

If I may add a suggestion:

if you select several altitudes on the plot it is hard to discern which track belongs to which altitude

why not choose different colors for each track in the plot and color the altitudes in 'Select levels' accordingly?

• Michael

semi-related: I wrote up a tutorial on Alps crossings with a hot air balloon as there is next to zero material available on the issue

it gives an idea of the meteorological prerequisites: http://static.mah.priv.at/public/alpcrossing/assets/player/KeynoteDHTMLPlayer.html#0

(suggestions for improvement and bug reports welcome)

Here's something neat: visualize an expected balloon flight in 3D based on a windy trajectory:

https://ayvri.com/scene/49j7m8dzje/cjzp38qi200013d5vtyo4jj3j

The GPX file was created with windy.com and the traj plugin. It includes an ascent and descent phase of 2m/s and level flight at 1500m. The GPX file was then uploaded to ayvri.com (free account required).

The ayvri visualization is based on cesium.js - for the curious, play here: https://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=CZML Path.html

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

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

Here's another long jump - from today

435km in under 4hrs, peak 80kts - and phenomenal forecast accuracy!

https://blog.mah.priv.at/gpsvisualizer/20200105044229-47167-map.html

A video from the second flight:

Duh. Thanks ;-)

(cosmetic)

should not this be rather liters per square meter rather than square kilometer?

good move

very important for street cred so windy is not cornered in as a pet project with vague prospects!

superb!

curious - are you using an optical flow algorithm?

• Michael

@jmh2002 that looks very promising

will contact the author and see what can be made of it

here is an example what I'd be looking for: https://sailpatience.com/where-is-patience/ - an embed provided by https://www.predictwind.com/ (which pushes all the right buttons for people trying to do tracking and weather as an embed)

Question - how would I create an embed widget given I have a dynamic KML/GPX//GeoJSON fragment?

The input file would need to be passed as a URI parameter as it might be created on the fly

for the same reason, the upload to windy.com seems suboptimal - assuming you would not want a public upload everytime someone retrieves the page with the embed on it

any suggestions?

thanks in advance.

another data point:

https://blog.mah.priv.at/index.php/2020/02/22/windy-traj-forecast-versus-gps-track/

@marekd said in Turning off a plug in?:

@rittels @mhaberler Plugins aren't used very much right now.
@ivo

Usability might be a cause for that.

I've given tutorials to my particular community on windy usage and have been invited for more, next in Switzerland in March. They are basically 'this is the philosophy and now let me hold your hand' events. And @rittels puts in a lot of hours into working in feedback.

So I'm somewhat dubious if your argument holds water if you look at specific segments, not just the overall usage.

Of course plugins cater to specific community, even local use only. Plugins which are used by everybody and his dog are not going to happen IMV.

Even if this is so, it is clear to me that user extensibility of a weather application has been a phenomenal success and has raised the bar for others

Maybe it is worth reconsidering what the relation of the open-source part of windy (right now - user-contributed client-side plugins only) and the closed-source part (server side and curated client-side code) is to be in the future

Example - what about open-sourcing the non-core/not-license-encumbered parts of windy to stimulate more user contribution?

Let's take the 'Upload KML, GPX or GeoJSON file' as a case in point:

1. it is a tad lame as it stands - 'can display polylines in color, issue closed'.
2. No attention to importing files generated by plugins given
3. if I want to make it useful for say displaying route planner or traj GPX files, I need to re-implement the whole yadayada, not just extend and build on what is already there

ad 2. I'm fine with that in principle - I do not expect you to jump every hoop users come up with. We're happy to fix that ourselves. But then you need to grease that capability a bit. Going closed source in irrelevant areas has a cost: usability is one of them. And I'd be fine to do that under a 'do with it what you want' license.

Another example: Integration of custom data layers, and a way to share them.

Any plans in that direction? this could be a significant booster for acceptance, and creating applications which even you never thought of.

And some markets, btw - just look at how an average nation aviation weather office displays its data. Mine makes me weep ;-)

• Michael

@rittels said in Turning off a plug in?:

It would be great if we could launch the plugins from the URL. The open plugin buttons could link to the address of the plugin. (please @ivo, @marekd )

This is important for usability for sharing a plugin setup, which is needlessly cumbersome right now. And it is easy to fix.

It should come down to passing a link which includes the plugin name, AND the set of parameters to the plugin. Opening the link should open windy, install the plugin listed, and set the parameters as per URL. Totally fine if that works only for blessed plugins.

Right now we stand at 'pass a screenshot as png'.

Please make that possible.

thanks, Michael