Skip to content

Add a new continuous colour/fill scale using colorbrewer colours #439

Closed
wants to merge 7 commits into from

6 participants

@jiho
jiho commented Mar 14, 2012

It fetches 6 colours from a colorbrewer palette and feeds them to gradientn. It gives very nice results even if the palettes were not intended for that use originally.

Ideally, the regular brewer scale should be able to deal with this: use scale_colour/fill_brewer() and provide a continuous or a discrete scale depending on the data... but this may run again into the problem that the data is only known at render time or something like this. Anyhow, I couldn't figure out how to do that with the current state of the code so a created new functions. The names (scale_colour/fill_brewerc) are clearly not very inspired so I am completely open to suggestions.

@jiho jiho Add a new continuous colour/fill scale using colorbrewer colours
It fetches 6 colours from a colorbrewer palette and feeds them to gradientn. It gives very nice results even if the palettes were not intended for that use originally.
0418d57
@jiho
jiho commented Mar 14, 2012

This is an example map produced with the "Spectral" palette (and stereographic projection in coord_map, Yay!):

image

For those who want to know, this is the average
temperature at the sea surface in summer.

@wch
Collaborator

I think you'll want to add an alias for the American spelling also: scale_color_brewerc

@hadley hadley commented on the diff Apr 11, 2012
R/scale-brewer.r
@@ -38,6 +38,30 @@ scale_fill_brewer <- function(..., type = "seq", palette = 1) {
discrete_scale("fill", "brewer", brewer_pal(type, palette), ...)
}
+#' @export
@hadley
Owner
hadley added a note Apr 11, 2012

Can you also add a few words to the main doc mentioning that it does both continuous and discrete variables?

@jiho
jiho added a note Apr 11, 2012

Is commit b5fe2d4 enough?

@hadley
Owner
hadley added a note Apr 11, 2012

Maybe mention that continuous colours are smoothly interpolated discrete colours, and have not be tested like the discrete colours have.

@jiho
jiho added a note Apr 11, 2012

OK, I expanded the description in commit afda6e9. Let me know if the text is OK.

(I also committed the .Rd file this time, while I forgot on the previous commit)

@hadley
Owner
hadley added a note Apr 11, 2012

Much better, but can you please break the documentation lines at ~80 characters?

@jiho
jiho added a note Apr 11, 2012

I think this should be the text editor's job (and TextMate actually does this quite well now) rather than mine (or yours) and I also feel that "justifying" text manually like this complicates diffs when one wants to add a word or two and has to shift every subsequent line... but I did ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@hadley
Owner
hadley commented Apr 11, 2012

I like the idea, but I'm not a big fan of the name (I don't like the compounding). Any other ideas?

jiho added some commits Apr 11, 2012
@jiho jiho Expand documentation of scale_brewer
As per Hadley's request: "add a few words to the main doc mentioning
that it does both continuous and discrete variables""
b5fe2d4
@jiho jiho Further expand the description of scale_brewer
Give more precisions regarding the intent of the original colours and how
ggplot2 modifies them (in the continuous case).
afda6e9
@jiho jiho Break lines at 80 characters f03b072
@jiho
jiho commented Apr 11, 2012

What about scale_***_distiller to signify that it goes a bit further than "brewer". That's not very discoverable (to say the least) but is kinda fun.

@jiho
jiho commented Apr 11, 2012

Just realized there might be some unintended association with Acrobat Distiller and the production of PDFs etc. Did anyone else think of this?

@jiho
jiho commented Apr 13, 2012

So, what about scale_***_distiller? Opinions anyone? I know I won't be able to find a better name, but native english speakers might.

@BrianDiggs

The only thing I can think of would require overhauling all the color/fill names: making the method of generation of the levels a suffix. So this would be scale_***_continuous_brewer, and the current scale_***_brewer would be scale_***_discrete_brewer; scale_***_gradient would be scale_***_continuous_gradient; etc. However, I am not sure that it would be worth it (even with the original names being maintained as aliases for backwards compatibility).

@hadley
Owner
hadley commented Jun 8, 2012

I like scale_*_distiller - if you make the change, I'm happy to merge the pull request.

@baptiste
baptiste commented Jun 9, 2012

It's always seemed kind of odd to me that Brewer palettes (and, if they were to be implemented, those of dichromat) would have their own special syntax in ggplot2. Should we consider the possibility of hard-coding these particular colour values in ggplot2 (or package scales, presumably), independently of the original package, and make a more consistent interface to all these special cases? It could even be part of a new colour package, defining a general structure to define and access colour palettes.
The weird contraints of RColorBrewer (n >=3 for "Set1" ??), the absence of continuous versions, and the inconsistent naming scheme are somewhat confusing in the otherwise consistent ggplot2 framework.

@jiho
jiho commented Jun 10, 2012

I agree with baptiste though. I think there should be two colour scales: scale_colour_discrete and scale_colour_continuous and the palette argument should determine which colours to use. For the discrete scale, the default could be "hue" and that would be the current behaviour, or the appropriate palettes from ColorBrewer or dichromat.

But that would probably break too much pre-existing code to be viable...

@baptiste

But that would probably break too much pre-existing code to be viable...

not necessarily: if scale_colour_brewer() became merely an alias for scale_colour_discrete(palette = ...) the more general functions would not have to break anything.

@hadley
Owner
hadley commented Jun 11, 2012

I don't particularly see the appeal of collapsing scales with rather different arguments in to one function - I think two many r functions do that already, and it's rather confusing. A function should do one thing well.

@hadley
Owner
hadley commented Jun 11, 2012

I don't particularly see the appeal of collapsing scales with rather different arguments in to one function - I think two many r functions do that already, and it's rather confusing. A function should do one thing well.

@jiho
jiho commented Jun 11, 2012
@baptiste

I don't particularly see the appeal of collapsing scales with rather different arguments in to one function - I think two many r functions do that already, and it's rather confusing. A function should do one thing well.

I'm not sure; if a grammar of graphic does such a good job at combining heaps of different plot types into a single, consistent framework with one top-level function (ggplot), why couldn't we aim for the same approach with scales?

It seems to me that choosing a colour scale is conceptually similar to choosing a type of plot and playing with variations, from a user's perspective.
Having a wild variety of different colour functions that inherit their name from the particular colour package they come from, or the type of scale that they represent, or something else, ... seems more confusing to me than one or two generic functions, with good defaults, that accept one consistent argument for fine-tuning the appearance (namely, the palette of colours).

@jiho
jiho commented Jun 13, 2012

It's quite different from the problem at hand but while we are on the topic of scales and since many interested parties are watching the topic, here is another suggestion: issue #578.

Edit: wow, it actually got automatically referenced here. Nice. Thanks github.

@hadley
Owner
hadley commented Feb 24, 2014

Could you please rebase/merge against master, re-document with the development version of roxygen2 (install_github("klutometis/roxygen) and resubmit?

@hadley hadley closed this Feb 24, 2014
@krlmlr
krlmlr commented Feb 25, 2014

@jiho: I have combined this pull request with your other change that implements reverse Brewer scales, fully maintaining your authorship (#830). @hadley prefers two separate pull requests. Would you mind if I prepared the two pull requests based on your changes?

@jiho
jiho commented Feb 27, 2014

Thanks for the work but since the two need to stay separate I've done two P-R already. Rebasing this one was kind of a mess but it is now done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.