Fix how geom_dotplot handles some aes

[evolvedmicrobe]

This commit allows geom_dotplot to display color attributes properly
when dots are binned. Prior to this, if one ran a command such as:

ggplot(mtcars, aes(x=factor(cyl), y =mpg, fill=factor(carb), group=factor(cyl))) + geom_dotplot(binaxis="y", stackdir="center")

The dots would be positioned on top of each other, because a "double
grouping" was performed where both the fill and the x axis were used to
divide groups. This change keeps the groups appropriately separated
when the x/y positions are being determined, but still applies separate
coloring to each.

It does this by changing where the fill color is added to the data used
when plotting. Previously, the data was condensed into bins and a
dataframe where each row represented several dots to be plotted during
the calculate groups step. This condensed data was then re-expanded
with a constant fill color added for each binned group inside the
reparameterise method. This commit re-expands the data into one line
per dot in the original calculate method, where the appropriate fill
(or other aes) is still available and can be added back in.

I verified that all the original examples for geom_dotplot still behave
as expected, and all tests currently pass.

[evolvedmicrobe]

I gather the failed tests are independent of this PR as several previous ones seem to generate the same error.

[evolvedmicrobe]

Also, in case it is useful, some before and after for the command:

ggplot(mtcars, aes(x=factor(cyl), y =mpg, fill=factor(carb))) + geom_dotplot(binaxis="y", stackdir="center")

[hadley]

@wch could you please review the basic strategy?

@evolvedmicrobe You'll also need to match the style of the existing code, but there's no point doing that until we're confident that the change as a whole is good to merge.

[evolvedmicrobe]

@hadley @wch thanks for taking a look at this. My hope is really just to commit something that produced the "after" plot rather than the "before" plot, happy to make any coding style (or other) changes to get that done.

[wch]

A couple quick thoughts:

• It would be nice if the stacking order were consistent with respect to the group/color. In the example, in the left column of dots, the bottom two groups have different stacking order. I'm guessing they're in order of the y values?
• This may require extra care when using facets - you'd usually not want them to be grouped in this way across facets.
• This is similar to using stackgroups=TRUE, but not exactly, since the goal here is to share bin positions only for points that share the same x location (in the same facet), whereas with stackgroups=TRUE, the bin positions are shared across all data.

[beroe]

Was this closed because it was fixed? And if so, what is the solution. I still get unpredictable spacing using ggplot(mtcars, aes(x=factor(cyl), y =mpg, fill=factor(carb))) + geom_dotplot(binaxis="y", stackdir="center",stackgroups = TRUE,binpositions="all") or the code shown above in the before/after example.

[evolvedmicrobe]

This issue was just closed and not fixed.

[adempewolff]

Stumbled across this while trying to figure out how to produce something similar to the "after" plot above. Can see the rational for not wanting to change the default behavior, but it would be nice to have this as an option at least.

[vitorbl]

Solution would go through feeding fill argument inside dotplot layer without calling aes(), but DATA MUST BE ORDERED FIRST, first with respect to your x variable ( factor(cyl) ), secondly with respect to your y variable (mpg). Solution would look a lot like that:
data <- mtcars[with(mtcars,order(factor(cyl), mpg)),]

ggplot(data, aes(x=factor(cyl), y =mpg, )) + geom_dotplot(binaxis="y", stackdir="center", fill = data$carb)

Downside is that you are losing legends, I think it can be set manually. It's possible to build a function to address the colors in a very personal way returning strings that reger RGB values or color names.

• In fact, mtcars$carb can be unsderstood as a color parameter, otherwise a function converting values to either RGB or color names (always in the string format) would be mandatory.

[evolvedmicrobe]

For what's its worth we were able to solve the problem and make a nice publication graphic (Figure 1 here: http://www.pnas.org/content/early/2017/07/12/1703338114.full.pdf). I love this library, thanks ggplot!

[kevinmickey]

This PR was closed, but it appears there is still an open issue: #1745.

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/