Category: meteo

Chris (of windy traj plugin fame) could not join my team for the Sagrantino Cup balloon event due to the pandemic. But he used the time to improve traj – and it has improved a lot!

Speedup

Previously, generating trajectories for many altitudes and several models could take quite a while – since every calculated point would need an interaction with the windy server backend. Chris changed this so the relevant data tiles are downloaded once into the browser and all path calculation happens locally in the browser. Now it’s as fast as Meteoblue!

Sharing trajectories

“Look, tomorrow looks flyable!” – a common message, and then.. attach what? a screenshot? a GPX or KML track? What I did so far is: download the trajectories as GPX tracks, then massage them with gpsvisualizer.com, download the resulting HTML file, upload that file to my server, and share a link to that file – for example, like so. That’s quite tedious, and precludes the recipient from running traj with the original parameters but later (for updated forecast values) or different parameters/models.

Chris has now added this capability and it has turned out super useful. Before trying yourself, read the restrictions:

• this only works with a real browser – to make it work on a mobile or pad, you need to copy the link, and paste it into a browser
• once you open the link, you’ll see a popup – acknowledge it by clicking ‘Open’:

With that said: give it a try here. This is what’s going to happen:

So what has happened here?

• You saw the popup pane on the left side, and me clicking ‘Open’ to proceed.
• The traj plugin came up, with parameters pre-set, like location, models, altitude, duration and so forth. And starting time – more on that later.
• The trajectory computation automatically started and the window centered and zoomed such that all tracks are visible – all I had to is pan out a bit so the detailed map is hidden. Done!

Let’s dissect the link above and look under the hood:

https://www.windy.com/plugins/windy-plugin-traj?time=1T04:00&lat=48.439&lon=15.674&models=iconEu&levels=surface,100m,975h,950h,925h,900h,850h,800h&duration=120&ascent=0&descent=0&sample=5&sampleAscDes=1&start=true?5,m:eXFagAz

The first part of the link (https://www.windy.com/plugins/windy-plugin-traj) up to the first question mark calls the windy website and tells it to open the traj plugin. That part causes the popup you saw in the image and video above.

The rest of the URL consist of normal parameters of the style key=value and separated by ‘&‘. Most of them will be self-explanatory – like lat, lon, models, levels, duration and so forth – the start=true parameter causes immediate calculation of the tracks as soon as the plugin is loaded. It’s equivalent to clicking the ‘Start’ button in the small traj menu box.

The time parameter is always interpreted as UTC (Zulu time) and can be one of two flavors:

• an absolute date and time like time=2020-08-13T04:00– August 13, 2020, 04:00 UTC
• a relative date and time like time=1T04:00 meaning tomorrow 04:00 UTC (for today use ‘0T<time>’, for day after tomorrow use ‘2T<time> etc)

I’ll write up a detailed parameter description eventually but I’ll let things settle down a but first – all this is rather fresh code. Note that the parameters from the URL are shown in the initial popup.

Why use relative time?

Well, the nice part of a relative-time URL is: it never changes – tomorrow always means ‘tomorrow’, but 2020-08-14T04:00 means ‘tomorrow’ only today as I am writing this. So you can paste a link for ‘tomorrow morning trajectories’ or ‘tomorrow trajectories’ in a website. And: you can bookmark them and name them.

So next time you want to know if tomorrow is flyable: click on the ‘tomorrow morning’ bookmark which has all your favourite settings, and you’re done!

And since this weekend a balloon event is coming up: here’s an example for time-relative links for Gneixendorf, Austria.

Today several balloonists “went across” – for a long distance flight over the Alps.

Here is one track flown compared to the forecast I did with windy traj with the ECMWF and iconEU models. Note that takeoff was at 0600Z but the forecast was for 0700Z. Most of the flight was around 2800m altitude, so the 3000m/700hPa tracks are the closest match (you can disable the irrelevant altitudes by clicking them away in the top right box).

The track is mostly right between the ECMWF and iconEU forecasts. Also, note the accuracy of speed forecasted – click on some track points and the rings of the forecasts to see the values (click here for full-screen display):

Here’s a shot from the above ride:

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:

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:

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 meteoblue.com, 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 windy.com – 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, windy.com 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: