3rww / rainfall Goto Github PK

Currently, timestamps (including timezone offset) are returned using the RFC 3339 standard (ISO-8061 format). Excel doesn't automatically parse this out, requiring an extra step for end-users of the CSV download. We can return a spec that Excel will automatically parse.

Need to make the distinction between active and inactive gauges in the various download contexts.

• Real-time rainfall should only be able to download from active gauges.
• Historic should handle both active and inactive (because we have data for previous gauges).
• The map symbology and labeling should make it clear what is active/inactive.

This requires one of three approaches

• handling pagination of events data in this app
• forgoing pagination in the API and just returning the entire list
• creating another rainfall events endpoint that returns the entire list

Two gauges were moved this spring.

• Bell Acres >>> West Deer
• Pitt >>> Schenley

This has been updated in the 3RWW API. However, this app uses static copies of that data.

Change that so we use the dynamic sources.

On map hover or click, in a map pop-up, show charts for:

• Year-to-date
• Annual averages for last 5 10, and 20 years
• Amount for last recorded rainfall event
• ???

Having any of this summary data at the ready will require

• some new API endpoints,
• semi-regularly updated materialized views in the database, since the queries behind these stats would be massive

The ISO formatting isn't Excel-friendly. Return results with something that is human readable and a standard.

See 3rww/data-api#5

Modelers need rainfall for an area

On hover or click, withing a map pop-up, show a chart for:

• rainfall over the last 12 hours
• ???

Workflow-oriented documentation

• Mimic playback presets available in the legacy site
• Include playback controls
• Have a "quick" download option available
• Auto-request this data with the page load
• Make a killer animation!

Hello Christian,
How are you.
Very pleased to read about your work, very fascinating. I have a question, how do you correct the radar data? Is there a description of the method, or a relevant published article?

best wishes,
Xing WANG

Enable the ability to convert from the current long format to a wide format, where sensors and metadata are in columns (like the legacy site)

Create a new context/view that is:

• unifies the workflow for provisional and qa/qc'd data; a "best of"
• puts the rainfall events front-and-center
• emphasizes visualization of stats between sensors and over time
• enables comparison and diffing between different events.
• by default has no geographic constraints: all gauges, all pixels

This would use a lot of the existing and planned components under the hood, but re-arrange them to support a new, exploratory workflow.

This could also possibly be done (or at least prototyped) in a Dash app.

...and have selections in the dropdowns highlight them on the map

A key feature of this viewer is providing shortcuts to date-time ranges of known rainfall events. This information comes from Vieux (we just need to pull it into the database and provide through rainfall-api.

From that data, and with other data attributes on storm events (e.g., we know the name of the storm was Hurricane Ivan, or we know there was flooding reported), have text-based and visual ways to search and select events (e.g. timeline).

Create a map legend component; Control it with preset scale options and maybe a few color options--control in the nav bar.

Consider being able to switch from showing rainfall totals to DDF.

• Expose playback controls for requested/downloaded rainfall data.
• Make a killer animation!

See issue 3rww/data-api#35. Requests may be failing due to a memory issue on the server.

Implement the geography-based pixel selections in the rainfall web app.

This tasks depends on 3RWW Data API task #30.

Implement interactive charting for rainfall results:

Get those rainfall results showing in 3D! Need to work-around the transparency issue for pixels with no-data (simply by eliminating those geometries for results, which means separating the results and hover layers in the stylesheet)

Longer term: consider using color and height to represent different things: e.g., DDF for a default return period (or a comparable one if we have an event on record) for color, and height for rainfall

Need to update the layout classes to adjust for appropriate screen breakpoints.

Timestamps are showing a 3 hour difference between rain gauges and radar pixels (real-time data only).

This is likely an error in the timezone conversion on the real-time gauge data (it comes in as PST).

Investigate results with many, many decimal places (many zeroes). Shouldn't be more than what Datawise and Vieux show. This may be happening in the API, but at the very least we should truncate for download.