seaborn icon indicating copy to clipboard operation
seaborn copied to clipboard

Allow multiple kinds in figure-level plots

Open mwaskom opened this issue 6 years ago • 3 comments

With recent shift in the docs to emphasize the figure-level plots, it raises the challenge that layering multiple plots (i.e. a swarmplot on top of a violinplot) this way is not obvious. For a single axes grid, you can plot directly onto it using the axes-level function you want. For multi-plot grids, you can use .map_dataframe, but synching the order of the semantics between the two plots is a challenge.

An option for a better API might be to accept a sequence in kind, i.e.

sns.catplot(x="total_bill", y="tip", kind=("violin", "swarm"), data=tips)

This would be straightforward, except what about additional keyword arguments?

mwaskom avatar Jul 06 '18 00:07 mwaskom

This would be straightforward, except what about additional keyword arguments?

Perhaps: pull out {kind}_kws from the kwargs and pass those to the specific axes-level plot only, passing additional non-kwargs to all plots. (Prioritizing specific kwargs).

mwaskom avatar Jul 06 '18 11:07 mwaskom

(i.e. a swarmplot on top of a violinplot)

Somewhat off-topic, but I find drawing strip/swarm plots on top of box/violin plots relatively useful. If this use case is in mind, providing swarm/strip functionality as a part of the box/violin API can support their usability, with the possible gain of nicer aesthetics (a few possible examples: fit points automatically within the corresponding box/violin; extending box whiskers to max data points; controlling alpha and zorder of the points and different box/violin elements to reduce visual interference).

Perhaps: pull out {kind}_kws from the kwargs and pass those to the specific axes-level plot only, passing additional non-kwargs to all plots. (Prioritizing specific kwargs).

How about (also) allowing a dict input having keys as requested plotting functions and values as specific plot kwargs? Do you consider allowing any drawing method also accepted by g.map() as a valid input?

MaozGelbart avatar Apr 28 '19 17:04 MaozGelbart

Sorry, but I don't think those suggestions fit particularly well within the current approach to the API.

mwaskom avatar Apr 28 '19 18:04 mwaskom

I think I'm going to close this for now with the new objects interface as offering a better path forward for plot layering.

mwaskom avatar Sep 14 '22 00:09 mwaskom