Discuss Options for Precipitation Tables going into following day

[shadkeene]

6-hour precipitation tables are based on Zulu time. So, for instance in Medford, OR under Pacific Daylight Savings Time we have 6-hour precipitation time brackets as:

• 5am-11am (12Z-18Z)
• 11am-5pm (18Z-00Z)
• 5pm-11pm (00Z-06Z)
• 11pm-5am (06Z-12Z)

And for Fort Worth Texas (CDT) we have: -7am-1pm (12Z-18Z) -1pm-7pm (18Z-00Z) -7pm-1am (00Z-06Z) -1am-7am (06Z-12Z).

In its current state, beta.weather.gov shows this for Medford, OR on day 1: and shows this all following days where precipitation amounts are available:

We probably want to choose the breakpoint that most closely corresponds with our day/night breakpoints in the daily forecast (6am-6am). So for Medford, we'd want to use 12Z-18Z, 18Z-12Z, etc, instead of the current setup which starts at 18Z.

But what if the current time is 9am, so precipitation forecast for 6am-9am is no longer relevant. Do we reduce the 6hr amount by half, to more accurately reflect the situation? Or do we leave the full 6hour amount in there, even though we're showing only 3 hours. Or do we keep the full 6 hour time in there, even though some of those hours are in the past? @coreypieper and others, we need to discuss this and find a solution.

Here's the current setup for Fort Worth, TX for the first day: and all other days:

Acceptance criteria

• [ ] Tests have been implemented or modified to capture the bug
• [ ] Changes have been tested for accessibility

[eric-gade]

One (small) question I have is this: if the API gives us precip amounts for a 4 hour period, does it make sense to simply halve that amount if we reduce that period to the first (or second) 2 hours? In other words, could it be the case that most of the precipitation actually might accrue in the first 2 or last 2 hours, and so averaging and dividing doesn't make sense?

[coreypieper]

...could it be the case that most of the precipitation actually might accrue in the first 2 or last 2 hours, and so averaging and dividing doesn't make sense?

This one is more-often the case, so splitting generally won't work well.

[greg-does-weather]

Some ideas we discussed:

1. Duplicate rainfall data between days to ensure that the tables are meaningful on their own, without requiring the user to look back and forth between two days' worth of tables.
   • Risk: Hourly labels could get confusing if the same hourly range (eg, 5am - 11am) is present twice
2. Add QPF as a row to the hourly table, where a QPF cell spans however many hours it's supposed to
   • Risk: Could be confusing that the cell span applies to the six hours cumulatively rather than individually
   • Risk: Would need to figure out how to indicate that the first cell might actually begin in an hour before the start of the table (eg, if the QPF is for 4am to 10am, but the table begins at 6am)
3. Look to forecast.weather.gov for inspiration for visualization. It uses a bar graph where the Y axis represents precipitation probability, the X axis represents time, and a label spanning each 6-hour segment indicates the QPF forecast for that time period

For now, we're going to push this back and look at it again when we get into visualizations. It seems like there's a there there.

[greg-does-weather]

@colinmurphy01 I've moved this back to the backlog, but maybe it should move elsewhere since it's waiting? Not sure how we manage that.

[colinmurphy01]

Per discussion, assigning to @greg-does-weather to explore prototypes for ☝.

Then we will discuss the design question - it just says time (5am) doesn't say what day? Do we need to add labels.

[greg-does-weather]

I think this is ready to move back to product/design. In my environment, you can see both the precipitation data incorporated into the hourly table and the precipitation table expanded to always cover at least 6am to 6am (except for the first day, where it begins at the top of the previous hour). Best way I've found for exploring it is to look for an area where it's currently raining on radar.weather.gov and then go there in my environment.

[greg-does-weather]

@colinmurphy01 I don't have this in my environment anymore, but I can put it back so we can decide what to do. This ticket's been in review for a while and it seems like we should either move on it or close it.

[colinmurphy01]

@greg-does-weather were you able to redeploy this solution to your environment?

[greg-does-weather]

Not yet. I tried this morning but something went sideways so it's not working. I'll try to look into it later today, but it might be Tuesday before it's ready.

[shadkeene]

@greg-does-weather this mentions "blocked". Are we holding on this, for the graphs? Will the graphs address this issue in terms of skipping morning precipitation for some areas?

[partly-igor]

We will need need to adjust that component for the precip types and adding graphs – but the timing issue is still going to be a question here, of which time blocks we display particuarly for "today".