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

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!

@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

have you considered turning off notifications for a start?

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

I'm just starting to play with https://chat.openai.com/chat and got curious on how strong it's meteo fu is

executive summary: not Nobel grade, but interesting starting points.

here's an example dialog:

Question: how can I determine the likelihood of hail by studying a radiosonde ascent?

Answer: A radiosonde ascent is a type of weather balloon that is equipped with meteorological instruments to measure various atmospheric parameters such as temperature, pressure, humidity, wind speed, and direction as it ascends through the atmosphere. The data collected by the radiosonde can be used to determine the likelihood of hail by examining the vertical profile of temperature and humidity.

Hail typically forms in strong thunderstorms where there is a high degree of instability in the atmosphere. The likelihood of hail formation is increased if there are strong updrafts, which can carry water droplets to higher altitudes where they freeze and become hailstones. The presence of moisture and cold temperatures at high altitudes is also important for hail formation.

To determine the likelihood of hail using a radiosonde ascent, you can examine the temperature and humidity profiles to identify areas of instability and moisture at different altitudes. Look for a sharp decrease in temperature with increasing altitude, known as a temperature inversion, as this can indicate the presence of cold air at higher altitudes that is favorable for hail formation. Also, look for high levels of moisture in the atmosphere, which can indicate the presence of strong updrafts that are capable of lifting water droplets to high altitudes where they can freeze.

Additionally, you can examine other parameters such as wind speed and direction to identify areas of convergence and divergence, which can also be important for hail formation. Regions of convergence can lead to the upward movement of air, which can increase the likelihood of hail formation.

However, it is important to note that determining the likelihood of hail using a radiosonde ascent is just one piece of information that meteorologists use to make weather forecasts. Other factors such as surface conditions, local topography, and atmospheric dynamics also play important roles in determining the likelihood of hail formation.

@Ondřej-Šutera there's some nice hodograph code in MeteoJS:

https://chird.github.io/meteoJS/examples/thermodynamicdiagram-hodograph.html

license: Apache License 2.0

@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