multi_line and categorical axis
See original GitHub issueHi all,
unless I am missing something, it looks like there might be some problem plotting multi_lines
when an axis is categorical (bokeh version: 0.12.7).
Minimal setup to reproduce the problem in a Jupyter notebook:
from bokeh.plotting import figure, show
from bokeh.io import output_notebook
output_notebook()
factors = ["a", "b", "c"]
p = figure(plot_width=400, plot_height=400, y_range=factors)
p.multi_line(xs=[[1,2,3], [1,2,3]], ys=[["a","c","b"], ["b","a","c"]], line_width=2)
show(p)
Throws the following error:
Javascript error adding output!
TypeError: Cannot read property 'c' of undefined
See your browser Javascript console for more details.
While the following code, which is identical except for the fact that both axis are numerical, functions correctly:
p = figure(plot_width=400, plot_height=400)
p.multi_line(xs=[[1,2,3], [1,2,3]], ys=[[2,1,0], [3,2,2]], line_width=2)
show(p)
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
D3 Multi-line Chart with categorical data on X-axis
D3 Multi-line Chart with categorical data on X-axis ... I'm trying to draw a multiple line chart by using company branches data consisting ......
Read more >Excel: Multiple Lines Across X-Axis Categories - PolicyViz
I have bar charts showing a time-series per x-axis category (across 12 weeks). I would now like to show a second set of...
Read more >4. Line Graphs - R Graphics Cookbook [Book] - O'Reilly
Line graphs can be made with discrete (categorical) or continuous (numeric) variables on the x-axis. In the example here, the variable demand is...
Read more >A Complete Guide to Line Charts | Tutorial by Chartio
The ability to plot multiple lines also provides the line chart a special use case ... axis variable is categorical is the dot...
Read more >4.3 Making a Line Graph with Multiple Lines
Line graphs can be used with a continuous or categorical variable on the x-axis. Sometimes the variable mapped to the x-axis is conceived...
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 FreeTop 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
Top GitHub Comments
I mean that categories are mapped to numerical coordinates internally, and you could just pass those numbers in stead of the string factor names. Roughly speaking if you have categories [“a”, “b”, “c”] then those will map to (0.5, 1.5, 2.5), but things like range padding can affect the mapping, so some fine tuning may be required.
But there are lots of ways that might also work. Another option is simply don’t use real factors coordinates or a real categorical axis at all. Instead use numeric coordinates, with a regular axis, and change how the axis displays tick values by making a tick formatter. (i.e. to show different label names for specific tick locations). Or even simpler, using tick label overrides. This is probably what I’d actually suggest to try to start. Here is a simple example:
As I said I simply don’t know how this could be fixed and still maintain support for nested categories. Nested categories were a crucial feature addition (so to be explicit and unambiguous: nested category support is more important than multi-line on categorical ranges), so this will just have to be an odd corner case to work around, I am afraid.
@robin-vjc by ambiguity,I mean this:
When you have a sequence of “nested categories”, say for grouped vbars, it looks like:
But that’s exactly the same form as for multiline. I am not sure there is any way to reconcile or disambiguate this. The handling of the property values and columns is at a very low level so it’s not something that could be handled at the level of
MultiLine
itself. Which doesn’t mean impossible, but does mean risky and expensive and for a single corner case with workarounds, probably not something that can be prioritized any time soon.