I want to get data of convPrecip(rain) with point-forecast api but, data is different

Korina

@yzoh26dett @sudarlife Hello, are you please comparing data from standard non Premium version of Windy? Could you please give us example for lat,lon and values from forecast that you got from API and Windy website?

yzoh26dett

@korina
Hi,
Yes, I'm getting data from non Premium version of Windy.
Sure, these are the values I got.

35.6895 139.6917 is my latitude and longitude respectively.
API : 2021-09-07 09:00:00 (JST) "2.799828e-03(mm)" (executed at 2021 Sep 6th 13:52 JST)
Website : 2021-09-09 09:00 JST "0.53in" (checked at 2021 Sep 6th 13:53 JST)

Korina

@yzoh26dett Hello, what layer and model did you get the data from please?

marekd

@yzoh26dett Please keep in mind that for non-premium API point forecast requests, returned data are slightly modified and shuffled. It is done randomly with every single request, so it returns you different response everytime. What exactly is the issue? What does the API return you and what response do you expect?

yzoh26dett

@marekd said in I want to get data of convPrecip(rain) with point-forecast api but, data is different:

@yzoh26dett Please keep in mind that for non-premium API point forecast requests, returned data are slightly modified and shuffled. It is done randomly with every single request, so it returns you different response everytime. What exactly is the issue? What does the API return you and what response do you expect?

yes of course I got that the data is slightly modified, and I just wanted to write a program which could be a reminder for me to bring my umbrella on a rainy day, so I don't care about the tiny difference of precip values

but somehow data I got is like this,

data from windy website (gfs) : 0.25 inch (about 6 mm) @ Sep 11th 2021 09:00 JST
data from API : 0.000023 mm @ Sep 11th 2021 09:00 JST

and this is not what I can use for my purpose (0.000023mm is not high enough for bringing umbrella lol),
so I just want to know if there is something I'm missing or it's like this (in the free version)
so I'm very happy if you help me with this problem

thank you

I use gfs model via API to get precipdata, like this.
data = {"lat": myLat,
"lon": myLon,
"model": "gfs",
"parameters": ["temp","pressure","precip"],
"levels":["surface"],
"key": myAPIkeyforWindy
}
header = {"Content-Type" :"application/json"}
raw_data = requests.post("https://api.windy.com/api/point-forecast/v2", json = data, headers = header)
json_data = raw_data.json()
df_data = pd.DataFrame(json_data,columns=['ts','temp-surface','pressure-surface','past3hprecip-surface'])

myLat = 35.6895
myLon = 139.6917

marekd

@yzoh26dett As I wrote above, returned data are slightly modified and shuffled. It means the order of data is different with every each request.

yzoh26dett

@marekd
unfortunately it seems you don't understand my point at all...
I don't care if it's "slightly modified and shuffled" or not at all...
and as I said above, my question is quite simple

these are the data I got via Wndiy API (myLat = 35.6895 myLon = 139.6917)
"date, temerature, air pressure, precip" like below

and temerature and air pressure value seems reasonable but only precip value is somehow too small even if it's slightly modified and shuffled because "0.000xx mm rain " doesn't make any sense, and this is exactly why I'm asking here.

If it's too much for you, I won't bother you anymore
but I showed all the parameters you asked and you only says "it's slightly modified and shuffled"
If I did something wrong or impolite things to you I apologize about that but did I?

date(JST)/ temp/hPa/precip(mm)
2021-09-10 00:00:00 	25.326162 	1007.150378 	0.000000
2021-09-10 03:00:00 	23.315333 	1013.010707 	0.000356
2021-09-10 06:00:00 	22.513396 	1014.847652 	0.000051
2021-09-10 09:00:00 	24.646636 	1016.048758 	0.000589
2021-09-10 12:00:00 	26.422427 	1017.250172 	0.000000
2021-09-10 15:00:00 	21.425998 	1017.784785 	0.000000
2021-09-10 18:00:00 	22.806458 	1014.359763 	0.000314
2021-09-10 21:00:00 	19.680203 	1014.101810 	0.000023
2021-09-11 00:00:00 	26.292525 	1015.839568 	0.000000
2021-09-11 03:00:00 	20.295875 	1007.026874 	0.000130
2021-09-11 06:00:00 	26.226146 	1014.942723 	0.000485
2021-09-11 09:00:00 	23.978381 	1016.626293 	0.000000
2021-09-11 12:00:00 	25.199939 	1014.956792 	0.003083
2021-09-11 15:00:00 	23.180884 	1015.012399 	0.000000
2021-09-11 18:00:00 	19.770917 	1012.648844 	0.000000
2021-09-11 21:00:00 	23.067594 	1009.683736 	0.000000
2021-09-12 00:00:00 	25.675872 	1015.034222 	0.000000
2021-09-12 03:00:00 	23.673601 	1013.201085 	0.000045
2021-09-12 06:00:00 	23.360019 	1016.757229 	0.000000
2021-09-12 09:00:00 	28.195922 	1013.649316 	0.000000
2021-09-12 12:00:00 	20.967406 	1013.257497 	0.000000
2021-09-12 15:00:00 	23.505053 	1012.835986 	0.000962
2021-09-12 18:00:00 	23.855205 	1007.343322 	0.000390
2021-09-12 21:00:00 	24.916117 	1006.516975 	0.000000

marekd

@yzoh26dett There is no reason to be rough. I understand the problem finally and found the problem. Units were incorrect. It should be fixed now. Thanks for pointing out the problem.

yzoh26dett

@marekd Thank you very much for your help and sorry for getting heated up.

cwpenergy

Hi, regarding this fix, my app is failing since this morning because of this unit change. I was expecting 'mm' instead of 'm'.

Has it been always like this?

Usually precipitation are presented as millimeter.

I would like to know since when it was the real value unit was meter instead of millimeter as expected?. I've been ingesting this data for a couple of months already.

Thanks

Vincent

marekd

@cwpenergy Hi, sorry for all problems you have. Unit was changed because it was wrong. The number value is still same without any change, just unit was changed. We will not change it again, it will preserve in current state. We try to do our best to not make breaking changes, but this was bug fix. Sorry again and thank you for your understanding.

cwpenergy

@marekd

So if I understand correctly from now on the unit will be meter (m)?
What happen with the past data? The unit was in millimeter, but in reality it was meter? Since how long, has it been like this?

marekd

@cwpenergy Yes, it will be in m since now. We have no past data, we have only current forecast. But if you store past data, just consider them in meters, nothing more. Values remain unchanged, only unit was wrong. As I can see you are an API user since 07/2020, so all the data you collected should be in meters. Sorry again, obviously precip in point forecast is not so imported for API users, otherwise it would be reported more often. We are so sorry for the inconvenience.