Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modify temporal color scale & legend to focus on tip dates #544

Merged
merged 2 commits into from
May 1, 2018

Conversation

jameshadfield
Copy link
Member

Previously, the color range for temporal trees (i.e. the blue -> red) was based upon the root date -> the latest tip date. For deeply diverged trees (e.g. dengue, lassa) this meant that essentially all the tips were red and represented by the final box in the legend.

This PR modifies the legend to span the actual tip ranges. The colour ranges are skewed to mostly focus on this range as well. I think this results in much nicer and more useful displays, although for lassa all the recent samples are still red! cc @trvrb @sidneymbell

image

image

image

image

@jameshadfield
Copy link
Member Author

jameshadfield commented Apr 23, 2018

A possible extension to this is to space the domain (of the scale) according to num of tips, so that a lot of the color scale changes happen where there is densest sampling. For flu, this wouldn't change much, but for Lassa it would be very different.

E.g for Lassa (S), tipDates range between 1969 & 2018, and the domain (spaced according to sampling) would be 1969, 2009.283, 2011, 2011.99, 2012.99, 2013.57, 2015.99, 2016.148, 2016.83, 2018.18

image

zika:
image

flu:
image

@sidneymbell
Copy link
Contributor

This is lovely, far more informative. Thanks, @jameshadfield.

@trvrb
Copy link
Member

trvrb commented May 1, 2018

@jameshadfield --- I really like the direction here. Date coloring was completely uninformative for some builds. A couple thoughts:

  1. I completely see why you set the color ramp to reflect tip sampling. Otherwise, http://localhost:4000/lassa/s?c=num_date will still give little discrimination in recent samples due to the presence of the single isolate from 1969. Still, seems somewhat bespoke relative to the rest of the app to have a non-linear colorBy.

  2. Generally, it seems like this issue should be addressed in the colorBy export. Ie should colorBy reflect all nodes? Or should it be clamped to tips? Should it be a linear mapping of domain to range? Or should it be weighted by sampling?

I like our defaults of all nodes and linear. But giving the option for the others seems like the more general way to address this.

I'm happy to merge this now and address point (2) with time.

@trvrb trvrb merged commit 970abb7 into master May 1, 2018
@trvrb trvrb deleted the temporal-colour-scale branch May 1, 2018 22:49
jameshadfield added a commit that referenced this pull request May 8, 2018
jameshadfield added a commit that referenced this pull request May 8, 2018
* 554:
  reinstate branch thickness changes. Closes #544
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants