Pirate-Weather / pirateweather

Code and documentation for the Pirate Weather API
Apache License 2.0
617 stars 27 forks source link

V2 API General Feedback #155

Closed cloneofghosts closed 3 months ago

cloneofghosts commented 4 months ago

Describe the issue

I'm sure you already have a list of things to fix/implement on the V2 Alpha endpoint but here's a list of things that I noticed:

If anyone else is using the V2 Alpha API feel free to add things that you've run into. Also for things that are fixed on the V2 Alpha endpoint already do you want to close the issue or leave it open until it launches? I'm fine with leaving it open but it would clean up the issue list and the project list if marked as complete.

Acknowledgements

cloneofghosts commented 4 months ago

@alexander0042 I'm guessing this is something you're working on? Been getting a Internal Server Error message whenever I try to visit the V2 endpoint URL and the V2 dev URL still does not work.

alexander0042 commented 4 months ago

You guessed right- I was pulling together a paper for a conference last month, and then away skiing (and checking the weather constantly) this week. Back at this next week, so should be able to start checking some of these off! I really appreciate you putting this list together, since I'll let me keep track of the main things ✅

cloneofghosts commented 3 months ago

@alexander0042 The V2 Alpha API has been returning an Internal Server Error for the past day or so. Did you push up an update which broke things or did it just happen to break by itself?

EDIT: Is the model runtime section in the flags block broken or something? This is what I see:

"sourceTimes": {
"hrrr_subh": "2024-03-04 18Z",
"hrrr_0-18": "2024-03-04 16Z",
"nbm": "2024-03-03 05Z",
"hrrr_18-48": "2024-03-05 06Z",
"gfs": "2024-03-04 12Z",
"gefs": "2024-03-04 16Z"
},

HRRR 0-18 doesn't have the same time as the sub-hourly HRRR and 18-48 has a future date. NBM it says hasn't had any new data in over a day when it should be the same time as HRRR_subh

Has the NBM data stopped integrating? I thought the model ran every hour and under sourceTimes I see this "nbm": "2024-03-05 17Z",

I thought that the API would fall-back to use other sources if the one used in the forecasts hasn't been updated in x number of hours. From what I can tell the data is still somewhat accurate but the temperatures are way off.

EDIT: Seems like NBM has broken again and it looks like GFS is also broken. I'm also a bit confused as to where some of the currently data is coming from. Some of it seems to be from the hourly data but others (temperature and precipIntensity) seem to come from somewhere else. Is that data coming from a different model which would explain why the temperature seems to be pretty off when compared to the live API.

cloneofghosts commented 3 months ago

Ah you moved it to the dev endpoint so disregard my comment.

alexander0042 commented 3 months ago

Yea, there was a bit of chaos there while I tried a bunch of different things. Adding NBM in turned out to be a bit more complex than I expected, since it meant that which model was being used to grab a specific variable became much more dynamic, instead of just HRRR/ GFS. But it's all in there now, and crucially, the infrastructure to actually serve data from it is now in place, which was a key step. I also ended up focusing more on response speed than I initially planned, since the times were pretty good, I wanted to see how fast I could get them (answer- real quick, at least 10x the speed of the old one, sometimes closer to 50x!)

If it makes sense to you, I'm going to start a new issue thread and pin it with some notes on version 2. I can't say enough how great your details are in this one, and I'll go through them one by one now that all the infrastructure is in place, but my ideas is adding some notes for others to a top level comment (or maybe as a discussion)?

cloneofghosts commented 3 months ago

Sure you can create a new issue for notes and v2 feedback. Will close this one so you can create your issue.