Windy Trajectory plugin updated

Chris recently released a new iteration of windy-plugins-traj (0.7.0), with several new features:

  • show the temperature along a given trajectory
  • Here button provides for easy re-planning from current positon and alitude
  • tracks are now marked by model-specific markers
  • selectively displaying altitudes and forecasts based on a specific model
  • additional forecast models: NEMS and namConus
  • selecting between accuracy and speed: using the ‘Layer Interpolation’ switch

Let’s go through these in turn:

Temperature along a path

Once you have created a path, click on a point along the track. The popup shows the forecasted temperature at this location – useful for the loading calculation, and planning proper clothing:

the outside air temperature displayed along the path

Tracks downloaded as KML or GPX files will carry along temperature values except for ECMWF-generated tracks. You can see the temperature forecasts in windy, but due to licensing constraints the values are not exported for ECMWF.

Not every program which reads GPX files actually can display these values. Barring a better alternative, exporting in KML and reading in Google Earth will display temperature values:

Google Earth will show temperature values when importing a windy-traj generated KML file

Here: warp me to where I am!

On a recent balloon ride we had to decide wether to rise, descend, or stay level to reach a certain target. Since we had mobile Internet coverage, we used windy to re-generate trajectories for different altitude choices.

As always, you need a starting location. So that’s what the ‘Here’ button does: It will retrieve your current location, set the location picker, and – if an altitude value is available – set the next matching altitude.

I got a field report today from a gas balloon ride that this feature works exactly as advertised.

Model-specific markers

Generating tracks for several models and altitudes easily makes for a cluttered screen. So far, all tracks were marked with black circles in (by default hourly) intervals. All trajectories of a given model now have distinguishable black marker icons:

  • ECMWF – circle
  • GFS – rectangle
  • iconEU – triangle, upward pointing
  • nems, namConus – triangle, downward pointing

Selectively displaying altitudes and forecasts

Selecting several models and altitudes easily makes for a confusing screen. Chris added the capability to selectively turn on/off tracks by model and altitude. To do so, the menu needs to remain open – then, clicking models and altitudes will (de) select the display of the corresponding forecast track (click here for a full-screen version):

Addional forecast models: NEMS and namConus

This version adds two models:

  • namConus (North American Continental US), 5km grid, by NOAA, some 3 days lookahead)
  • NEMS by, 4-12km grid, based on NOAA model with meteoblue extensions added, claims to be strong in Alpine areas, 2 days lookahead, ground up to 1500m (850hPa)

namConus seems generally useful for ballooning purposes and adds a third model for the North American continent in addition to ECWMF and GFS.

NEMS, however, looks rather restricted for aviation purposes as currently available in – lookahead two days only, and covering altitudes only up to 1500m, which makes it useless except for rather mundane flights. As it stands, this is not a replacement for the meteoblue trajectory function, which covers higher altitudes as well as six days lookahead – for a fee.

Note that NEMS trajectories currently only work with the ‘Layer Interpolation’ option selected – see next section.

Selecting between accuracy and speed

This version adds a switch in the menu: ‘Read data with:’ being ‘Data Loader’ or ‘Layer Interpolation’, with ‘Data Loader’ being the default.

If exploring NEMS trajectories, remember to select ‘Layer Interpolation’ or you will see a message ‘No model’ displayed. Also, remember – NEMS currently only works up to 1500m.

The way I understand this switch – it is a tradeoff between speed and accuracy. Layer interpolation works much quicker (almost an order of magnitude) but sometimes gives odd result.

My recommendation: if exploring many altitudes and models, it might make sense to select Layer interpolation initially, and to switch to Data Loader once you drill down to a smaller set of altitudes and models, yielding more accurate results.

Geekspeak: The Road Ahead (coders only)

Chris tried hard to accelerate trajectory computation, and the Data Loader/Layer Interpolation knob is a step in this direction. But at some point it might make sense to move work to the windy backend.

Right now all the work is done in the browser, but each data point needs a server interaction to retrieve a new value set – which slows things down considerably. That, however, is currently beyond the limitations of the windy plugin model, and would need a way to add user-contributed code to the windy server backend in a safe fashion. I understand things might be moving in this direction.

That said, let me stop the nit-picking: compared to the rest of the crowd, is a phenomenal step forward by making a weather application user-extensible and hence adapted to specific needs!

To round it off, a take-home by Taleb:

Looking up SIGMET’s

