Shared colorscales/colorbars aka coloraxes
See original GitHub issueRight 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
Issue Analytics
- State:
- Created 5 years ago
- Comments:14 (14 by maintainers)
Top Results From Across the Web
Layout.coloraxis in Python - Plotly
Type: dict containing one or more of the keys listed below. ... Determines whether the colorscale is a default palette (`autocolorscale: True`) or...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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 nocoloraxis
so it would behave like all traces do right now - the trace defines its own colorscale and colorbar.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 withcoloring: 'lines'
(or'none'
) I don’t see any sense allowing to share a colorbar with heatmaps. So we’re only talking aboutcoloring: 'fills'
. But since we have to exclude'lines'
and'none'
already, I’d argue for excluding'fills'
too - and only allow contours withcoloring: '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)