-
Notifications
You must be signed in to change notification settings - Fork 633
Legend combining fill.name and group.name when ggplot keeps fill.name only #168
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
it seems to me that the best approach would be to just assign the plotly name to be "[1, 360]" etc for each of the traces generated by the geom_polygon. So the rule can be: if there is another legend aesthetic other than group (in this case, fill), then use that for the trace name; otherwise use the group. |
We should probably try to find some more examples of mixed legend entries. In the future, this might end up being a plotly map type (cc @etpinard) which might have a different conversion with more sensible traces + legend items |
@tdhock did you're latest stuff clear this up? |
@chriddyp this is most likely due to my recent pull request where I added some code to avoid redundant legend entries. https://plot.ly/~cpsievert/430/collisions-reported-in-new-york-city-2014/ |
Great news, thanks very much! Janet |
@jcp1016 reported a very interesting issue which occurs when converting this awesome map:

The ggplot code being
The entire project can be found at https://github.com/jcp1016/Collisions (code lives in "Main.Rmd").
She cites https://github.com/hadley/ggplot2/wiki/plotting-polygon-shapefiles for the choice of aesthetics and using geom_polygon.
As is, the ggplotly conversion (https://plot.ly/~marianne2/824/collisions-reported-in-new-york-city-2014/) looks good for the plot itself, but the legend is wrong: it's a cross product of
fill.name
andgroup.name
, where the ggplot only representsfill.name
in the legend...@chriddyp @tdhock @cpsievert I would love your ideas on how to approach this. I definitely don't want to hack something that would make the legend work just in this case. I think it makes sense to include
group.name
in the legend in general. Would we want to give up on 'recreating' legends logically and, instead, retrieve the ggplot legends and translate them 'directly'?For your information, showing below the resulting ggplot without

group
aesthetic argument:The text was updated successfully, but these errors were encountered: