soaringmeteo / soaringmeteo

Weather forecast for soaring pilots (paragliding, hang gliding, etc.)

SoaringMeteo

https://soaringmeteo.org is a weather forecast website for soaring pilots.

This repository contains the implementation of the new version of the website.

Architecture

On the one hand, SoaringMeteo produces weather forecast data relevant for soaring pilots. This data is produced either by extracting it from third-party sources such as GFS, or by running the WRF model on our own servers.

On the other hand, this forecast data is displayed on the website https://soaringmeteo.org.

This repository contains two sub-projects:

• backend, which produces the forecast data,
• frontend, which displays the forecast data.

The backend part is made of three distinct programs:

• gfs, the GFS pipeline, which processes data from the GFS model
• wrf, the WRF pipeline, which processes data from the WRF model
• common, common parts (e.g., GRIB extraction, etc.)

Please refer to each sub-project for more details.

Usage

Go to https://soarwrf1.soaringmeteo.org/v2.

License

GPL-3.0-or-later

Contributing

Pull requests are welcome. See the CONTRIBUTING.md file for more details, or the TRANSLATING.md file if you want to help translate the user interface.

Donating

As you may know, Jean Oberson originally paid for the development and operation of this site (and we appreciate that). To ensure the long term viability we are request donations to cover the operational costs. CSM membres contributing to the site or administering the club give their time free of charge. We prefer direct donations as opposed to other forms of financing such as advertising.

Each year we look for funds to pay for the web and computing servers (for WRF + GFS calculations and the website). The budget is approx. 1'500 CHF (1350.- €) per year.

We promise to continue to publish the CSM annual accounts on this website. So, we ask you to consider a donation however modest. Each donaton encourages us to further develop the site - we thank you in advance.

soaringmeteo's Issues

Consider using OpenLayers instead of Leaflet

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?

Time is always shown according to the user timezone

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.

Sounding diagrams are not responsive

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.

XC flying potential is not configurable

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.

Difference between SoarGfs and SoarV2

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.

Add more WRF days forecasts?

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

Expose Soaringmeteo API

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.

Sounding forecasts are missing

No pressure difference graphs

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

Meteogram altitude & pressure level seems to be inverted

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)

Cloud cover forecast is often over-optimistic in WRF

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.

Alert when several good flying days ahead?

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.

The “layers” menu is not fully visible on small screens

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:

Button to centre map on current location (feature request)

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?

Meteogram navigation

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.

Add support for language ES

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

Unable to click on the map besides the summary or diagram view

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.

[UX] SoarV2 - Display last run time & update time

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

Location details are not shown on meteograms

[UX] SoarV2 - soarWRF - Display calendar for forcasted days

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 ?

No ThQ in meteograms

Add a “wind speed” overlay

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

Add support for language PL (polish)

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

Unable to change history size (and other parameters) from configuration

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

Feature request: Show inversion on meteogram?

Would it be possible to show on the meteogram?

No layer “surface wind”

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

No relative sunshine in soargfs

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.

Enhancing computing speed

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!

No layer “cumulus size”

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

No summary of the XC flying potential is shown in the tooltip that pops up when you click to a location

No climatology history

The backend depends on an unknown CSV file

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?

Show an overview of the coming days in the WRF summary-box

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

No layer “Rain”

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

Locations and widgets cannot be bookmarked

WRF domains resolution is not explicit

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:

soaringmeteo/backend/wrf/src/main/scala/org/soaringmeteo/wrf/Grid.scala

Lines 15 to 18 in 61b672d

	"d02" -> Grid("alps-overview", "Alps Overview", 450),
	"d03" -> Grid("central-alps", "Central Alps", 350),
	"d04" -> Grid("southern-alps", "Southern Alps", 350),
	"d05" -> Grid("eastern-alps", "Eastern Alps", 400),

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