soaringmeteo / soaringmeteo Goto Github PK

would be possible to have more that two days?
Current on v2 we have tommorrow and depending on he run time, the day after

Is your feature request related to a problem? Please describe.

Currently, the wind is only shown visually with arrows. It could be useful to add an “Overlay” that would show the wind speed with a color scale, like Meteoblue does, for instance:

Describe the solution you'd like

Add a “Wind speed” overlay to the menu:

This overlay would apply to every grid cell a color according to the wind speed in that location.

Additional context

Currently, we support the following wind elevations:

Consequently, we should generate wind overlays for each supported wind elevation.

The overlays are generated here on the backend. Every layer has a corresponding definition in the frontend (for instance, here is the Thermal Velocity layer. Note its dataPath must match the path produced by the backend).

In the current soaringmeteo.org, in the aerological map you can show the rain.

Displaying a sounding diagram on a small screen device is inconvenient. The bottom is cropped and there is no way to scroll down.

Instead, it would be better to adapt the diagram to the screen space, and to support zooming in and out.

On several maps, there is a button to recentre the map on the current location (useful when called from phones).

Would that be possible on v2, is it complicated?

This is an old dream, but perhaps it is possible with the new data layouts and separation of front/backend.

The idea would be to click on a point (say close to the Pléiades), and create and alerts (email, telegram...) if the wind force 250m AGL and soaring potential look good for three days in a row, over the coming week.

A potentially interesting feature could be to expose an backend API with documentation to the outside world. This could allow other developers to build a separated, more intuitive front-end, based on the existing computation, and let the team focus on the data gathering and model building side. This would nevertheless come at the cost of an API management topic, potentially with versioning etc.

Describe the bug

When the diagram or the “summary box” is shown, it is not anymore possible to click to a location beside the box. Clicking below the box works, though.

To Reproduce

Click on the map to open the “summary box”, then click to another point of the map, anywhere on the right side of the box (but not below the box).

Expected behavior

The content of the box should be updated according to the newly selected location.

Additional context

The problem is due to the fact that the timeline at the top of the screen and the diagram/summary box are all inside the same HTML element. The reason this was done like this is that this allows us to scroll horizontally both the timeline and the diagram on small screens.

Is your feature request related to a problem? Please describe.

The list of WRF zones does not tell the resolution used by each domain:

Describe the solution you'd like

Instead, we should make it clear that the “Alps Overview” uses a domain with a resolution of 6 km. For instance:

Additional context

The labels are defined here:

This file is part of the backend, which exports the labels when it produces the frontend assets.

On small devices, the top of the “layers” menu may be truncated. Since it is not possible to scroll, some entries may be completely unreachable, see:

We always show time according to the user timezone. This can be an issue when a user is looking at a forecast for a remote area (with a possibly different timezone than their timezone).

We could introduce a setting allowing users to switch between their time or UTC time.

I am happy to provide translations into polish language.
Will you enable PL ?

In the current soaringmeteo.org, in the aerological map you can show cumulus sizes.

About

When I check the Meteogram of a spot in the map, the resulting graph shows a altitude (over Mean Sea Level I assume?) and pressure level (1050 hPa, etc) seems to be inverted.

I think that pressure level is probably wrong (as I think you would usually show low altitude in the bottom and high at the top)

Legacy soargfs provides both cloud cover and relative sunshine information:

Furthermore, the relative sunshine information is used to compute the ThQ:

https://github.com/Boran/soaringmeteo/blob/c3c4562f086c283ed4063f94c0da26b2c309aa49/src/makeGFSJs.pas#L841

(so, it uses both the relative sunshine and the cloud cover information to compute the ThQ)

However, the way the relative sunshine information is computed seems quite approximate to me.

It is based on the “max insolation” values we provide in the CSV file gfs-loc.csv, but we don’t have a correct way to get these insolation values for new points. Then, these max insolation values are interpolated to compute the max insolation value at a given time of the year, following a sinusoidal shape:

https://github.com/Boran/soaringmeteo/blob/c3c4562f086c283ed4063f94c0da26b2c309aa49/src/makeGFSJs.pas#L1165

In the new version of soargfs, we don’t do that anymore, and we compute the ThQ only based on the cloud cover.

However, it seems that there is a way to get the relative sunshine information from the GFS output. Indeed, the secondary files contain clear sky downward solar flux and downward solar flux:

The ratio between the two is the relative sunshine.

We currently fetch only the primary GFS data, but we could complement it with the secondary GFS data to get the relative sunshine.

The current formula is adjusted for paragliders flying in mountains, but it is not great for flatlands or sailplanes.

It would be good if the users could configure their type of soaring activity and we could adjust the formula appropriately. Here are some examples of possible settings suggested by a user:

Mountains - as now
Flatlands -7kmh+ at base of boundary layer, any wind at the top
Flatlands towing 15kmh+ at base any at top
Sailplanes - Ignore wind

Currently, the XC flying potential value is computed on the backend. If we want to make it configurable, we may want to compute it on the frontend instead.

In SoarV2 soarGFS model, I found very convenient the following calendar visualization to navigate between forcasted days :

In SoarV2 soarWRF model, only the current day is displayed. Navigation between forcaster days is only available with the -24 / -1 / +1 / +24 menu at the bottom of the page :

-> Is it possible to use in soarWRF modal the same calendar visualization used in soarGFS ?

I might be wrong, but I think I noticed that high-altitude clouds (8km+) are not taken into consideration in the soaringmeteo forecasts? Is that correct? As they limit sunshine and thermals a lot, and could hence be a valuable part of the forecast. I currently use meteoblue cloud forecasts to check that.

On 24.03.2021, there has been a change in the distribution format of weather data used for the computation, which interrupted the service at the time.

• Previously, the first forecasting soarWRF results for the day after tomorrow were available around ~8:30 or 9:00am.
• From then on, forecasting results for the day after tomorrow became available around 11:30am.

Having these forecasts earlier was very handy, especially for week days, as it allowed for easier day-off planning and eased relations with management. Would there be a way to gain a bit a computing speed, to have the results earlier again?

SoarV2, XCTherm and others are good backup solution for such purpose, but I thought I'd still open a ticket here 😃 Have a good day!

I open a meteogram, and navigate using the dates in the red part.
The data in the green part does not update
The dates at the bottom (ping), do, also change correctly

Tested on windows: Chrome and Edge. Androis.

In SoarV2 it will be interesting to easily make availlable the model initialisation run time used (GFS or WRF) and soaring meteo last update time.
Proposal :
->Display these 2 informations on the Sumary section

OpenLayers supports raster reprojection out of the box, which would be useful to display the forecast data as an overlay on the map. We currently use Leaflet, where we have an ad hoc implementation of the projection of the GFS grid on the map.

Also, OpenLayers seems to support the WMS provided by Météo France.

OpenLayers seems powerful, however, the following points need to be investigated:

• would this increase the size of the application bundle?
• OpenLayers can easily project pixels in the map, but what about some more advanced shape, like a wind barbell?

Is your feature request related to a problem? Please describe.

The “summary box” shows the XC potential over the hours of the current day:

Describe the solution you'd like

Alternatively, it could show the XC potential at mid-day for the current day and the next ones (like we do with GFS).

Can we add the initial spanish?
I'll will then do the machine translation and get it review by a native speaker at RVL

Hello,

First of all, I want to congratulate you on this superb tool.

I am trying to run the code locally, but I am not familiar with the expected format for the locations CSV file. Can you provide an example file to facilitate the project setup?

I was surprised by the differences between those models. I was expecting a convergence of the results.

If I take today (29.09.2023) forecast for today and tomorrow (30.09.2023)

The forecast seems inverted: it's better today on GFS and tomorrow on SoarV2.

Would it be possible to show on the meteogram?

In the current soaringmeteo.org, the aerological maps let you see the surface wind.

Perhaps the fiveDaysAgo could be a parameter so that you could decide later how many days you wish to keep (e.g. depending on disk space)?

Originally posted by @Boran in #5 (comment)

I agree, it would be good to make this duration configurable, as well as the number of days of forecast (currently 9).

In the current soaringmeteo.org, there are 6 pressure level difference graphs (useful to assess foehn danger)