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.

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?

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

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