-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Improvements to qualitative color scaling #3826
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
Comments
Hmmm, I think I'd prefer to take the same approach as |
Yea, so something like |
I was thinking of a scale function |
As discussed here, if we make this part of ggplot2 3.3.1 we shouldn't change the default color scales. Also, I'm not sure if @hadley's comment #3826 (comment) has been addressed in the PR. |
…tOption('ggplot2.discrete.[fill/colour]') argument, closes tidyverse#3826
scale_[fill/color]_discrete
currently default toscale_[fill/color]_hue
. While this is a great default when there are a large number of levels to encode, it's not a great default there are just a few (i.e., it's not colour-blind safe or aesthetically pleasing compared to carefully chosen qualitative palettes like colorbrewer or Okabe-Ito). In the event there isn't already a "blessed" ggplot2 scale (e.g.,scale_colour_brewer()
), the usual way to override the default is with a custom qualitative colorscale is to usescale_[fill/color]_manual()
, but this also isn't ideal for situations where you don't want to make any assumptions about the number of levels to encode (i.e.,scale_[fill/color]_manual()
errors if there are more levels than color codes).I'd like to propose that
scale_[fill/color]_discrete
gain a new argument, saycodes
, that would accept a vector of color codes. In the eventcodes
is longer than the number of levels to encode, it would effectively bescale_[fill/color]_manual
; otherwise, it would effectively bescale_[fill/color]_hue
. Moreover, I think it would make sense forcodes
to default to something sensible like Okabe-Ito.It seems the implementation for this would be relatively straight-forward (see here for a proof-of-concept). If there's interest in pursuing this idea, I'd be happy to start a PR.
The text was updated successfully, but these errors were encountered: