That's probably something we can try.

The thing is that different model report different things.
I think that EC has all of model elevation, actual elevation and sfc temp while GFS only has actual? elevation.

I have chosen to use the model elevation when available because what's below probably do not make a lot of sense ?

@stitch good catch. The line was still potted with the wrong scale in unzoomed mode. This should be fixed in 0.8.5. (You can specify the version when loading the plugin using the name windy-plugin-soundig@0.8.5 before it becomes the default in a few hours).

With regards to the scale in zoomed mode:
The plugin is originally targeted to paraglider pilots.
That's why I do not display hPa but elevation on the y axis and stop at ~7000m.
Given that a paraglider fly at ~40km/h we are less interested in speed > 30km/h - we would start flying backward in gusts and also have turbulences.
That's why having more granularity in the 0-30k range is interesting - we are only remotely interested in >30.
It does not affect us that much: we wouldn't fly in that zone but knowing the max speed higher still could be interesting.

That being said I'm open to extending the plugin for more use cases - we started discussing that with @johnckealy.
What I do not want is to have to configure 20 different options to use the plugin but what I could imagine is to have a handful of different "profiles" (paragliding, meteo, ...) each having a sensible configuration.

Having a shared google doc could help everybody interested share ideas ? Do you want to start one ?

The parcel is displayed from 2h after sunrise to 2h before sunset and starts at the surface elevation at air temperature +3C - it seems to works better for my use case. I think it would be better to discuss on an other thread ?

What I meant is that 250hPa is NOT in the data loaded from the data loader - that is whatever is available to plugins for GFS.

The windy UI might:

• do an interpolation,
• have more data available but I doubt as @ivo told me the opposite on an other thread.

Did you check if that is not a simple interpolation ?

Quick answers as I don't have much time right now
@Gkikas-LGPZ There is no data at 250hPa for GFS
@johnckealy It would be great if we can come with only one codebase and a few options. That would be less to maintain and more maintainers.
@stitch I have a linear scale in unzoomed view ready. I only need to publish it, probably later today.
@ivo great, thanks !

@Gkikas-LGPZ please check 0.8.2 that I have just published:

• Changing the units in the preferences should now work for altitude,
• There is a check box ("Zoom view") at the bottom to expand to graph up to 150hPa (zoomed view is up to 400hPa).

You probably need to specify the name as sounding@0.8.2 when loading it for now.

@ivo I'm all for it if possible. As @Gkikas-LGPZ mentions the sounding is more adapted for paraglider pilots currently and I probably need to make some small changes:

• The upper is currently set to 400hPa, changing it is only a setting,
• The wind scale is non linear (0-30km/h on the left half, 30 to max on the right half),
• I have done nothing to make it work on mobile screens.

All of this should be easy enough and there could be a setting to have a generic version or a specialized version for paraglider (a checkbox).

@Gkikas-LGPZ as mentioned above the current upper level is 400hPa but that's only a setting to change. I have just checked for the units. It seems like "ft" does not work ie altitude is always displayed in meters but "kt" works for me for the wind (You have to reload the page & plugin when you change the units). There is currently no way to have hPa on the y axis but that would be simple to implement.

ECMWF was by far the most accurate and useful for my sounding plugin.

I would be really interested in having access to ECMWF again.

Thanks for your looking into this,
Vic

Windy shows the meteogram at the picker (flag) location.
Températures match for near term forecasts.

As you can see on the screenshot

• the time on the meteogram is 6h on Monday 13
• the time on the timeline is 18h on Monday 13.

Given the temperature (31C), it seems that the timeline shows the correct time - ie the time of the forecasts currently displayed on the map (18h).

I'm wondering if this is linked to the extended forecasts having less data points that the near forecasts (every 6h vs every 3h) and that is not taken into account on the timeline ?