Update: the windy-plugin-sigmets function has been discontinued and the author has vanished the github repository mentioned below.

A SIGMET is a useful weather safety advisory. However, when those are buried in a bland website, few people have a look. Here’s an example as to how NOT present information, from our friendly Austrocontrol briefing website (login required):

Can one do better? Yes they can – “they” being the prolific folks writing plugins for the superb Windy platform, this time windy-plugin-sigmets:

windy-plugin-sigmets in action

This is not yet in the list of official plugins, so to activate, one needs to click the ‘Hamburger menu’ (left top) -> ‘Install windy plugin’ -> ‘Load plugin directly from npm’ and enter ‘windy-plugin-sigmets’ like so:

For the curious: the source code is here.

I learned about this plugin through Twitter:

While we are talking SIGMETs – here’s an alternative source for SIGMETs-on-a-map:

And once I am dictator for lifetime, every web designer will be required to read and understand this book . There, I said it! trajectories on mobile and pad

So far I thought the windy trajectory function only works on desktop browsers, and not on mobiles or pads. Well – I stand corrected thanks to a post in the Windy community forum by the prolific Jakub Vr√°na.

To do so, open in a browser on your mobile/pad, and choose the trajectory plugin like on the desktop (just ignore the ‘Download App’ button!). Things work mostly like on the desktop – here’s proof from an iPhone using Safari:

And here Chrome on Android:

However, the Route Planner function currently does not work on mobile. Other than that – almost like on the desktop!

Trajectory forecast vs track flown: a new data point

I’m always interested in comparing forecast trajectories versus tracks flown – I posted some data points here.

Thanks to Kolja Packard’s excellent field report (in german and english) we have a new one – the first image in Kolja’s report shows their trajectory forecast done 22 hours before takeoff, and looking out 80 hours. This was their forecast:

now compare that to the actual tracks flown as recorded on the Gordon Bennet Cup website:

See also the live tracking replay view.

The match is pretty phenomenal!

Field report: Windy at the Gordon Bennet Cup

Kolja Packard was member of the ground support team for the Belgian, Spanish and US teams at the Gordon-Bennet-Cup 2019 – the most prestigious gas ballon race in the world. He used – among other tools – and in particular traj – the trajectory plugin – to aid pilots with weather information and tactical advice.

Kolja writes:

Experiences with the Windy Trajectory Plugin

Hello Michael,

find below a summary of the experiences and impression of the trajectory plugin for I used it in the – rather particular – setting of planning and supporting a long-distance (and long time!) race with gas balloons during this year’s Gordon Bennet race starting from Montb√©liard.

Usually with gas balloon rides a duration of 6-12 hours is of interest. But in competitions, flights lasting several days are possible. With this year’s Gordon Bennet Race – which is about maximum-distance-flown, due to the overall weather situation, flight times of up to 72 hours and much more were possible.

For the average – and much more common – hot air balloon pilots flights of around 1-3 hours in the morning and in the evening are more typical.

We looked into possible tracks while supporting three teams (BEL1, ESP1 and USA1) and those were quite long-lasting flights. Our strategy – and therefore the search for relevant information – looked at 80 hours onward from the start even before takeoff!

By using windy’s traj plugin, we gained the following advantages:

1. trajectories based on additional weather models – only windy could provide data for ECMWF and IconEU beyond the GFS-based HYSPLIT and the GFS-derived NEMS model by Meteoblue

2. it was straightforward to model long duration trajectories with changing altitudes and represent those in a single screen view

ad 1) especially during diverging forecasts there is value in having data from different models at hand, so as to get at least a rough tendency of weather development

ad 2) example below: multilevel trajectory produced 22 hours before takeoff (actually this are 4 partial trajectories following each other with different altitudes assembled into a single view):

Detail view of how partial trajectories are assembled:

See below for details on tagging and coloring trajectories, for instance by model

For developing such a “multi-level trajectory”, you start with a single parameter set (height, model etc) and just start another trajectory at a certain point with a different set of parameters.

One can add aribtrary trajectories at arbitrary points of an underlying trajectory so as to estimate the impact of altitude changes at different points into the flight given a location, and develop a strategy based on the result.

Using all available models, views become confusing quickly. Here we show a forecast based on a single model while varying the altitude. Takeoff locations and times are subject to pilot’s discretion – and mistakes.
Three models displayed simulataneously.

I did not use the ascent/descent simulation provided by the traj plugin – trajectories at a given altitude for extended periods of time were more relevant to us.

