I am a glider pilot and would be very interested seeing an enhanced the "Termals" layer and/or adding new layers in a "Soaring" group?

I am thinking that most of the parameters from RASP like "Thermal updraft velocity W*", "Thermalling height", "CuPotential", "Cu Cloudbase where CuPotential > 1000" and even "Star Rating" are all directly and relatively simply derivable from model data. It would therefore be possible to show all these things either as separate layers or perhaps combined into the "Thermals" layer in some way.

Would there be any interest in such a development? I think there are a lot of glider pilots who would sign up from premium if it were there.

@francescogola

It does, in fact, remain possible to use plugins on a phone within a browser. This is a section that I added to the installation note for my plugin covering this. I think it is quite likely that your plugin will also work in this way. I hope this is helpful...

Mobile

Note: Windy plugins including SoarCalc are not compatible with the Windy mobile App but SoarCalc functions well within Chrome etc on mobile devices.

1. Open Chrome or other browser on your mobile device.

2. Navigate to "windy.com/plugins" (do not go to windy.com as that will redirect you to the App which you do not want)

3. SoarCalc should appear in the list of available plug-ins. If so simply select it, otherwise please follow Load plugin directly from URL.

4. The plug-in is now installed. However, it is not yet available in this browser tab so close this tab.

5. Navigate to "windy.com/plugin/soarcalc" in a new window/tab and SoarCalc will appear at the bottom of the screen.

6. It will always be necessary to use "windy.com/plugin/soarcalc" so you may want to create a shortcut to that.

7. Ignore the button inviting you to "Download App".

Load plugin directly from URL

If "SoarCalc" is not found in the list of plug-ins then it is still possible to install directly from the URL...

1. Select “Load plugin directly from URL”

2. Paste this string after the url already present in the input box:

      12216047/windy-plugin-soarcalc/1.0.5/plugin.min.js
   

3. Press "install untrusted plugin" and SoarCalc will be available on the main menu.

Whenever the surface pressure is greater than 1000hPa the sounding forecast shows incorrect data. Specifically, it shows the surface temperature and dew point at the 1000hPa level as if this were the surface. In the screenshot below, the model elevation is 112ft whereas the 1000hPa level is 748ft which results in LCL being reported 636ft too high (TCON/CCL are also incorrect). This can be verified quite easily by looking at the data returned by getMeteogramForecastData() which, certainly appears to be exactly the same data as is being displayed by the Sounding forecast.
Please can this be fixed?

OK, the problem was that the upload url changed to https://node.windy.com/plugins/v1.0/upload since the last time I published and I needed to update my copy of publish-plugin.yml

@nrbray @Suty temp-surface and dewpoint-surface are already being used. But they should be applied at the surface level rather than at the 1000hPa level. I.e. like this...

    const surfaceT: number = md['temp-surface'][t];
    const surfaceTdew: number = md['dewpoint-surface'][t];
const surfaceGh: number = meteogramForecast.data.header.modelElevation;	// surface geopotential height is provided in the header rather than the data

rather than the equivalent of this...
const surfaceT: number = md['temp-surface'][t];
const surfaceTdew: number = md['dewpoint-surface'][t];
const surfaceGh: number = = md['gh-1000h'][t];

(taken from code I wrote to reproduce the numbers)

I suspect that this would be rather a straightforward fix.

Hi @vicb

I would be hugely grateful if you could take a look at and comment on my previous post. This really does seem like quite a simple error with a simple fix. However, it does have consequences for anyone interested in thermal soaring from lowland locations in areas of high pressure. (i.e. most sailplane/hanglider/paraglider pilots most of the time???).

It also has serious consequences for a new plug-in (SoarCalc) which I wish to publish which calculates the RASP soaring parameters. It is natural to show "SoarCalc" alongside the "Sounding forecast" and the data shown overlaps the most simple case being LCL. "SoarCalc" will show this correctly (basically just)...

model elevation + 125 * (surfaceTemp - surfaceDewPoint)

whereas "Sounding forecast" is basically showing

