[CLOSED] v35.0.0

[Liam.pankhurst]

@marekd is there any plans to add local models for Australia? This would be very helpful

[marekd]

@liam-pankhurst What a coincidence... Stay tuned ;-)

[idefix37]

@marekd
Hello,
This new version is really interesting. I'm sure HRRR will be a must for American users!

The new hurricane tracker is based on ECMWF forecast and past track.
https://www.ecmwf.int/en/forecasts/charts/tcyclone/tc_plumes?facets=undefined&time=2022022100,0,2022022100&unique_id=05S_EMNATI_2022
I thought the previous one was based on NHC data. But I was may be wrong.
Are the wind speeds really using the Safir-Simpson scale in Windy as it is mentioned in the presentation of the Hurricane tracker? I have not found in ECMWF literature any information about it. Only that "Intensity estimates are based on the raw 10m wind speeds in model output; because of resolution limitations the resulting categories often provide an underestimate the true".

Concerning HRRR the only issue I found is the absence of past data to get a good comparison with a local weather station. The dotted lines are shown 1 or 2 hours back which is not enough for a good comparison. For example:
.
I have not seen what you mean with "Fixed bounds for local models".

[marekd]

@idefix37 As usually, thank you! :-)

• just for to be sure, we will check the Safir-Simpson scale in a HT

• HRRR archive will be fixed soon, thank you for pointing it out

• I have not seen what you mean with "Fixed bounds for local models".

  then it is fixed correctly :-)

[idefix37]

@marekd said in v35.0.0:

@idefix37

• just for to be sure, we will check the Safir-Simpson scale in a HT

There is an other reason for reconsidering the reference to the Safir-Simpson scale. For ranking tropical cyclones, in other areas than the Atlantic and the NE Pacific, different scales are used:
https://en.m.wikipedia.org/wiki/Tropical_cyclone_scales

[marekd]

@idefix37 You are right. Unfortunately, we will hide a hurricane forecast part for the next release until we solve this issue (we will keep the history as it is in production now). We think it is better to show nothing than stupidity. We are going to fix it and release the fix asap. Thanks again!

[Liam.pankhurst]

@marekd oh Thankyou that's awesome.
Is there any idea of when that might be happening?

[marekd]

@liam-pankhurst We just test data post-processing, then it is added to the client and sent to our internal testers. After this process, it can go to the production. It usually takes 3-6 weeks (depends on how many bugs are in data). But no guarantee! It's just behind-the-scenes info.

[Liam.pankhurst]

@marekd awesome, thankyou

[rittels]

@rittels, @jakubvrana, @vicb, @johnckealy, @marekd

W.picker.getParams() and W.rootScope.pickerLocation no longer works.

Use W.store.get("pickerLocation").

[vicb]

@rittels I'm using windyPicker.on("pickerMoved", ({ lat, lon }) => {...}) and it still seems to work, do you confirm ?

[rittels]

@vicb

Hi. Yes it still works.

Sometimes you need the picker position.

For instance when your plugin opens, you can check if the picker is already open and get the coords, then store.get("pickerLocation") is useful. It returns null if the picker is closed.

Or: If a location is searched, then the detail plugin opens, which also opens the picker. The picker.on("pickerOpened",..) is then not triggered.

[marekd]

Beta test is closed, v35.0.0 has been released. Thank you all for your help!