Further into the race, we were faced with short-term decisions beyond the long-range planning. Here some features of the traj plugin proved useful.

For instance, for short-term forecasts the age of a forecast is relevant – it makes a difference if it is a new iteration or several hours old.

There was no clear “winner” in terms of models as for accuracy – generally the ECMWF model provides reasonable results, on short-term IconEU also got some best suiting forcasts to actual conditions.

Adding airspace information to trajectory tracks is very helpful (even if available as a separate windy plugin).

Here the goal was to steer the BEL1 team around, or within the airspaces encountered, only at certain altitudes. The blue trajectories correspond to an hour of flight at current altitude, based on three models. Thereafter, a simulation at different altitudes based upon the – then – most current model.

The following features proved useful:

– the resulting trajectories can be overlaid with all data provided by windy. By clicking on a point in a trajectory, forecast time is automatically adjusted, as is the altitude. That makes it straightforward to estimate conditions at a certain point into the flight.

– map display in windy is very flexible, for instance scaling and import of non-standard geodata.

– exporting trajectory data from the plugin is very useful.

During intense use of traj, I’ve encountered some restrictions and issues, and I have some suggestions for further development.

I encountered two issues during 5 days of use – which I generally would rate as “explainable”:

1. Looking ahead over 40 hours, I ran into a problem with IconEU – forecasts got stuck some 3 days into the future – the site got stuck and required a restart in a new browser window.

This did not occur with other models, and also did not reoccur during later phases of the flight when we only looked at shorter time spans.

2. On and off the trajectory computation appears delayed as – according to a message on-screen – there was no connection to the server. Certainly this is attributable to our makeshift Internet hookup for our “Control Center”. Nice to see that the job did not fail but rather eventually continue once network connectivity was reestablished. And this is only was an issue because it took quite some time to compute the trajectories – more below.

The only real downside to the traj plugin – and then only compared to some commercial alternatives and when computing long-lasting flights, and therefore not neccessarily felt by many users is its low speed of computation.

In particular, when using multiple models over an extended period of time, the job might take 10 minutes or more. But if I understand it right, the traj plugin just queries wind info on the current location and time from windy and trajectory computation happens locally, not on the server.

Given 3 models, maybe 3-4 altitude levels and – for example -40 hours lookahead, that’s 480 data snapshots taken by the client, and that takes its time. And I had to forecast 80 hours in different variants… For a free service, that is something one can live with – especially since most users are likely interested in much shorter forecast timespans.

Here is some feedback on usability and suggestions for further development based on my experience gained during this race:

1. Setting the starting time of a trajectory happens in local time. We used UTC throughout also with other tools, and that is asking for mistakes (by the user). Also because we were busy around the clock and have produced countless trajectories. To avoid simple mistakes it would have proven useful to see or adjust trajectory starting time in UTC in the settings menu (given a completed trajectory, UTC times can be had by clicking on points of the curve).

2. The capability to simulate many trajectories (different altitudes, times, models, locations) and have them displayed in the same screen is a major advantage of the traj plugin. One can work out an optimal path pretty well (best takeoff time and location, altitude, change of altitude etc). Along the way you’d compute quite a few trajectories, most of which you’d throw away. Others you will like to keep. It’d be super useful to selectively discard trajectories without erasing them all. I have not discovered such a function.

3. Clicking on a point in a trajectory displays information on the computaion settings of the trajectory and the chosen point. This also selects the windy current time and location for a following trajectory calculation-very useful!

A suggestion: total trajectory duration is displayed in minutes (e.g. 2400 minutes in our case) other than in hours:minutes as selected in the Settings display. Display in hh:mm format would be more useful.

4. When calculating three altitudes with three models, this will result in 9 trajectories displayed – this becomes confusing pretty quickly. Two suggestions:

4.a) trajectories of identical altitudes by different models have the same color. Marking trajectories additionaly by model would be very useful. Now, only when clicking the curve you see the underlying information.

4.b) For better representation I chose higher-contrast colors than default. That is currently only possible by pressure altitude which is somewhat cumbersome. Adding altitudes in meters/feet would be a plus:

5. Not sure if it is possible to read out the last update time for a given model in windy with a plugin. But it would be super useful to display this to rate its relative value. One can find that information, but it takes several clicks and not in direct comparison of the trhee models. It would be great to see this for instance in the Settings menu where you select models.