1000hPa elevation + 125 * (surfaceTemp - surfaceDewPoint)

which is simply not correct. So, yes, you should be using the "-surface" level data (which is the same as obtained with getPointForecastData()) in conjunction with the model elevation from the header (gh-surface is always null).

My problem is that people are likely to assume that "Sounding forecast" is correct and "SoarCalc" is incorrect and will therefore junk the new plug-in with little further consideration. I am therefore very hesitant to publish my plug-in.

@cepelk Thanks for your interest in the SoarCalc plug-in. (By the way, it has just been updated to work properly with the recent update to Windy.com)

As I understand it there is no intention to add support for plug-ins within the Windy mobile App. (Although I would be happy to be wrong about this).

However, as described in the installation instructions within the SoarCalc ReadMe.md file that you can find here...

https://github.com/tomgooch/windy-plugin-soarcalc

it is possible to use plug-ins within a browser on a mobile phone which will achieve pretty much the same result.

BUT, since I wrote the ReadMe file things have moved a little in the wrong direction. You can still install the plug-in by navigating to https://www.windy.com/plugins however you can no longer open Windy.com with the plug-in active by navigating to https://www.windy.com/plugin/soarcalc (or any other plug-in so far as I am aware). Instead, it is necessary to go to https://www.windy.com/plugins each time, select SoarCalc and then "Open plugin" from there.

This works but for some reason it is no longer possible to tap on the items shown in the plug-in to see the tooltip / description of the parameter. The parameters are however, fully described in the ReadMe.md file.

I hope you find this helpful.

I would be very interested if anyone can tell me why urls like https://www.windy.com/plugin/soarcalc no longer work. If this is a permanent state of affairs I will update the ReadMe to reflect this.

@pavelmedia Thank you.

Hi, I have updated my SoarCalc plugin to be compatible with recent changes in Windy.com. github tomgooch/windy-plugin-soarcalc

I have marked it as public with this URL and have already done a publish-plugin giving...
"https://windy-plugins.com/12216047/windy-plugin-soarcalc/1.0.11/plugin.min.js"

Please can the properly released plugin be updated to this version.

Thanks

OK, the problem was that the upload url changed to https://node.windy.com/plugins/v1.0/upload since the last time I published and I needed to update my copy of publish-plugin.yml

Can anyone help me with this? the "publish-plugin" action is now always failing with exit code 22 with the following output...

This is not an error it is the normal state. I think you may need to take a look at https://docs.windy-plugins.com/getting-started/debugging.html

@rittels Thanks for the hint. I did wonder if this was happening and will now take another look as this will also have a bad effect in SoarCalc. For me, this has been masked by the worse problem that getLatLonInterpolator() fails (never resolves) some fraction of the time and I needed to add a timeout and fail gracefully.

Right now I am struggling to work out why the "publish-plugin" action always fails with "Error: Process completed with exit code 22." This has happened before and I cannot for the life of me remember what I did to resolve it.

Until recently, the following code (called within onRedrawFinished) worked properly. Following the recent update it now fails about 50% of the time in the sense that the updateInterpolator function never gets called. (I have never seen the "catch" happen in my testing)

		getLatLonInterpolator().then((interpolator) => {
			updateInterpolator(interpolator, model, overlay);
		 }).catch((e) => {
			console.log(e);
			updateInterpolator(null, model, overlay);
		 });

This has a bad effect on the functionality within the SoarCalc plugin. Any help would be very gratefully received.

@rittels Thanks for suggestion. Do you know exactly what store.get('timestamp') returns? What I (we all?) need is the timestamp corresponding to the currently displayed forecast data definitely not the time displayed on the slider.

The parameters to the onRedrawFinished event used to contain a "path" from which one could deduce the timestamp of the map that has just been drawn. In the SoarCalc plugin I use this to update and show soaring parameters corresponding to the currently displayed forecast.
The "path" parameter is no longer there and so the plugin no longer works. Please can this either be reinstated as it was or, better, can a timestamp be provided in a more appropriately named parameter.