+1, HRDPS would be very desirable in complex coastal areas, such as those on the west coast of Canada with its many fjords and islands. Even in the Northern Puget Sound area (San Juans, Bellingham) in my experience HRDPS delivers the most accurate surface wind predictions. It seems to have an especially good accounting for local thermal effects, which often have a major impact on local winds in the summer around here.

This is the UI I currently use for HRDPS: http://canadarasp.com/RASP.html?param=sfcwind1,opacity=50,zoom=8,lat=49.19338120891148,lon=-125.31684978125907,model=hrdps,twodaydynamic=false,windgrams=false,wind_checkbox=true

Interestingly, this screenshot demonstrates that "just" freezing the animation & showing particles with their trails in static positions could be sufficient to address the performance concern, without losing the directional indication & without introducing a different visual paradigm.

I personally would use that mode to avoid my laptop fan spinning up every time I open a windy tab.

@vicb, thanks for porting the better sounding plugin! I can confirm that it works after going through the new "install" step, and then entering the plugin via the menu. On mobile, I had a hard time finding the plugin list / install workflow, and resorted to manually opening https://www.windy.com/plugins (no more trailing slash).

One thing I noticed is that plugins now seem to have proper URLs, so it could be possible to bookmark and share a full windy view using a plugin. This is excellent for power users. Hopefully, this will also enable us to share a plugin view with others, with a sensible install workflow when the plugin is not installed in that particular browser yet. Currently, when opening a URL like https://www.windy.com/plugin/sdg/48.612/-122.425?clouds,48.612,-122.425,10, I am getting high CPU usage and not much progress. This is in Firefox 122 on Linux, and Firefox 124 on Android. A profile on desktop looks like this:

I would like to add a plug for HRDPS, a high resolution model similar to HRRR but for Canada. The model is freely available from Environment Canada, and it is popular with kiters and paragliding pilots in the N of the US and Canada, mainly through the graphical view at http://canadarasp.com/. Its high resolution very frequently outperforms HRRR, especially in mountainous areas.

@nkinnan @idefix37 there is already a user preference for the particle animation speed:

Maybe adding a "None" option there could do the trick, without confusing casual users?

On the technical side, from a cursory look in the web developer console, it seems JS code is driving the animation. Freezing the animation loop in the debugger stopped the animation & CPU usage. Maybe adding "exit after one iteration" logic in that animation loop would go a long ways towards implementing a "no animation" preference?

On a recent paragliding trip I really noticed wind animations chewing through my phone battery quickly. While I was day tripping & had means of recharging my phone at the end of the day, energy usage is usually really tight on extended backcountry trips. This can be a safety issue. It would be great if we could understand wind flow forecasts without quickly running down phone batteries, and without manually toggling all wind display on & off.

I am seeing similar hanging behavior in Chromium.

@Suty, I am seeing a similar issue with wind stations:

