Labeling vertical and horizontal dimensions of a facet_grid display.
Rob James
faceted graph? Facet_grid kindly provides the various categorical values
relevant to the facet, but does not annotate the overall graph with an
indication of which variable is being used as the horizontal or vertical
dimension of the matrix of facets.
Consider:
ggplot(data=diamonds)+geom_line(aes(x=carat, y=price))+
+ facet_grid(color ~cut)
What I am looking for is a means to annotate the horizontal dimension of
the matrix of graphs with "cut" (or some other arbitrary string) and on
the vertical axis says "color" or an arbitrary string. I am referring
here not to the X/Y axes of each graph, but to the set of graphs.
Right now, the strategy seems to rely on having categories that imply
the variable name. However, this is often not the case, for example
when one has numeric values in both the horizontal and vertical dimensions.
My halting attempts to use geom_text resulted in sample text which
showing up in each facet, rather than once for the whole matrix of graphs.
I would welcome suggestions.
Suggestions?
Brian Diggs
On 6/14/2011 8:42 AM, Rob James wrote:
> Is there a way to label the horizontal and vertical dimensions of a
> faceted graph? Facet_grid kindly provides the various categorical values
> relevant to the facet, but does not annotate the overall graph with an
> indication of which variable is being used as the horizontal or vertical
> dimension of the matrix of facets.
>
> Consider:
>
> ggplot(data=diamonds)+geom_line(aes(x=carat, y=price))+
> + facet_grid(color ~cut)
>
>
> What I am looking for is a means to annotate the horizontal dimension of
> the matrix of graphs with "cut" (or some other arbitrary string) and on
> the vertical axis says "color" or an arbitrary string. I am referring
> here not to the X/Y axes of each graph, but to the set of graphs.
There is something similar to this that you can do:
ggplot(data=diamonds)+geom_line(aes(x=carat, y=price))+
facet_grid(color ~cut, labeller="label_both")
It puts the variable name in the label for each row/column of the facet,
rather than a single label for the whole faceting.
> Right now, the strategy seems to rely on having categories that imply
> the variable name. However, this is often not the case, for example when
> one has numeric values in both the horizontal and vertical dimensions.
>
> My halting attempts to use geom_text resulted in sample text which
> showing up in each facet, rather than once for the whole matrix of graphs.
>
> I would welcome suggestions.
> Suggestions?
>
--
Brian S. Diggs, PhD
Senior Research Associate, Department of Surgery
Oregon Health & Science University
Rob James
Thanks Brian!
Can I ask where you found this?
I see the labeller= option in the ?facet_grid documentation, but I do
not see a list of valid values. I don't have Hadley's book at hand, so
perhaps the details are there.
Many thanks,
Rob
Brian Diggs
>
>
>
> Thanks Brian!
>
> Can I ask where you found this?
>
> I see the labeller= option in the ?facet_grid documentation, but I do
> not see a list of valid values. I don't have Hadley's book at hand, so
> perhaps the details are there.
I'm not sure where I first learned about this. Probably on the mailing
list. It's not in the book (or at least not in the section (7.2) on
faceting). And you are right that the web site only mentions that it is
an option but doesn't indicate what is valid to pass to the option.
There are discussions on the mailing list, and oblique references on the
wiki, but nothing that is very definitive.
Maybe I should write up a page for the wiki that describes what I know
about it, so at least there is something to look at.
Brandon Hurr
Maybe I should write up a page for the wiki that describes what I know about it, so at least there is something to look at.
Brian Diggs
> Yes please.
>
> Brandon
https://github.com/hadley/ggplot2/wiki/labeller
This is descriptive, not proscriptive (I am not delusional that I think
I can tell Hadley what to do). Also, it'd be nice to embed examples of
what each of those outputs look like in the page. I don't know how to
do that with the wiki, but anyone is welcome to add that (or anything
else that I missed).
--
Hadley Wickham
> can tell Hadley what to do). Also, it'd be nice to embed examples of what
> each of those outputs look like in the page. I don't know how to do that
> with the wiki, but anyone is welcome to add that (or anything else that I
> missed).
This looks great, thanks! I think this is a good choice for a wiki
page - I don't think it belongs naturally in function-level
documentation because it applies to multiple functions, and goes into
more depth than you'd normally want in an example.
Hadley
--
Assistant Professor / Dobelman Family Junior Chair
Department of Statistics / Rice University
http://had.co.nz/
Zack Weinberg
>> This is descriptive, not proscriptive (I am not delusional that I think I
>> can tell Hadley what to do). Also, it'd be nice to embed examples of what
>> each of those outputs look like in the page. I don't know how to do that
>> with the wiki, but anyone is welcome to add that (or anything else that I
>> missed).
>
> This looks great, thanks! I think this is a good choice for a wiki
> page - I don't think it belongs naturally in function-level
> documentation because it applies to multiple functions, and goes into
> more depth than you'd normally want in an example.
I agree, this is very nice! I was just looking for the functionality
provided by label_parsed, as it happens :)
I do think some of this belongs in function-level documentation:
specifically, each of the stock label_* methods should have their own
?page, and the list you have under "Built-in acceptable values" should
appear, in its entirety, in ?facet_grid (and ?facet_wrap, if and when
it grows the same feature).
-- This is actually a general problem with the ggplot documentation,
both the ?pages and the website: reference documentation needs to
repeat itself a lot more than it currently does. Every optional
argument to a function needs to have at least one sentence of
explanation in the documentation of that function, EVEN IF the primary
documentation of that argument is somewhere else. Current bad
examples:
?geom_step:
# Arguments:
# ...: other arguments
-- What other arguments? Where do I look for documentation on what
the possibilities are and what happens to them? Presumably all other
arguments are passed on to some other function (as is the common
pattern in R) but I have no idea which one. (Some of the geoms'
documentation says "...: ignored", e.g. geom_linerange; that's more
helpful than just saying "other arguments" but leaves me wondering
*why* other arguments are ignored rather than rejected.) It would
suffice, here, to write "...: all other arguments are passed on to
<name of function>". Then I can go read that function's page for
details.
?facet_wrap:
# Arguments:
# facets: NULL
# as.table: NULL
# drop: NULL
This is obviously bad. It's particularly bad here because 'facets' is
the primary knob for this function! I can deduce its approximate
syntax from the examples (but not its *precise* syntax -- what happens
if I write "cyl ~" instead of "~ cyl", for instance? What happens if I
write "color ~ cut" instead of "~ color + cut"? and I can also deduce
what "drop" does, but I remain completely in the dark as to what
"as.table" does.)
I want to emphasize that this kind of thing is bad EVEN IF there is
some other documentation page where an explanation can be found,
because how do I know which page to look at? Keep in mind that when
people are reading the reference manual instead of the ggplot2 book,
it's because they do more or less know how to use ggplot2 but they
cannot remember precisely how to do some specific thing; and do also
please keep in mind that not everyone has the book (or, in my case,
the book is currently on loan to someone else).
Having complained a whole lot, allow me also to say that if there's an
organized effort to improve the ggplot2 documentation, I would be
delighted to chip in.
zw
Hadley Wickham
> both the ?pages and the website: reference documentation needs to
> repeat itself a lot more than it currently does. Every optional
> argument to a function needs to have at least one sentence of
> explanation in the documentation of that function, EVEN IF the primary
> documentation of that argument is somewhere else. Current bad
> examples:
The move to roxygen and Jake's help should resolve a lot of these
problems - they are mostly caused by over-automation, so I don't even
notice what important parameters are undocumented.