Implement Heatmap chart

otisg commented 9 years ago

Here's an example: http://bl.ocks.org/tjdecke/5558084 Or: http://bl.ocks.org/mbostock/3202354

And this one would also be nice: https://github.com/lbrucher/d3-tree-heatmap -- it looks like an upside-down Flame graph: http://www.brendangregg.com/FlameGraphs/cpu-linux-execs.png

masayuki0812 commented 9 years ago

It seems difficult to implement in c3 architecture. Anyway, please let me mark as enhancement.

otisg commented 9 years ago

@masayuki0812 thank you for the info and for not just rejecting and closing the issue right away! :) But the mention of "c3 architecture" and the heatmap being difficult to implement with c3 makes me wonder -- can you say a few words about the c3 architecture and what about it would make something like heatmap difficult to implement? It may be valuable information for anyone out there considering c3 (vs. some other charting library). If you'd like, I could raise this question on the mailing list, too, so you can address it there to a wider audience? Thanks.

aendra-rininsland commented 9 years ago

@otisg @masayuki0812 It might be a really worthwhile discussion to have on Google Groups, given the ongoing efforts to improve the plugin architecture (#351) — I'd really like to help contribute to that, but I'm not really sure where to start. I can think of a half dozen reasons why addressing the architecture at this point would be really good place to direct efforts, and figuring out both how the existing architecture compares with, say, NVD3 might be a really good place to begin.

masayuki0812 commented 9 years ago

@otisg @aendrew Thank you for the suggestion. Yes, let's talk on Google Groups and is it posted already?

Btw, please let me explain briefly here.

The architecture of c3 means its data structure and the way to use SVGElement. In c3, the data structure is designed to have only x and y (2 dimensional) basically and other parts are implemented to process the data based on this principle as well. So, this means if the data needs to have more information (I expect some parameter that determines color strength will be needed and it becomes 3 dimensional), we have to change the other parts also. Additionally, it seems difficult to render something like heatmap because SVGElements c3 uses are not designed to be located like heatmap (e.g. bars, legends, labels, etc). From these points of view, I'm afraid we have to write so many parts to support its data structure and rendering process, then the code will be fat and finally it might be easier to implement from scratch (it's not only this case, but also other case where we have to parse different data structure and render different types of shapes).

However, in my opinion, it would be possible to parse the data to determine x and y from the index of column and row, and y from its value to render http://bl.ocks.org/tjdecke/5558084, for example:

columns: [
  ['x', '1a', '2a', '3a', ...],
  ['Mon', 10, 20, 30, ...],
  ['Tue', 20, 30, 40, ...],
  ...
]

In this case, index of each target (columns of Mon, Tue, ..) is treated as y of the heatmap. It's completely different from the original behavior of c3, but it could work. Additionally, it's enough to change the way to parse and we don't have to change the data structure. Then, if we can add some functions to render the tiles (e.g. redrawTile, updateTargetsForTile, etc), heatmap could be rendered, I guess.

Does it make sense? Please let me know if you have any questions. Thanks!

aendra-rininsland commented 9 years ago

@masayuki0812 Thanks for the really thorough explanation! Does this also apply to non-axial charts like the pie/donut and gauge charts? Those seem to require much different rendering logic; granted, I haven't looked into it too much.

Re: bloat, I think that's a huge reason why a plugin infrastructure is important. Once that's in place, all charts could effectively be plugins, including the existent core charts. That way developers can customise their minified version — say you're building a dashboard to parse server logs and all you need is the line chart, there should be some way to not have to deal with the extra heft of the pie charts et al. That aspect could also be tied into Bower really effectively (possibly similar to how Angular-UI's UI-Utils do things), or could even make a web-based download builder similar to jQuery UI's.

masayuki0812 commented 9 years ago

@aendrew Yeah, it's true. I'm thinking same things. Documentation has been mostly done, so I'm plaining to start working on plugin architecture next.

VMBindraban commented 6 years ago

Is there any news about this? (it has been 3 years)

nikitha2se commented 5 years ago

Is there any update on this ?

digEmAll commented 4 years ago

My 2-cents about this feature.

As shown in this codepen, it's almost possible to implement a decent heatmap using a stacked bar chart : https://codepen.io/digemall/pen/VwLwOoR

Of course the code heavily relies on svg manipulation, in particular to change label positions. What it would be nice to have to really improve this code (please correct me if some API already exists) :

a setting to set the data-labels inside the bars instead of above them. Hacking them using transform-translate, is not perfect and leaves an "ugly" white space at the top
a setting to hide tooltip colors-spans (I hid them through css)
a way to set borders of bars (I guess you can do it through stroke property but I couldn't do it...)

Khazl commented 4 years ago

Would love to see this chart type in C3!

c3js / c3

Implement Heatmap chart #882