Legend combining fill.name and group.name when ggplot keeps fill.name only

[mkcor]

@jcp1016 reported a very interesting issue which occurs when converting this awesome map:

The ggplot code being

ggplot(map_df) + 
        aes(long, lat, fill=CollisionRange, group=group) + 
        geom_polygon() + 
        geom_path(color="white", linetype=1, size=0.25) + 
        ggtitle("Collisions Reported in New York City - 2014") + 
        xlab(NULL) + ylab(NULL) + coord_equal() + 
        scale_fill_brewer() + 
        theme(axis.ticks = element_blank(), 
              axis.text.x = element_blank(), 
              axis.text.y = element_blank(), 
              legend.title=element_blank())

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 and group.name, where the ggplot only represents fill.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:

[tdhock]

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.

[chriddyp]

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

[chriddyp]

@tdhock did you're latest stuff clear this up?

[cpsievert]

@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/

[jcp1016]

Great news, thanks very much!

Janet