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

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?

@ivo delighted!

I already primed all my ballooning fellows on this - ICON-D2 is the best model for us in central Europe for flight forecasts

and my farmer neighbours.. I taught some of them to use windy and they are getting pretty good at bringing home the hey before the rain sets in;)

• Michael

@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

@Fitzy-1 this has come up in various shape or form several times, for AIS, ADS-B, and other location-and-whatnot reporting data sources

then some half-assed effort is expended on datasource X, plugin published, victory declared and the whole thing rots away

this scheme just does not fly - however, there seems to be a legit demand for displaying nonstandard stuff on maps

my recommendation would be - split the problem into two:

a) a generic "here's a plugin which can display various stuff on a windy Leaflet map" part
b) a per-use-case "transform my data into the format the former can display it"

there is a superb example in the node-red ecosystem for a): https://flows.nodered.org/node/node-red-contrib-web-worldmap and I suggest to give it a try

• you display "stuff" on the map by sending a JSON message with coordinates, and attributes what and how to display it

• you "move" stuff on the map by sending that message with new coordinates

that is pretty much it - see the usage section: colors, icons, popups, speed/heading vectors, links, images, send GeoJSON, KML etc and what not

now node-red has an internal mechanism for message passing between nodes and that needs to be replaced by some generic vehicle - for that I'd use a Websockets listener/connector, passive/active HTTP or just passive/active TCP.

Step1: transplant the inbound message handling mechanism into a windy plugin.
Step2: recreate the outbound "Events from the map" so an external data source can react to click, pan, move, delete, file drop.

Then, to integrated your AIS or some other data source you only have to transform the data into the format expected by the map interpreter. And it could be pretty much any language one is familiar with - node, python, whatever.

I've used node-red-contrib-web-worldmap - it's well supported, stable and very popular. The core code is some 3000 lines and well written.

@rittels

what is the status on Icon and Icon-D2 in the Point Forecast API ?

Michael

@yorikthree years later: same problem here

@dodohjk Michael here, I developed and operate the data backend behind the radiosonde plugin

there was an issue with my backend during July which went unnoticed for a while. I have now since fixed it and the data should be current.

@mtrunz anybody can verify independently this works?

hangs during "loading directly from npm" for me

@korina no, none I could discern of

I'm happy to do a shared skype screen if deemed useful

Michael

@korina

no errors displayed

graphic compatibility mode on/off has no effect

I also reset any flags in chrome://flags - no change

NB I am running a beta version of MacOS (Monterey 12.5 Beta (21G5027d))

anybody with an Apple M1 around who can try to reproduce?

Michael

@korina I checked with all my platforms, and it turns out that this error ONLY shows on Chrome/MacOS arm64 - I have this versions:

• Chrome Version 104.0.5083.0 (Offizieller Build) dev (arm64)
• MacOS 12.5 beta arm64

All the following combinations work as you described:

MacOS 12.5 beta arm64

• Safari Version 15.5 (17613.3.1.1.2)
• Firefox 101.0 (64-Bit)
• Brave: Version 1.39.111 Chromium: 102.0.5005.61 (Offizieller Build) (arm64)

Windows 10:

• Chrome Version 102.0.5005.63 (Official Build) (64-bit)
• Firefox 101.0 (64-Bit)
• Microsoft Edge
  Version 102.0.1245.30 (Official build) (64-bit)

iOS/Chrome
Android/Chrome

MacOS Big Sur x86 11.6.4 (20G417)

• Chrome Version 102.0.4972.0 (Offizieller Build) dev (x86_64)

so I think I hit bleeding edge issues with the Apple M1/Chrome combo

let's disregard for now, will have an eye on it and report if things improve

happy to do/forward console debugging if anyone is interested

Michael

this is a section of the airports POI layer, iphone app, v35.3.4:

here in the web site, same version, Chrome/MacOS:

the challenge: in the second screenshot, find the airports displayed clearly in the first screenshot

bonus credits given for finding Aviano Air base, Treviso, Istrana, Portoroz, Montfalcone (LIPA LIPH LIPS LJPZ LIPQ) ;)

one needs to hover directly over the airport which raises the popup

My suggestion would be to revert to the constant-size ring display as before or fix the icon (enlarge and color by VFR/IFR status)

what is the algorithm for displaying a ring versus an aircraft icon?

the first screenshot at least displays the airports well, but in the case of Udine I do not understand what the extra aircraft icon is meant to convey

what would make sense (provided the underlying data supports this): distinguish civilian and military airports visually

Michael

@kekert is it just my gut feeling that there are more WMO stations being displayed now in general, not just Germany?