Wrapping up: I certainly did not use all features of windy or the traj plugin for that matter, since I encountered this only recently (and through your blog, by the way). But then in the days before and during the race I guess I used it for 12 hours a day and I am very impressed by its potential!

ps: as I was writing this up, I tried to access the plugin. But it seems it is currently unavailable, as are other plugins. Never happened before!

Attached below find some recordings – I hope you find it useful!

best regards


Erfahrungsbericht: Einsatz von Windy beim Gordon-Bennet-Cup

Kolja Packard war im Rahmen des Gordon-Bennet-Cup 2019 beim Bodenteam f√ľr Mannschaften aus Belgien, Spanien und USA. Er hat – und insbesonders traj, das Trajectory-Plugin – verwendet, um die Piloten taktisch zu unterst√ľtzen. Kolja schreibt mir:

Eindr√ľcke zum TrajektorienPlugin f√ľr Windy

Hallo Michael,

im Folgenden findest du eine Zusammenfassung √ľber meine Erfahrungen und Eindr√ľcke zum Trajektorien-Plugin f√ľr, die ich im ganz speziellen Anwendungsfall f√ľr die Planung und Betreuung von Langzeit- bzw. Distanzfahrten von Gasballonen im Rahmen des diesj√§hrigen Gordon Bennett Rennens in Montb√©liard machen konnte.

F√ľr eine gew√∂hnliche Gasballonfahrt sind Fahrtzeiten von 6 – 12 Stunden von Interesse. Im speziellen Falle von Leistungs- oder Wettbewerbsfahren sind auch Fahrtzeiten von mehreren Tagen m√∂glich. Im ganz speziellen Falle des diesj√§hrigen Gordon Bennett Rennens (eigentlich ja √ľber die maximale Distanz, was aber nat√ľrlich auch eine lange Fahrzeit impliziert) kam es bedingt durch die Wetterlage zu Fahrten von deutlich √ľber 72 Stunden, sogar bis zu 90 Stunden.

Ich gehe davon aus, dass bei der zahlenm√§√üig weit st√§rker vertretenen Fraktion der Hei√üluftball√∂ner eher kurze Fahrten im Bereich 1-3 Stunden in einem definierten Zeitfenster in der Fr√ľh oder am Abend interessant sind.

Die m√∂glichen Fahrtverl√§ufe, die uns bei der Unterst√ľtzung dreier Teams (BEL1, ESP1 und USA1) bei diesem Rennen interessierten, waren also von betr√§chtlicher Dauer und unsere Strategie und somit die gesuchten Informationen beliefen sich schon vor dem Start auf √ľber 80 Stunden!

Bei diesen zeitlich weiträumigen Strategieentwicklungen vor dem Start waren bereits zwei deutliche Informations- Hinzugewinne durch das Plugin ersichtlich:

1. Trajektorien basierend auf zusätzliche Wettermodellen möglich (NEMS mit Meteoblue, GFS mit windy+plugin und HYSPLIT und zusätzlich ECMWF und IconEU ausschließlich mit windy+plugin)

2. Strategien mit wechselnden Fahrthöhen waren ohne größeren Aufwand zu berechnen und auch direkt zusammen darstellbar

Zu 1.: Wie auch sonst, wenn man bei nicht eindeutigen Vorhersagelagen gerne mehrere Modelle zu Rate zieht, um zumindest √ľber die grobe Tendenz einer Entwicklung eine zuverl√§ssigere Auskunft zu erhalten, war es auch bei der Trajektorienberechnung ein Gewinn weitere Wettermodelle zu Rate ziehen zu k√∂nnen.

Zu 2.: Hier ein Beispiel zu Multilevel-Trajektorie etwa 22 Stunden vor dem Start gerechnet (eigentlich 4 Teiltrajektorien mit unterschiedlichen H√∂hen direkt aneinander gef√ľgt):

Das Aneinanderf√ľgen von Trajektorien im Detail:

(Zur Farbgebung und Kennzeichnung der Trajekorien, z.B. nach zu Grunde liegendem Modell, Weiteres unten)

Beim Rechnen solcher ‚ÄúMultilevel-Strategien‚ÄĚ bzw. ‚ÄúMultilevel-Trajektoerien‚ÄĚ rechnet man einfach eine Trajektorie und f√ľgt danach eine weitere mit abweichenden Parametern an usw.

