Shared / matching auto-binning for histogram2d traces

[etpinard]

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)bins objects in the layout similar to "shared" color scales/axes discussed in Shared colorscales/colorbars aka coloraxes #3431

cc @nicolaskruchten

[alexcjohnson]

a shared object would probably work for histogram2d traces 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]

so what does it look like when you have two histogram2d traces on the same subplot? they overlap and you use opacity? I feel like that case is more marginal than the different-subplot one :)

[alexcjohnson]

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]

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]

note: once this and #3431 are done we can add histogram2d to px :)

[etpinard]

I think this is obvious, but I'd like confirmation:

• Setting compatible binning with bingroup should work only for traces on the same bin axis OR across matching bin axes (i.e. set with ax.matches).

Is that correct? Or should bingroup work across general cartesian axes?

[alexcjohnson]

I feel like there would be uses for bingroup across non-matching axes, as long as ax.type is the same.

[etpinard]

Ok great, I'm glad I asked.

Next, should we allow histogram2d traces to be in different binning groups for their x-bins and their y-bins simultaneously. In other words, should we add xbingroup and ybingroup instead of just bingroup?

[kevinoe]

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]

@kevinoe Thanks for writing in! Could you share an example of your use case to help us out even more? Cheers!

[alexcjohnson]

Next, should we allow histogram2d traces to be in different binning groups for their x-bins and their y-bins simultaneously. In other words, should we add xbingroup and ybingroup instead of just bingroup?

I suppose we could imagine something like a manually-constructed splom showing 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 xbingroup defaults bingroup + '__x' or something?

[etpinard]

But in general it would be nice to only need to specify the group once. Perhaps we make all three attributes, and xbingroup defaults bingroup + '__x' or something?

More on this topic, should

Plotly.newPlot(gd, [{
  type: 'histogram2d',
  x: [1], y: [1],
  bingroup: '1'
}, {
  type: 'histogram2d',
  x: [2], y: [2],
  bingroup: '1'
}])

• make data[0].xbins + data[1].xbins compatible AND data[0].ybins + data[1].ybins compatible (i.e. lead to two bin "groups")
• OR make data[0].xbins + data[1].xbins + data[0].ybins + data[1].ybins compatibl (i.e lead to one single bin "group")?

[etpinard]

I went with

• make data[0].xbins + data[1].xbins compatible AND data[0].ybins + data[1].ybins compatible (i.e. lead to two bin "groups")

in #3845