dc.js
dc.js copied to clipboard
dc-js
Add .barWidthAccessor to manually specify (per-bar) widths for barCharts
This is an attempt to address my question on StackOverflow at http://stackoverflow.com/questions/23764932/dc-js-bar-chart-different-widths-and-title-problems .
The width is specified in pixels rather than in the default xaxis units because I couldn't think of a way to have a sensible function that would work with time axes.
I still think this is kind of a strange thing to do. For one thing, the human eye perceives area more than length, so if you have a long time period with the same number of observations as a short time period, it will look like a lot more when in fact it's the same number only less frequent.
Could you provide a motivating example, i.e. a screenshot?
In general, I'm trying to wrap my head around why the bar charts are not always evenly spaced and equal width. I can't remember ever seeing bar charts that were otherwise. Right now we allow bars to pile up (as long as the scale is not ordinal), which is strange to me.
I do get the use case for months #540, but that's only a very small width difference....
As far as the area vs length issue you mentioned, if the user wants to draw histograms as opposed to bar charts, then the height of each bar is normalized to the bar's width. It's not at all uncommon for scientific data to have variable bin widths in order to have the number of entries in each bin be roughly similar. Another common issue is if you have linear binning, but are plotting on a log scale (or vice verse).
For another specific example, consider time periods with boundaries marked by some physical event, such as hardware upgrades (Phase I-V, etc.). The attached screenshot shows the particular use case I needed: performance of an experiment during periods with different configuration templates in place (and here the bar height is simply whether or not that period is included in a global analysis, but I could have easily wanted, say, the number of triggers recorded in each period).
As a final argument, a crossfilter group allows for arbitrary binning, so it seems overly restrictive to say that only fixed-width bins can be turned into bar charts.
@gordonwoodhull here is a related dilemma I'm trying to resolve right now. Have any suggestions?
x axis is time: .x(d3.time.scale().domain([beginHour, endHour]) -- with sufficient data points it looks fine:
..but with fewer data points the bar width calculation is too huge, and looks bad. If I set additional padding, etc. it might fix it for the chart with fewer bars, but wrecks the chart with more data points.
@davisford, that's an interesting problem indeed. Could you bring it up on the user group, and mention this PR?
I think other people might have ideas, and though you could use this PR for that, this is both more and less than you need.
@bloer, I am still thinking about this. I think the usual solution is to basically use an ordinal scale, i.e. draw the bins the same width but have them represent different amounts of time, but that's misleading in its own way. I'd like to know the prior art on this.
I think this is generally a good idea. When your data is highly skewed (see for example this SO question), you may wish to split the bins not evenly, to see better with better resolution what happens in highly dense areas, and to "merge" very low bars into a one wider (and higher) bar; this, without changing the scale itself of the x-axis, which may remain, say, linear.