Dabei ist es sehr n√ľtzlich an einer vorhandenen Trajektorie eine Vielzahl neuer Trajektorien ansetzen zu k√∂nnen, und zwar nicht nur am Ende sondern an jedem beliebigen Punkt, und somit die Auswirkung von m√∂glichen H√∂hen√§nderungen zu jedem Zeitpunkt der Fahrt (am vorausberechneten Ort) absch√§tzen und somit eine m√∂gliche Strategie entwickeln zu k√∂nnen.

(Berechnet man alle drei Modelle, wird es schnell un√ľbersichtlich. Hier nur ein Modell genutzt mit verschiedenen H√∂hen. Farben kontrastreicher gew√§hlt. Ausgangspunkte und dazugeh√∂rige Startzeiten von Trajektorien sind ausschlie√ülich in der Kontrolle und somit auch Fehleranf√§lligkeit des Benutzers.)

(drei Modelle parallel berechnet)

Da es f√ľr unsere Vorausberechnungen von vielen Stunden nicht relevant war, habe ich die Funktion des Steigens/Fallens, die das Plugin ja schon mitbringt, nicht verwendet. Uns interessierte was in einer bestimmten H√∂he √ľber l√§ngere Zeit zu erwarten war.

Je weiter wir in das Rennen kamen und sich somit parallel zur l√§ngerfristigen Vorausplanen auch kurzfristige Fragestellungen ergaben, desto mehr zeigten sich noch weitere Funktionen des Plugins als n√ľtzlich.
F√ľr kurzfristige Vorhersagen kann es z.B. eine Rolle spielen, ob ein Wettermodell auf dessen Basis eine Trajektorie berechnet wird, schon viele Stunden alt ist oder eben k√ľrzlich neu zur Verf√ľgung gestellt wurde.  Die Genauigkeit der Vorhersagen der verschiedenen Modelle war im √úbrigen nicht eindeutig bei einem Modell gr√∂√üer. Tendentiell erschienen die Trajektorien mit dem ECMWF-Modell eine gute Vorhersage zu erzielen. Im Kurzfristigen Bereich war bei gr√∂√üerer Aktualit√§t das IconEU Modells auch mal n√§her an den eintretenden Verh√§ltnissen gelegen.

Im Verlauf der Langfahrt war das Einblenden der Luftr√§ume (im Plugin integriert, sonst auch √ľber separates Plugin m√∂glich) eine gro√üe Hilfe.

(Ziel: BEL1 am Luftraum vorbei, bzw. im Luftraum nur mit bestimmten H√∂hen, zu dirigieren. Die blauen Trajektorien entsprachen einer Stunde vom Berechnungszeitpunkt in der aktuellen Fahrth√∂he gerechnet mit drei Modellen. Als Kontrolle dazu andere H√∂hen. Danach m√∂gliche Optionen mit dem zu dem Zeitpunkt aktuellsten Wettermodell.) 

Folgende weitere Punkte sind positiv aufgefallen:
– Die Trajektorien k√∂nnen auf Windy mit allen von Windy zur Verf√ľgung gestellten Daten √ľberlagert dargestellt werden. Durch klicken auf einen Punkt der Trajektorie springt die Darstellung automatisch zu dem entsprechenden Zeitpunkt und, z.B. bei der Darstellung des Windes, auch in die entsprechende H√∂he. So ist sehr gut abzusch√§tzen, welche Verh√§ltnisse zu welchem Zeitpunkt der Fahrt herrschen.
РDie Handhabung der Kartendarstellung ist in Windy sehr komfortabel. Skalierbarkeit, Import anderer Geodaten,…
– Das Exportieren der Trajektorien direkt aus dem Plugin ist ebenfalls ein plus.

Nat√ľrlich habe ich durch die intensive Nutzung auch die ein oder andere Einschr√§nkung oder ein Problem erfahren und kann mir daher auch ganz konkrete Weiterentwicklungsm√∂glichkeiten vorstellen.

