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

(90 min)

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?



@alknet

Have a look at this SvelteKit app: https://github.com/ISmillex/adsb-flight-map.git - worked on first try for me, maybe a base for you

This renders in 3D using Cesium and not 2D/Leaflet but the fetch/decode/display logic should apply

it cleverly uses several open sources of ADS-B data

@Lukas-Cesna works again on desktop, both standard and leafGL versions - not mobile yet

I'm not aware of any Meteo app which actually uses the ADS-B wind speed and wind direction data as a source of measurement, if you will.

It would certainly be interesting to compare those vectors to forecast vectors at the flight's altitude - it would give some confidence to the likelihood of a forecast being close to reality.

That said, I have no bearing on the reliability of these reported vectors. Maybe some pilots could comment?

This is what Grok has to say on the issue: https://grok.com/share/bGVnYWN5_3d13d62e-fb05-4320-8037-6ac4a98fec86

@Lukas-Cesna confirmed - standard version

@Gkikas-LGPZ No, I was referring to standard ADS-B messages like the ones in https://airplanes.live

they use the same decoding software readsb like most other ADS feeding service (adsbexchange, fr24, flightaware etc) so the fields are pretty much standard.

Some of the data fields like wd and ws might be nteresting: https://airplanes.live/rest-api-adsb-data-field-descriptions/

Airplanes.live is one of several community-based sources, like https://adsb.fi and https://www.adsb.lol

OpenSky might be a feed alternative, but they discourage live tracking and seem more research-oriented: https://openskynetwork.github.io/opensky-api/

If I were to integrate ADS-B into Windy core, I would go for an arrangement with ADSBexchange.

Michael

@taarnby https://airplanes.live/api-guide/ would be a starting point.

The trajectory plugin is used around 20 times a day, and that is just from users which consent to usage tracking. Mobile traj being on the way now.

The webgl testing release broke it AGAIN.

How many iterations of this experience will we have to go through?

Can I recommend one of the two following options, either is fine with me and both together would be best:

• invest effort into automated regression testing for plugins - at least for the top used ones - to prevent a - unfortunately by now standard - thermonuclear outcome

• take plugin usage as an indicator for what users actually want, and integrate the winners into the core functionality.

I - and not just me - would really appreciate if that particular issue could be resolved in a stable manner.

Webgl is nice and leaflet 1.4 might warrant a brushup. That said, I encourage to reconsider feature priorities.

If anything, do not disband the plugin capability - it is the best user needs indicator you've got.

thanks in advance

Michael

@Suty confirmed fixed

The radiosonde view has a full-screen button right bottom (red circle) for presentation/discussion purposes:

This used to work fine, it is currently broken - the radiosonde view is not widened left full screen anymore, and the ascent view becomes useless:

The bug is broweser-independent

Michael

@Jari-Sochorová same goes for the Compare button

took a while to figure it was moved to the model panel