Color tree by measurements

[huddlej]

Description

Originally suggested by @trvrb on Slack:

General feature I've wanted for the Measurements panel is to be able to click on a row at the y-axis (maybe with a little gear or spotlight following the name) that would then color the tree by this row's measurements.

This feature is part of a class of features that would allow the measurements panel to control the display of other panels. This specific feature would function like a combination of 1) a filter to all tips in the tree that appear as test viruses in the selected row(s) and 2) a dynamically-defined coloring of tips (and the map and frequencies) by a quantitative color scale corresponding to the range of measurements in the selected row(s).

This functionality would be analogous to the nextflu implementation of gears that users can click on to display only tips that have measurements against that reference.

Design questions

• What color do we display for a tip with multiple measurements? How does the nextflu implementation deal with this?
• Should we allow users to select multiple rows from the measurements panel?
• How should we present the option to select a row to filter/color the tree (e.g., a "gear or spotlight"?)
• How do we handle selection of a measurements row that is not grouped by reference strain (e.g., grouped by reference clade)? This relates to the earlier question about whether to support selection of multiple rows.
• How should we highlight the reference strain(s) in the tree to indicate their distinct nature as a reference point for the filter and coloring?
• How should we save the state of the selected row(s) in the URL? Thinking ahead to when we've implemented Add URL parameters for the measurements panel options #1815.
• How can we support display of imputed titers from models like nextflu produces? Some options include:
  • precompute these imputed titer values per reference strain (in a workflow) and store them in the measurements JSON as a separate collection with an option to group by reference strain
  • precompute the imputed titer values per reference strain (in a workflow) and store them as coloring in the main Auspice JSON
  • impute titer values on the fly like nextflu does using only the substitution model

[huddlej]

I chatted with @tkanderson today at Options and he upvoted this feature request as high priority for their work. He is interested in the full nextflu functionality where the tree can display the raw measurements and imputed titer values per reference strain.

[joverlee521]

We had a small group meeting today that went over the design questions (meeting notes).

Summary of v0:

Clicking on a single measurements row will inject a dynamic color-by. The color scale will be based on the 5-95 percentile of all values in the single measurements collection so that outliers don't skew the coloring. This is based on all measurements instead of just measurements in the current row to ensure the color scale is stable when switching between rows. Each strain's color will be based on the mean of the strain's measurements in the selected row. Strains without measurements values will be greyed out. If the grouping value is a tip in the tree (i.e. a reference strain), we will use a grey/black crosshair icon to highlight the reference. No special functionality will be added for titers from models, they can just be added as a separate measurements collection.

Things left for future versions:

• URL params
• Dynamic tiered color-by dropdowns per measurements collection
• Coloring of internal nodes when using titers from models
• Selecting multiple rows as coloring

[joverlee521]

I think the cleanest path for this would be to update calcColorScale in src/util/colorScale to support measurements colors so that this can also use the central changeColorBy thunk for updating coloring. Since types were added to src/util/colorScale in #1864, I'm going to pursue adding types for measurements to make this easier. (I've already been learning TypeScript by tinkering with types for measurements anyways.)

Another thing that I'm considering is refactoring where the measurements are being filtered and grouped. This is currently happening within the front-end MeasurementPlot component, which made sense when I first implemented the measurements panel since this was the only component that needed the grouped measurements. However, since the grouped measurements is needed for the coloring calculations, it would make more sense for this data to be in the central Redux state. This is especially true when we want to add URL params for measurements colorings in the future.