Zwei Probleme sind im Laufe der 5 Tage aufgetreten, die ich aber beide als ‚Äúerkl√§rbar‚ÄĚ einstufe.
1. Bei einer Berechnung von √ľber 40 Stunden hatte ich einmal das Problem mit dem Modell IconEU, dass eine Trajektorienberechnung immer am selben Zeitpunkt (etwa 3 Tage in der Zukunft) h√§ngen blieb und die Seite dadurch nicht mehr reagierte und ein neues Browserfenster gestartet werden musste. Mit den anderen Modellen tauchte das Problem nicht auf. Es ist ebenfalls zu einem sp√§teren Zeitpunkt nicht mehr aufgetaucht, als nur noch k√ľrzere Zeitspannen gerechnet wurden.
2. Das ein oder andere Mal war die Trajektorienberechnung verz√∂gert, da, laut windy-Bildschirmmeldung, keine Verbindung zum Server bestand. Dies ist aber mit Sicherheit dem Internetanschluss in unserem provisorischen ‚ÄúControlCenter‚ÄĚ geschuldet gewesen. Positiv war hier, dass das Plugin dadurch nicht in einen Fehler lief sondern die Berechnung dann weiterf√ľhrte, wenn die Verbindung wieder m√∂glich war. Zu diesem Effekt kam es aber nat√ľrlich auch erst dadurch, dass das Berechnen der Trajektorien verh√§ltnism√§√üig lang dauerte. N√§heres dazu im Folgenden.

Der einzige f√ľr den Nutzer negative Punkt in der Nutzung des Plugins – und dies aber auch nur im Vergleich zu anderen teils kostenpflichtigen Angeboten und speziell bei Berechnungen von Trajektorien sehr langer Zeitdauer – ist die verh√§ltnism√§√üig langsame Berechnung der Trajektorien.
Zur Berechnung von Trajektorien, vor allem mit mehreren Modellen gleichzeitig, um auch den Vergleich zu haben, und √ľber eine l√§ngere Zeitdauer, ben√∂tigt  man dann schon mal 10 Minuten und mehr. Dies aber ebenso nachvollziehbar, da ich annehme, dass das Plugin einfach die jeweiligen Vorhersagezust√§nde abruft, um die Trajektorie zu errechnen und die Berechnung ja nicht auf dem Server geschieht. Bei 3 Modellen, mit 3-4 H√∂henleveln und z.B. 40 Stunden Dauer sind das dann ganz schnell mal 480 Istaufnahmen, die in Windy aufgerufen werden! Dies kommt nat√ľrlich vor allem beim Rechnen von langen Zeitdauern zum tragen. Und f√ľr die ganze Strategie musste ich 80 Stunden mit verschiedensten Varianten berechnen‚Ķ
F√ľr ein Gratistool aber immer noch ein verschmerzbarer Nachteil, der f√ľr die meisten Nutzer, die viel k√ľrzerer Trajektorien interessieren d√ľrfte, nicht so erheblich sein wird.

Im folgenden noch ein paar Feedbackpunkte √ľber Fehleranf√§lligkeit (in der Benutzung) und Anregungen zu m√∂glichen Weiterentwicklungen auf Grund der erfahrenen Einschr√§nkungen:
1. Das Einstellen der Startzeit einer Trajektorie geschieht durch den Zeitregler in Windy. Diese Zeit ist ‚Äúlocal‚ÄĚ. Da wir generell und auch mit anderen Tools mit UTC gearbeitet haben, gab es hier immer potential sich zu vertun. Wir waren nat√ľrlich rund um die Uhr damit besch√§ftigt und haben unz√§hlige Trajektorien gerechnet. Zum vermeiden einfacher Fehler w√§re es aber n√ľtzlich gewesen, wenn die Startzeit der Trajektorie in UTC zumindest im Settings-Men√ľ ersichtlich oder sogar einstellbar w√§re. (Bei der fertigen Trajektorie l√§sst sich der Zeitpunkt dann einfach in UTC ablesen durch anklicken der Trajektorie).
2. Der Vorteil dieses Plugins liegt vor allem darin, dass man viele Trajektorien (unterschiedliche H√∂hen, Modelle, Startzeiten, Startorte) nacheinander berechnen und in der gleichen Oberfl√§che anzeigen lassen kann. So kann man ein gew√ľnschtes Ergebnis sehr gut herausarbeiten (bester Startzeitpunkt oder -ort, Fahrth√∂he, Fahrth√∂henwechsel‚Ķ). Auf dem Weg dahin berechnet man in der Regel einiges an Trajektorien, die man gerne wieder verwerfen m√∂chte, andere wiederum unbedingt behalten. Den gr√∂√üten Zusatznutzen h√§tte ich darin empfunden, wenn man einzelne Trajektorien wieder l√∂schen k√∂nnte ohne alles zu l√∂schen. Eine solche Funkion habe ich zumindest nicht gefunden.
3. W√§hlt man einen Punkt auf einer Trajektorie aus, bekommt man Informationen zur Berechnung der Trajektorie und Zeitpunkt des Punktes angezeigt. Au√üerdem kann man den gew√§hlten Punkt auf der Trajektorie direkt als Ausgangspunkt f√ľr weitere Berechnungen nutzen. Sehr n√ľtzlich! Kleine Verbesserung der Nutzbarkeit: Die Gesamtdauer der Trajektorie wird hier in Minuten angezeigt, also z.B. 2400 Minuten, statt in Stunden:Minuten, wie man sie vorher auch in ‚ÄúSettings‚ÄĚ ausgew√§hlt hat. Die Darstellung in hh:mm w√§re praktischer.
4. Berechnet man z.B. drei verschiedene H√∂hen mit allen drei Modellen erh√§lt man 9 Trajektorien. Da wird es schnell un√ľbersichtlich. Hierzu zwei Anregungen:
4.a) Da die Trajektorien einer gleichen H√∂he verschiedener Modelle immer die gleiche Farbe haben w√§re eine zus√§tzliche Kenntlichmachung der Trajektorie nach zu Grunde liegendem Modell n√ľtzlich. (Wird die Trajektorie angeklickt, erh√§lt man die Information dieser einen Trajektorie. Das ist aber wenig praktikabel.)

4.b) Zur besseren Unterscheidung der verschiedenen H√∂hen habe ich jeweils kontrastreichere Farben als die Vorauswahl gew√§hlt. Dies ist nur nach Druckh√∂hen im Bereich ‚Äúsettings->colours‚ÄĚ m√∂glich, was es etwas umst√§ndlich gemacht hat. Nach H√∂hen in Metern w√§re ebenfalls w√ľnschenswert. Evtl. w√§re direkt bei der Auswahl der ‚Äúlevels‚ÄĚ die Farbauswahl praktisch.

5. Ich wei√ü nicht, ob es einen Weg gibt die letzte Aktualisierung eines Wettermodells aus Windy herauszulesen und mit einem  Plugin anzuzeigen. Das Wissen um den letzten Aktualisierungsstand ist zumindest sehr hilfreich um den Wert eines genutzten Modells im Vergleich zu einem anderen genauer einzusch√§tzen. In Windy l√§sst sich die Info herausfinden, nur eben mit mehreren Klicks verbunden und nicht in direkter Gegen√ľberstellung. Eine solche Info z.B. dort, wo man die Modelle ausw√§hlt in ‚ÄúSettings‚ÄĚ w√§re grandios.

Abschlie√üend sei zu bemerken, dass ich bei Weitem nicht alle M√∂glichkeiten von Windy und in dem Zusammenhang auch von dem Plugin einsetzen konnte, weil ich erst sehr kurz vor dem Rennen mit dem Trajektorienplugin (√ľbrigens √ľber deinen Blog) in Ber√ľhrung gekommen bin. In den Tagen vor und w√§hrend dem Rennen habe ich mich aber wohl gesch√§tzte 12 Stunden am Tag damit auseinander gesetzt und bin von dem Potential mehr als beeindruckt!

P.S.: Übrigens, als ich diese Zeilen schrieb wollte ich noch mal auf das Plugin zugreifen. Es war bei Windy aber nicht mehr möglich ein Plugin auszuwählen. Dies kam aber bisher noch nie vor.

Im Anhang noch ein paar ‚ÄúAufzeichnungen‚ÄĚ etc. falls von Nutzen.

Liebe Gr√ľ√üe,


Windy trajectory functions improved

Chris, the author of the traj plugin, has released a new version (0.5.1) with new functions – it is easier to use and more powerful! Also, a few days ago, windy updated the web version of their product and made it much simpler to work with plugins. So let’s have a look:

When you now click on the “Hamburger menu” (three horizontal bars, left top) and then “Install Windy plugin”, you see a gallery of approved plugins with an example screenshot, description with a link to more detail – scroll down to “Trajectory”, click “Open” and you are done!

Starting plugins in windy has become much easier

The traj plugin is now structured into a large parameter pane on the left, and a small operations menu center bottom – first, set all your params in the left pane, then run the operation from the operations menu.

Any parameters you set will be recorded and come up as before when you run again.

