Posts made by tomA27

@pavelmedia Perfect! That was exactly the answer that I was hoping for. Thanks again.

@pavelmedia Thanks again for your help. I have one question please. If I run publish-plugin again (with a new version) in order to "install directly from url" and test future changes on a mobile phone, will that interfere with the published version that everyone sees? If so, what is your recommendation for such testing?

@pavelmedia I don't know if it was even necessary but I did a new "publish-plugin" so I had to up the version to 1.0.6.

@pavelmedia Thank you very much for looking at the plug-in. I have already renamed the screenshot.

@rittels I've just tested that I can install your density altitude plugin using chrome on my phone and then access it successfully by navigating to windy.com/plugin/density-alt so I imagine that SoarCalc and other plugins will behave in the same way. So, for me, panic over.

@rittels Are you saying that if installed directly from my url 12216047/windy-plugin-soarcalc/1.0.5/plugin.min.js then the user will be able to open and use my plugin by navigating to windy.com/plugin/soarcalc as I have said in my installation instructions: https://github.com/tomgooch/windy-plugin-soarcalc/wiki (I know that a considerable number of people have done this successfully)

BUT if the plugin is officially installed and available to select from in the list then they will not be able to access it by navigating to windy.com/plugin/soarcalc ? I have obviously not tested this as it is not yet published (I asked for it to be published yesterday).

@francescogola sorry to take over your thread.

@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.

Hi, I would like to submit this plugin please...

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

I have already been using it privately and have circulated it to be used directly from the url to a number of others.

@Suty @jancellor @jphobbs
Isn't the fundamental problem here that the timestamp for the mapped data is not actually displayed on the map? If it were then the problem would be obvious. It becomes obvious if you have a plug-in that displays this timestamp as obtained like this...

onMount(() => {
    broadcast.on('redrawFinished', onRedrawFinished);
});

function onRedrawFinished(params: any)
{
	console.log('onRedrawFinished', params.path);
        _path = params.path;
	const dateString: string = _path.substring(0,4) + '-' + _path.substring(4,6) + '-' +   
        _path.substring(6,8) + 'T' + _path.substring(8,10) + ':00:00Z';
	_hour = new Date(dateString).getTime(); }

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.

@idefix37 Thank you again.

@idefix37 I've done some searching. I find that getPointForecastData() gives me the surface pressure for AROME (2.5km) but not for AROME-HD (1.3km). So in the sense that I can calculate the surface elevation from the surface pressure in the 2.5km case what you say is correct. Is this what you meant? It does strike me as very odd. Can there really be any good reason for not supplying model elevation directly in both cases? (I'm interested in boundary layer thickness and lifting condensation level so as it stands AROME-HD is pretty useless to me if I cannot get hold of model elevation)

@idefix37 Thank you for your reply.

Am I missing something? For all the other models (that I have looked at) the actual elevation is returned in the header here:
meteogramForecast.data.header.elevation;

and the model elevation here:
meteogramForecast.data.header.modelElevation;

As far as I can see model elevation is not given in this location for either AROME-HD (1.3km) or AROME (2.5km). And in both cases model elevation is shown as NaN in the Sounding Forecast pane.

Are you saying that model elevation is made available in some other place in the case of AROME (2.5km)? If so please let me know where I can find it?

It seems that the forecast data as returned from getMeteogramForecastData() does not include the model elevation for the AROME and AROME-HD models. This spoils the Sounding Forecast and anything else that wants to use the same data.

Is there a reason for this? Where has this information been lost? I.e. by Windy.com or before the data is supplied to Windy.com? It would be very good to have this corrected especially as AROME-HD is such high resolution.

@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.

@jancellor @vicb Thank you for your input. I'm sorry that I never discovered your thread before.

The Sounding forecast already uses the surface temperature/dewpoint at the 1000hPa level. (or perhaps it uses the temperature and dewpoint from getPointForecastData which gives the same values). This is plain to see if you display the temperature, dewpoint and LCL separately in another add-in

My understanding is that "surface" means the air in contact with the surface (normally at 2m). Indeed dewpoint-surface, rh-surface, wind-v-surface etc are clearly properties of the air close to the surface rather than the surface itself.

I find it impossible to see any good reason not to use the surface temperature/dewpoint at the surface level (model elevation).

Personally, I see this as quite an important bug in the official sounding forecast.

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?

I like the sounding pane a lot but I have discovered, what I see as quite a serious problem. Whenever the model elevation is below the 1000hPa level it is incorrect. It shows the surface temperature and dew point at the 1000hPa level as if this were the surface. eg...
Surely LCL should be model elevation + 125 * (surface temperature - surface dew point) should it not? This is what is shown in my plugin 4 + 125 * (14.8 - 7.4) = 925 (929 difference is due only to precision with which numbers are presented).
However, in the screenshot the 1000hPa level is 223m and LCL is shown as 1120m which is more like 223 + 125 * (15 - 7) = 1223. (here, the loss of precision is greater). The pattern is repeatable, I have looked in many locations at many times, it really does look like whenever the surface pressure is above 1000hPa it is basing LCL on the 1000hPa level rather than on the surface.
If you select a point where the surface pressure is below 1000hPa there is no such problem and the agreement is very good e.g....
Of course, one of the reasons that this disturbs me is that others (like me) will assume that the sounding is correct and my plugin is wrong which, in fact, is not the case. For this reason, I do not feel that I can yet make the plugin available to others which I would like to do.
This looks like a bug to me, in which case it would be really great if it could be fixed please?
Or can someone point out where I am mistaken?

OK, worked it out by looking in fetch.d.ts...
const latLonStep: LatLonStep = { lat:_loc.lat, lon:_loc.lon, step:1};
getMeteogramForecastData(_model, latLonStep).then((meteogramForecast) => {
_meteogramForecast = meteogramForecast;
updateSounding();
});

I've just signed up for premium and set my forecast resolution to 1 hour which works fine in the browser. I sort of assumed that this would also cause getMeteogramForecastData() to return the data in 1 hour steps instead of 3 hour steps but it does not.
The documentation for getMeteogramForecastData() does elude to the possibility of passing additional parameters but is not really very helpful.
Please can someone tell me if there a way of asking for and getting 1 hour time steps from getMeteogramForecastData()? If not why not?
Thanks.