I agree with idefix: temperature layer at 850hPa is useful. Looking at winds also helps: wind abruptly changes direction by maybe 45 degrees at the front. Over ocean, surface winds are fine, but over land I'd look at winds at 850-900hPA as well. It also helps to look at precipitation: it rains there. It also helps to see the pressure contours: they have a little kink at the frontal lines. My favorite view at windy.com for that is: color as precipitation, pressure contours, and particle wind animation.

There are some related discussion here https://www.morganscloud.com/2017/06/28/grib-weather-files-you-gotta-see-the-rain/

Re: storage. Access even to a very sub-sampled historical data would be useful as well!

If you have data at 1 degree resolution, that is roughly 360*180 points per globe. If you were to only keep 5 (7, 10) basic measurements (pressure, temperaturue, wind speed/direction, precipitation) at three different altitudes (0, 850hPa, 500hPa), it gives you: 360 * 180 * 5 * 3 * 4 (bytes per float32), which is about 4MB per measurement. Sample it every 3 hours over a year, and that would be 8GB/year. Go to 0.5 degree resolution, and that's 32GB/year. That still can fit on my laptop. And I think grib files actually use less than 4 bytes per point.

I was also frustrated with the lack of any ways to access historical data. So I'm actually planning to download a bunch of grib files from public GFS server, select only relevant timepoints/layers, and save them for viewing in existing grib viewers (or publish them somewhere). It is still a lot of work, probably a week of coding for me, and however many days/weeks to download the data. I may actually do this project at some point.

Found them! It wasn't trivial though. I tried to find it several times, and still completely missed the bottom-right corner menu buttom.

As a side note, is there a reason the app has two menus? Could they be made into one long menu, and the top button would load the top of it, while the bottom would load the bottom? This would help people like me find the right menu item.

Re: Can I change the color scheme?

I'm trying to revive this old topic that talked about the current colorscheme not being able to distinguish 13kt from 18kt. I am a sailor, and the green color currently ranges from force 3 to early force 5, which is a huge difference for kitesurfing, small boats travelling upwind, and many other wind-related sports. Currently you can't visually tell 13 knots from 18 knots, and there is a 2-fold change in wind pressure there (18^2 / 13^2 = 1.91), which is a lot!

I'm a data scientist, and I spend a lot of time using colormaps and thinking about them. I can see that the current colormap is suffering from the same problem as the infamous and widely used Matlab's "jet": green colors are just all blurred together; you have no contrast there. Matlab since even changed away from Jet to a more perceptually balanced colormap. Same happened with matplotlib, and they have some discussion here https://matplotlib.org/users/colormaps.html

I currently don't have a colormap in mind that would replace the current one, due to the required dynamic range. But I would be happy to work with someone from the Windy team to find/design one.

It may be just me being slow... but nevertheless I consider myself a power user. I just find it very unusual to have a menu button on the bottom of the screen. For example, apps like google maps now have two menu buttons: regular menu in the top left corner, and "layers" menu in the top right.

Found them! It wasn't trivial though. I tried to find it several times, and still completely missed the bottom-right corner menu buttom.

As a side note, is there a reason the app has two menus? Could they be made into one long menu, and the top button would load the top of it, while the bottom would load the bottom? This would help people like me find the right menu item.

Yes, pressure isolines.

I've been using them in the web app. But I couldn't find a way to enable them in the Android app.

Would be great to be able to to display pressure contours in the Android windy app. At least I could not find any way to enable it.

It would be very useful for the sailing community.

Re: storage. Access even to a very sub-sampled historical data would be useful as well!

If you have data at 1 degree resolution, that is roughly 360*180 points per globe. If you were to only keep 5 (7, 10) basic measurements (pressure, temperaturue, wind speed/direction, precipitation) at three different altitudes (0, 850hPa, 500hPa), it gives you: 360 * 180 * 5 * 3 * 4 (bytes per float32), which is about 4MB per measurement. Sample it every 3 hours over a year, and that would be 8GB/year. Go to 0.5 degree resolution, and that's 32GB/year. That still can fit on my laptop. And I think grib files actually use less than 4 bytes per point.

I was also frustrated with the lack of any ways to access historical data. So I'm actually planning to download a bunch of grib files from public GFS server, select only relevant timepoints/layers, and save them for viewing in existing grib viewers (or publish them somewhere). It is still a lot of work, probably a week of coding for me, and however many days/weeks to download the data. I may actually do this project at some point.

I agree with idefix: temperature layer at 850hPa is useful. Looking at winds also helps: wind abruptly changes direction by maybe 45 degrees at the front. Over ocean, surface winds are fine, but over land I'd look at winds at 850-900hPA as well. It also helps to look at precipitation: it rains there. It also helps to see the pressure contours: they have a little kink at the frontal lines. My favorite view at windy.com for that is: color as precipitation, pressure contours, and particle wind animation.

There are some related discussion here https://www.morganscloud.com/2017/06/28/grib-weather-files-you-gotta-see-the-rain/