Example: parameters for a typical 2-hour summer season balloon ride

  • “Select levels” – select all from 100m to 1500m
  • “Select models” – ecmwf, gfs, iconEu (all are done in one go now – no more clicking “Start”, wait, change forecaste model, iterate!)
  • “Settings” – ascent/descent: 0 m/s, duration 2:00, everything else default
  • “Airspaces” – optional. Expand the menu; in my case, I click “Austria”; in case your screen gets overly cluttered, you can remove that airspace by clicking the small white-cross-on-red button besides the country name.

Thereafter, you do not need the parameter pane any more- click it away with the white-cross-on-red button on the top to get more screen space.

Next, select a start time by shifting the time selector at the bottom to your desired start time.

Finally, select a location. I use favourites – click on the heart icon in the operations menu, and select a location. Click the heart icon again to close the location dropdown. This will set the “location picker” – if there’s a message on screen saying “Place Picker”, repeat that process – it’s very easy to accidentally deselect the location picker.

Good to go! Click “Start” in the operations menu. That button changes to “Stop” while the process is running, and changes back to “Start” when done – wait for it. You will wind up with a screen roughly looking like so:

Trajectory generation finished

The black bullets along a track correspond to the “Marker intervals” setting in the parameter pane – I leave those as default, 1 hour.

Interpreting the results

Click on a track – a two-part panel will pop up telling you more detail about this particular track at this point:

Forecast detail when clicking on a track

The left panel states the forecast model, and the time when the model was last updated.

The right panel shows wind speed, wind direction, time, altitude and ground elevation – so at the point we’d be roughly 700m above ground.

Note the “Route Planner” button – we’ll cover that in the next section (this function only works with tracks generated by the ECMWF model).

Usually tracks vary substantially at low levels, whereas in the free atmosphere tracks tend to converge quite closely. That degree of divergence between models for a given altitude also gives you a hint as to the likelihood of an actual flight matching the forecast. Several models agree: likely that is where you’re actually going.

I tend to believe the ECMWF forecasts most, with ICONEU a close second. But that is gut feeling and not science.

If you want to save those forecasts, click “Save” in the operations menu. The resulting file will be in GPX format and can be published for other people to see like so.

Drilling down: displaying a cross section

Click on an ECMWF forecast track, then click on the “Route Planner” button. This will split the screen vertically and the atmosphere cross section along this track comes up in the bottom half:

Atmosphere cross section along forecast track

This is really handy for a quick look on conditions en route. Look here for more information on the Route planner. This only works with ECMWF-generated tracks – not for GFS or ICONEU.

Update: Route Planner just was improved (Airgram and IFR view added) and that update also shows if Route Planner is activated via the traj.

Big Fat Warning: See the “Directions north up” dropdown near the bottom of the last screenshot? There are two more options which are seriously confusing with respect to wind barbs: “from left to right” and “from bottom to top”.

You want to set this dropdown to “north up” or the wind barbs will be relative to your course(!!). That possibly makes sense for airplanes but not for balloon rides.

For an explanation, see the section “How to choose your direction on the map”.

I wrote a note on Route Planner.

Animating a GPS track

So you had a great flight. You unload your GPS and now have a GPX file. How do you share the experience with others?

Well, draw it on a map like so:

Boring display of a great flight

Pretty bland, if you ask me – “yes, we’ve been here and there too”. in Flatlandia, that is. The dynamics of the flight experience, great views – gone.

You could generate a KML file and tell folks to view it in Google Earth. Works, if they have Earth installed – which translates into “almost nobody”. With an advanced degree in Earth, you can even create an animation video. But that takes time and lots of moving files around.

What I’m looking for is – send out a link, and everybody with a browser at hand could re-live the flight, drag, pan, and zoom around like so:

and.. also be able to embed this on a web page.

Do-it-yourself like so:

  • create a free account on
  • upload your GPX file
  • click the “3D” icon and the Play button

That’s it!

Another option:

Turns out there are several sites which provide similar services. also sports free accounts, with the option to upload GPX files. Other than ayvri optionally displays current flight data (speed, altitude, climb/sink rate, distance, time) – very nice!

Click the image below to run the actual animation on

Flight animation with

Pretty much the same drill as above:

  • create a free account on
  • upload a GPX file and describe the flight
  • click “Create Scene”
  • click the “Stats” dropdown (right top) for flight data
  • view the animation
  • record its URL for sharing.

While rikitraki seems to be more of a single-programmer hobby project, ayvri looks more professional and polished, with a company, free/paid options, an API and a Twitter & Facebook presence behind it.