Shared colorscales/colorbars aka coloraxes

[nicolaskruchten]

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

[etpinard]

Quick question:

What should happen when traces that don't have the same colorbar visuals (e.g a heatmap and contour trace) share the same color axis?

In JSON form, this would be something like:

var data = [{
  type: 'heatmap',
  z: [[1,2,3], [2,3,3]],
  coloraxis: 'coloraxis'
}, {
  type: 'contour',
  z: [[2,3,1], [2,4,0]]
  coloraxis: 'coloraxis'
}]

var layout = {
  // e.g. some optional color-axis settings
  coloraxis: {
      colorscale: 'Viridis'
  }
}

then should we show two colorbars? A "combined" version (not sure how this would look like)? Maybe we could show a colorbar only if all traces have compatible color bar visuals? Or should color axes not have control over color bars at all? In other words, traces with the same coloraxis would share cmin / cmax / cmid and colorscale values - it would up the user to set showscale and the colorbar options accordingly in their trace(s).

[nicolaskruchten]

Could we unify these color scales with a new attr like “discrete” or something? And then they could share

[nicolaskruchten]

To be clearer: “discrete” would default based on the first trace that shares it, so contour-only would default to discrete and heatmap-only would not, and mixed would default to the first one but be overrideable

[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)

[nicolaskruchten]

What does “exclude”/“not allow” look like?

…

On Wed, Apr 17, 2019 at 20:38 alexcjohnson ***@***.***> wrote: 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) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABRWA2E4UP3JFHRTSLKMRTPQ67IBANCNFSM4GPTMLDQ> .

[alexcjohnson]

it probably looks like rejecting that coloraxis value from the latter trace, and giving it a separate colorscale and bar.

[nicolaskruchten]

Hmm. Is there any xaxis/yaxis precedent for this kind of rejecting? If two incompatible traces declare coloraxis: "coloraxis1" would we force a second color axis to exist and map one trace onto it, despite the figure spec?

[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.

[nicolaskruchten]

Works for me

…

On Wed, Apr 17, 2019 at 21:55 alexcjohnson ***@***.***> wrote: 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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3431 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABRWA3ZTFJUI22X67GX4XTPQ7IHZANCNFSM4GPTMLDQ> .