The affected stations are accessible via search or direct link (https://www.windy.com/station/pws-38ed1449f078de59?47.940,-122.510,8,i:pressure and https://www.windy.com/station/pws-5c552daff078de59?47.988,-122.558,8,i:pressure), but not via favorites. Additionally, in at least the last 2+ months these stations are also not showing up any more in the "reported wind" layer, even at high zoom levels in that area. Both have up-to-date wind, direction & temperature reports.

Another station in an apparently even more broken state is "Flight Park South" in Salt Lake City / Draper (https://www.windy.com/?40.444,-111.891,13,i:pressure). Its latest wind reading shows up on the map, but trying to pull up details by clicking on the latest reading on the map throws this error:

@vicb, after manually deleting all windy site data in my browser, logging in again, and finally reinstalling the plugin to make sure it does pick up the latest version, I can confirm that https://www.windy.com/plugin/sdg/49.263/-121.882?namConus,clouds,49.263,-121.882,10 loads without a hang. Thank you for fixing this!

Hopefully the plugin upgrade & installation workflow issues can be fixed on the windy side. /cc @Suty

@gwicke Are you sure it hangs ?

@vicb, in both Firefox and Chromium I am getting the "this page is slowing down your browser..." dialog after a while, and the plugin does not load as expected. Here is a profile captured in Firefox:

Interestingly, the profile still seems to be referencing 3.0.2. The plugin UI lists the version as 3.0.3. @Suty, what is the expected upgrade behavior for plugins? There is no explicit "upgrade" button in the plugin listing. Are users expected to pick up the latest version of a plugin automatically?

@vicb, opening https://www.windy.com/plugin/sdg/49.263/-121.882?namConus,clouds,2024041221,49.263,-121.882,12 still hangs for me with 3.0.3 installed.

@Suty to clarify, I was thinking primarily about making plugins more discoverable / usable on the mobile website. The app would be nice too, but mobile web would be enough for my purposes.

@vicb, thanks a lot!

@Suty, what is your take on the plugin infrastructure questions? Are there plans to make plugins more discoverable / usable for mobile users? Will there be a way for users to follow a plugin-referencing link like https://www.windy.com/plugin/sdg/48.612/-122.425?clouds,48.612,-122.425,10, and get some UI / workflow that lets them install the plugin & see the linked view? This would make it a lot easier to help other users get started with analyzing conditions for a particular flying site, for example.

I am seeing similar hanging behavior in Chromium.

@vicb, thanks for porting the better sounding plugin! I can confirm that it works after going through the new "install" step, and then entering the plugin via the menu. On mobile, I had a hard time finding the plugin list / install workflow, and resorted to manually opening https://www.windy.com/plugins (no more trailing slash).

One thing I noticed is that plugins now seem to have proper URLs, so it could be possible to bookmark and share a full windy view using a plugin. This is excellent for power users. Hopefully, this will also enable us to share a plugin view with others, with a sensible install workflow when the plugin is not installed in that particular browser yet. Currently, when opening a URL like https://www.windy.com/plugin/sdg/48.612/-122.425?clouds,48.612,-122.425,10, I am getting high CPU usage and not much progress. This is in Firefox 122 on Linux, and Firefox 124 on Android. A profile on desktop looks like this:

First of all, thank you for making it easier to check on recently reported wind data by adding the "Wind detail" view for station data:

Would it be possible to make this view the default when pulling up a station from "Reported wind" displays? Alternatively, could this selection be remembered for the account?

As a potential improvement, especially on mobile the "wind detail" view still has a lot of other details (incl. nearby webcams, air pressure etc), and the wind view itself is still very small. For wind sports like kitesurfing, paragliding, sailing etc really focusing on the wind with more vertical resolution could be nice I think. In many cases, users will check recent wind on launch or even in the air / on the water, and might have spotty connectivity. In those situations, avoiding additional bandwidth usage for webcam thumbs etc would usually be preferable.

As another idea, extending the current mouseover preview of recent wind readings with a small wind graph could make checking different sites a lot quicker. As an example, a common scenario is deciding where to go for a paragliding or kite session, based on the trend at several nearby sites. Ikitesurf has such mini graphs (on click in that case), and these tend to be very useful:

@Suty, I am seeing a similar issue with wind stations:

The affected stations are accessible via search or direct link (https://www.windy.com/station/pws-38ed1449f078de59?47.940,-122.510,8,i:pressure and https://www.windy.com/station/pws-5c552daff078de59?47.988,-122.558,8,i:pressure), but not via favorites. Additionally, in at least the last 2+ months these stations are also not showing up any more in the "reported wind" layer, even at high zoom levels in that area. Both have up-to-date wind, direction & temperature reports.

Another station in an apparently even more broken state is "Flight Park South" in Salt Lake City / Draper (https://www.windy.com/?40.444,-111.891,13,i:pressure). Its latest wind reading shows up on the map, but trying to pull up details by clicking on the latest reading on the map throws this error:

@nkinnan @idefix37 there is already a user preference for the particle animation speed:

Maybe adding a "None" option there could do the trick, without confusing casual users?

On the technical side, from a cursory look in the web developer console, it seems JS code is driving the animation. Freezing the animation loop in the debugger stopped the animation & CPU usage. Maybe adding "exit after one iteration" logic in that animation loop would go a long ways towards implementing a "no animation" preference?

On a recent paragliding trip I really noticed wind animations chewing through my phone battery quickly. While I was day tripping & had means of recharging my phone at the end of the day, energy usage is usually really tight on extended backcountry trips. This can be a safety issue. It would be great if we could understand wind flow forecasts without quickly running down phone batteries, and without manually toggling all wind display on & off.