It takes a few minutes for npm to update. At the moment version 1.0.2 loads, though if you click debug, it still shows 1.0.1. This happens if you update the version number in package.json, after compiling it plugin.js. The original version number is then still included in plugin.js. It does not matter at all, just looks confusing.
@rittels, the skewT is overlapping the spot forecast? I'll look into that. Man I hate cross-browser incompatibility! The error you see isn't anything to worry about, been meaning to find a way to suppress it. It's just the data points in the ascent that I didn't want shown.
Thanks for the info on the temperature discrepancy too @Gkikas-LGPZ and @Yves70, I'll have a look into that for the next version.
The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
Thanks, this allows me to get plugins also on iPad and cell phone which was not possible with the app nor the mobile web. As it automatically opens the app I can’t save a bookmark. So I put your post in favorite.
NWP forecasts are generally available to public in GRIB format, which contains a grid of rectangular cells - regularly distributed over the coverage area - for each parameter/level.
Parameters of NOAA's GFS 0.25° model (actually it is its full name; there is also GFS 0.5°), are well provided on grids with cells of 0.25° X 0.25° (lon/lat WGS84), one value by cell.
Thus, saying resolution 0.25° (or corresponding distance in km. on Earth at some latitude), is not an error; it corresponds to the distance between two values on the grid, i.e. to the resolution of the model as displayed on map (independently from the computed resolution in factory).
E.g. for lat=0°, distance between two values is 27.8 km for GFS 0.25°, while at mean Europe latitudes (lat=45°), the resolution is 20 km (see self-explaining image above).
For model values displayed on map as color shading (palette), or when user click on the map, intermediate values are extrapolated from neighbour cells values to the selected position (I don't know which extrapolation or smoothing algorithm Windy uses, there are many of them).
From my pov., the best would be to provide the resolution of a model in ° WGS84...
Defining the grid cell resolution as distance on Earth may be tricky, as it mainly depends on the latitude.
E.g., which would be the distance between two values of GFS 0.25° at levels at dozens of Km above the Earth?
Other models (e.g. DWD's ICON) are computed and provided in grids with hexagonal cells; they should generally be converted to square or rectangular grids in order to allow map renderers to handle them; here, the rendered resolution is not the same as the original one.