@NurlG Hi, we are already working on this - the pattern size just needs to be tweaked. It should be fixed in the next version.

@jab8283 Hi, this is a precipitation type in radar - the same case as snowflakes. For now, we have three categories - snowflakes for snow, no pattern for rain, and black dots for hail. In case you are not interested in displaying pType in radar, you can disable it in settings.

@idefix37 yes, @aslaugmvn is right, the metric is mistakenly reading the raw data inverted in reversed order. It is already fixed on our side and should be part of hotfix in a few days.

@lilhill Hi, we already implemented support for snapping time to reftime (where real data ends and nowcast starts) in radar and satellite layers. However, it will be available in version 51+ (not in the following v51). We are not planning to add a completely new button.

Hi, we are aware of the issue and have fixed it; it should be resolved in the next version. The problem was caused by a bug in the iOS 18 beta. We advise using stable OS versions.

@MetalAnon
Hi, could you tell us what iOS version and what Apple device you are using? Does the error happen every time you open radar layer? Does it also happen on the satellite layer?

Thank you!

Hi @alanduckers,

the Radar+, Radar, and Satellite layers use the same data. The difference is that Radar+ also performs the mentioned extrapolation of past satellite data. However, this extrapolation does not apply to radar data in the Radar+ due to technical constraints. As a result, and because radar providers can experience delays, you may notice that radar and satellite data do not always sync correctly in the Radar+ layer. For example, in the UK, the radar data currently lacks the most recent timestamp. Regarding the strange patterns, these might be caused by satellite data outages that are compensated for through extrapolation.

@ramzik99 Hi, we released hotfix, so it should be ok right now.

@compasscard Hi, this is intended behaviour since isolines are forecast and radar (satellite) is observation. Previously, we completely disabled the option of having isolines in radar and satellite layers, but after some complaints, we added them back. Since it does not make sense to combine forecast with past data (the mentioned -6h radar loop), it is indeed visible only in the last few minutes.

@Mavendow Hi, I looked at it, and you are right that no error message is being displayed right now - but this must be some recent degeneration, since we implemented the WebGL error message (and robust WebGL context support handling) the day we completely migrated to WebGL-only (a year ago). This should be fixed in the next version.

@Mavendow said in Web site is down:

But please, do tell me more about how deselecting a normal setting in every modern web browser should break the entire website. It's an interesting way of coding I've not heard of before.

I am sorry, but this statement is similar to "disabling JavaScript completely broke the page". This is not about deselecting a normal setting. WebGL is an essential technology required for implementing custom GPU-accelerated rendering, without which Windy wouldn't perform well.

@Cirkzz Hi, thank you for the report. Could you give us more information to help us troubleshoot the problem?

• for how long have you been experiencing this issue
• does it also happen on the satellite layer
• does it happen exclusively only during zoom, or is it possible to make the app crash during panning / playing animation
• could you verify the behaviour also in browser
• what device and os version do you have

Thank you!

@Riad-Ishak Hi, thank you for the report. Could you tell us more details?

• for how long do you observe this issue
• what device do you use (brand, model, os version)
• in case you use mobile device, does it happen in the mobile app (and if so, does it also happen in the browser)

@Paulair Hi, thank you for the detailed report. Yes, we did some changes in the lightnings renderer roughly two months ago (in version 51.2). So theoretically, your problem could be related to it. Could you tell me, whether it also affects strikes accumulation (the brownish areas on the map)?

@Nicholas-Mogire Hi, could you send us more information? E.g. whether there is any warning on top of the screen, or whether there is any error in the error console (or devtools). When did the radar overlay stop working for you? And do other overlays work (including satellite)? What device and browser do you use?

Thank you!

@Mickyship Hi, do you have any error in the console (either https://www.windy.com/debug, or in the devtools console)? And did you try any other browser?

@ramzik99 Hi, we released hotfix, so it should be ok right now.

@idefix37 yes, @aslaugmvn is right, the metric is mistakenly reading the raw data inverted in reversed order. It is already fixed on our side and should be part of hotfix in a few days.

@Mavendow Hi, I looked at it, and you are right that no error message is being displayed right now - but this must be some recent degeneration, since we implemented the WebGL error message (and robust WebGL context support handling) the day we completely migrated to WebGL-only (a year ago). This should be fixed in the next version.

@Mavendow said in Web site is down:

But please, do tell me more about how deselecting a normal setting in every modern web browser should break the entire website. It's an interesting way of coding I've not heard of before.

I am sorry, but this statement is similar to "disabling JavaScript completely broke the page". This is not about deselecting a normal setting. WebGL is an essential technology required for implementing custom GPU-accelerated rendering, without which Windy wouldn't perform well.

@Mavendow Hi, this is not about devs not fixing uncaught error... Windy requires WebGL (the mentioned HW acceleration) and without it it won't load.

Hi @Lestrade, @ibits, could you test this behaviour on the radar and satellite layers and see whether they also have any kind of rendering issue? Could you also send us a screenshot of the whole viewport (ideally the same layer you reported earlier), so we have more context? From the provided screenshot, I cannot even identify which layer it is. Thank you!

Regarding the issue, we already had some problems with FF, and it was always some setting related to color management or fingerprinting. Also, could you tell us when you started noticing this error? It could be related to a specific FF version, and an update might resolve it. You could check the following topic, where we already discussed it: https://community.windy.com/post/223049