Shared colorscales/colorbars aka coloraxes

Right now traces can share axes but not colorbars. It would be nice if they could, something like data[].coloraxis = "color1" with layout.coloraxis1 = { ... } and all bounds-computations could include the union of the data of the traces, etc

[alexcjohnson]

I feel like we do this in a bunch of situations, but one that comes to mind right now is scaleanchor, we’ll ignore it if the referenced axis is the wrong type.

If we reject a coloraxis setting, that trace would have no coloraxis so it would behave like all traces do right now - the trace defines its own colorscale and colorbar.

[alexcjohnson]

Contours with coloring: 'heatmap' would work just fine already - the colorbar would have lines on it for the contours I guess, which wouldn’t match the heatmap, but that’s probably OK. And contours with coloring: 'lines' (or 'none') I don’t see any sense allowing to share a colorbar with heatmaps. So we’re only talking about coloring: 'fills'. But since we have to exclude 'lines' and 'none' already, I’d argue for excluding 'fills' too - and only allow contours with coloring: 'heatmap' to share a scale with a heatmap - until we manage to do “discrete” right.

FWIW “discrete” itself has two variants that we need to be careful about. The version used in contour plots defines data values at the edges of each color - where the contour lines are. Much of the time heatmaps (and choropleths, scatter marker colors…) with discrete colors don’t do that kind of mapping, they simply have discrete data and they map a single value to a single color. As far as the colorbar is concerned the main distinction is where the labels go: at the color boundaries vs midpoints. For the boundaries case we will need changes to trace rendering code, for the discrete data case we’ll need changes to the colorbar rendering (and maybe trace rendering changes, if we want to also collapse multiple values onto one color)