Repository navigation
Shared / matching auto-binning for histogram2d traces #3515
Description
Split from #3506 (comment)
We don't currently match auto-binning for histogram2d traces on the same subplot, unlike we do for stacked & grouped histogram traces post #3044.
To do so, we could either:
- add a new attributes (e.g.
bingroup), or - add "shared"
(x|y)binsobjects in the layout similar to "shared" color scales/axes discussed in Shared colorscales/colorbars aka coloraxes #3431
Activity
alexcjohnson commentedon Feb 5, 2019
a shared object would probably work for
histogram2dtraces on separate subplots, but on the same subplot we would want them to be compatible (same dx/dy, and x/y start different by an integer number of dx/dy) rather than actually identical, to accommodate tiling.So a grouping attribute seems more appropriate to me.
That argument doesn't apply to colorscales/colorbars - there I think "shared" is either all or nothing.
nicolaskruchten commentedon Feb 5, 2019
so what does it look like when you have two
histogram2dtraces on the same subplot? they overlap and you use opacity? I feel like that case is more marginal than the different-subplot one :)alexcjohnson commentedon Feb 5, 2019
Overlapping would be plausible, but more common I'd think is tiling side-by-side, which is why I want to ensure we support compatible but not identical binning.
Certainly more marginal than different subplots, but we still don't want to break it!
nicolaskruchten commentedon Feb 8, 2019
Is there an issue open for optionally matching binning logic for overlaid 1d histograms? Would it make sense to handle that case with this issue?
nicolaskruchten commentedon Apr 9, 2019
note: once this and #3431 are done we can add
histogram2dtopx:)etpinard commentedon Apr 30, 2019
I think this is obvious, but I'd like confirmation:
bingroupshould work only for traces on the same bin axis OR across matching bin axes (i.e. set withax.matches).Is that correct? Or should
bingroupwork across general cartesian axes?alexcjohnson commentedon Apr 30, 2019
I feel like there would be uses for
bingroupacross non-matching axes, as long asax.typeis the same.etpinard commentedon Apr 30, 2019
Ok great, I'm glad I asked.
Next, should we allow
histogram2dtraces to be in different binning groups for their x-bins and their y-bins simultaneously. In other words, should we addxbingroupandybingroupinstead of justbingroup?kevinoe commentedon Apr 30, 2019
Just leaving my feedback as I'm dealing with this exact problem now. I would like exactly overlaid w/ opacity, which was described above as a "marginal" case. I'm using it to develop what I think is a more natural selection display (I overlay the selected points as a new trace with opacity .75).
etpinard commentedon Apr 30, 2019
@kevinoe Thanks for writing in! Could you share an example of your use case to help us out even more? Cheers!
alexcjohnson commentedon Apr 30, 2019
I suppose we could imagine something like a manually-constructed
splomshowing 2D histograms instead of a scatter plot, where neighboring cells share one axis but not the other, so would only want to match bins on the matching axis.But in general it would be nice to only need to specify the group once. Perhaps we make all three attributes, and
xbingroupdefaultsbingroup + '__x'or something?kevinoe commentedon Apr 30, 2019
etpinard commentedon Apr 30, 2019
kevinoe commentedon Apr 30, 2019
etpinard commentedon May 2, 2019
kevinoe commentedon May 2, 2019
etpinard commentedon May 7, 2019
More on this topic, should
data[0].xbins+data[1].xbinscompatible ANDdata[0].ybins+data[1].ybinscompatible (i.e. lead to two bin "groups")data[0].xbins+data[1].xbins+data[0].ybins+data[1].ybinscompatibl (i.e lead to one single bin "group")?etpinard commentedon May 8, 2019
I went with
in #3845