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

Inconsistent behavior of geom_line and geom_smooth wrt. color #498

Closed
aecay opened this issue Apr 16, 2012 · 7 comments
Closed

Inconsistent behavior of geom_line and geom_smooth wrt. color #498

aecay opened this issue Apr 16, 2012 · 7 comments
Milestone

Comments

@aecay
Copy link

aecay commented Apr 16, 2012

geom_smooth does not pick up its color from a scale_color_manual unless color is explicitly added to the aesthetic; geom_line does. Perhaps this is best explained by illustration:

foo <- data.frame(x = rnorm(30),  y = rnorm(30),  z = 1:3)
foo$z <-  factor(foo$z)
# the below graph has blue smooth lines
ggplot(foo,  aes(x = x,  y = y, linetype=z)) + geom_smooth() + 
  scale_color_manual(values = c("black"))
# the below graph has black lines
ggplot(foo,  aes(x = x,  y = y, linetype=z)) + geom_line() + 
  scale_color_manual(values = c("black"))
# this makes the first line black, but the other two don't show up
ggplot(foo,  aes(x = x,  y = y, linetype=z, color = z)) + geom_smooth() + 
  scale_color_manual(values = c("black"))

It seems like a bug for the two functions to behave differently, but I can't tell which one is misbehaving. I would prefer if they both behaved like geom_line, because I am trying to "zero out" all the colors in a graph with the scale_color_manual (for a dead-tree version of a graph). If there is an alternative, better way to do that, I would also be interested in hearing about it...

Thanks.

@hadley
Copy link
Member

hadley commented Apr 16, 2012

I'm still not sure what's causing the bug, but if you just want black lines, do geom_line(colour = "black")

@wch
Copy link
Member

wch commented Apr 16, 2012

Is this a bug? I think it might be expected behavior.

In this case, the color in scale_color_manual shouldn't set the color of the line. This is because no variable is mapped to color -- therefore doing stuff to the color scale has no effect. geom_smooth and geom_line both behave the same way -- it's just that the default color of geom_smooth is blue and the default color of geom_line is black:

foo <- data.frame(x = rnorm(30),  y = rnorm(30),  z = 1:3)
foo$z <-  factor(foo$z)
# Setting color in scale has no effect
ggplot(foo,  aes(x = x,  y = y, linetype=z)) + geom_smooth() + 
  scale_colour_manual(values = c("red"))
ggplot(foo,  aes(x = x,  y = y, linetype=z)) + geom_line() + 
  scale_colour_manual(values = c("red"))

# Setting it directly works
ggplot(foo,  aes(x = x,  y = y, linetype=z)) + geom_smooth(colour="red")
ggplot(foo,  aes(x = x,  y = y, linetype=z)) + geom_line(colour="red")

As for the issue, regarding why the other lines don't show up when colour is mapped and the scale only has one value, I think this is happening because the other values are assumed to be NA if they're not specified.

# Only one line shows up, in black
ggplot(foo,  aes(x = x,  y = y, linetype=z, colour = z)) + geom_smooth() + 
  scale_colour_manual(values = c("black"))

# First and third lines show up
ggplot(foo,  aes(x = x,  y = y, linetype=z, color = z)) + geom_smooth() + 
  scale_color_manual(values = c("black",NA,"red"))

I think it would probably be a good idea to print a message when not enough values are specified in a discrete scale.

Update: I checked 0.8.9, and the behavior is the same.

@hadley
Copy link
Member

hadley commented Apr 16, 2012

Agreed, this is expected behaviour. I'm not sure if a warning would be the right thing to do:

How would that differ from the following bevahiour?

ggplot(foo,  aes(x = x,  y = y, linetype=z, color = z)) + 
  geom_smooth() + 
  scale_colour_manual(values = "black", na.value = "red")

But maybe that behaviour is undesirable?

@wch
Copy link
Member

wch commented Apr 18, 2012

I have a hard time envisioning situations where using na.value this way would be desirable... when would you want to pass a vector with NAs to values and then tell it to substitute the NAs with something else?

I guess the NA substitution makes sense for continuous color scales, but in those cases, the NAs are calculated from the scale -- they're not manually specified, as is the case here.

@hadley
Copy link
Member

hadley commented Apr 18, 2012

Good point. I'll make the fix.

@aecay
Copy link
Author

aecay commented Apr 19, 2012

Hrm. I have lost track somewhat of the discussion. I think I understand why the geom_smooth is blue whereas the geom_line is black.

From the point of view of a user, it would be convenient if a quick print-suitable version of a graph could be generated by last_plot() + theme_bw() + <something>. That is what I was trying to use the scale_color_manual to do -- to remove all the color from the plot. So, I think that the missing piece is one or both of:

  1. making geom_smooth and friends read their default color from the theme, instead of having a global default. This would let them be black in theme_bw, but blue in theme_default
  2. adding a scale_color_constant function, which would override any color that is specified by an aesthetic with a single value (in this case black). This has the advantage of avoiding the need to specify black in each geom that makes up the graph.

That turns this from a bug report into a feature request, I suppose. I've looked at the code involved, and while I wouldn't say that I have wrapped my head around all its object-orientedness, I could take a crack at implementing these things if there is interest in them.

@hadley
Copy link
Member

hadley commented Apr 20, 2012

The manual scales issue is now #512.

Currently, there's no way to change the default aesthetics of geoms on mass. This may be something that will be possible after the layer rewrite. Could you please file that as a separate issue, outlining your use case?

Thanks!

@hadley hadley closed this as completed Apr 20, 2012
@lock lock bot locked as resolved and limited conversation to collaborators Jun 20, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants