Skip to content

Treemap trace #1038

Closed
#4185
Closed
Treemap trace#1038
#4185
Assignees
archmoj
Milestone
v1.50.0

Description

@ghost
ghost
opened on Oct 14, 2016

I believe treemaps could deserve to be supported natively as a new type instead of having to precompute the rectangles and add them as shapes.
One reason is that using shapes prevents us from directly using a colorscale on another trace attribute (since the shapes' fillcolor attribute only accepts a color value).

Activity

  1. etpinard
    added
    featuresomething new
    communitycommunity contribution
    on Oct 14, 2016

  2. rodrigomurta commented on Nov 3, 2017

    @rodrigomurta
    rodrigomurta
    on Nov 3, 2017

    It would be nice to have support to R too. Now treemaps are restricted to Python and Matlab.

  3. jackparmer commented on Mar 13, 2019

    @jackparmer
    jackparmer
    on Mar 13, 2019
    Contributor

    (Related: #2221)

  4. nicolaskruchten
    added this to the v1.50.0 milestone on Jul 4, 2019
  5. etpinard
    assigned
    etpinard
    and
    archmoj
    and unassigned
    etpinard
    on Jul 4, 2019
  6. archmoj
    added
    type: new trace type
    and removed
    communitycommunity contribution
    featuresomething new
    on Jul 4, 2019

  7. nicolaskruchten commented on Jul 4, 2019

    @nicolaskruchten
    nicolaskruchten
    on Jul 4, 2019
    Contributor

    There are three possible visual forms that are in principle treemap-like, but whose intent and natural input format differ:

    1. Hierarchical part-of-whole represented as nested rectangles, with various algorithmic approaches, like optimizing for square aspect, or slice-and-dice etc
    2. 2-level x/y Marimekko plots which are arguably more bar-like than anything else, as they can be made with and benefit from continuous/cartesian axes e.g. https://datavizcatalogue.com/methods/marimekko_chart.html
    3. Multilevel mosaic plots (more than 2 levels) whose input data more closely resembles the parcoords one (see https://www.perceptualedge.com/articles/visual_business_intelligence/are_mosaic_plots_worthwhile.pdf for commentary)

    Let's focus strictly on number 1 in this case, assuming that this is a trace-with-its-own-domain like sunburst and that it does not have cartesian axes.

    Within that, there are a bunch of dimensions to explore, requirements-wise (these may overlap a lot, naturally):

    1. Color: there are many charts in the wild, especially financial ones, that use continuous color on treemaps (e.g. https://finviz.com/map.ashx)
    2. 'headers' for the rectangles that show the names of the containing ones. Note: this messes with the strict area calculations a little bit! (e.g. https://finviz.com/map.ashx) ... some implementations put the containing header in the top-left and the contained name in the bottom-right for example http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022
    3. Independently of headers, we might want to allow nesting borders or padding around the boxes and that messes with the math a bit also in terms of layout. I don't think we should do the "cushion gradient" effect that some implementations use. Here's an example of 'padding' https://observablehq.com/@d3/nested-treemap
    4. Mouseover behaviour to show hierarchy (i.e. adding borders to all containing rectangles on hover)
    5. Click to zoom in... double-click to zoom out? If there are 'headers' then you could click on the header to zoom out, similar to the way you click on the center of the sunburst to zoom out
    6. tweening when zooming in and out, keeping in mind that the aspect ratio will change while zooming
    7. text/hover info/templates, to show the percentage of whole, percentage of parent, name etc
    8. a top-level "path" bar that summarizes the current location within the treemap and allows zoom-out (e.g. http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022)
    9. The ability to constrain the number of visible levels like we do in Sunbursts (e.g. http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022 again)

    There's lots of d3 prior art here... https://www.d3indepth.com/layouts/

    Other implementations:

  8. nicolaskruchten
    changed the title [-]Native support for treemap chart types[/-] [+]Treemap trace[/+] on Jul 4, 2019

  9. archmoj commented on Aug 21, 2019

    @archmoj
    archmoj
    on Aug 21, 2019
    Contributor
    1. Click to zoom in... double-click to zoom out? If there are 'headers' then you could click on the ...

    Implementing double-click may not be a good idea noting that on some device e.g. iPad the hover event is triggered by single click and the click event is triggered by double click.

  10. archmoj commented on Aug 30, 2019

    @archmoj
    archmoj
    on Aug 30, 2019
    Contributor

    Is it useful to display node's current/full path on hover?

  11. nicolaskruchten commented on Sep 4, 2019

    @nicolaskruchten
    nicolaskruchten
    on Sep 4, 2019
    Contributor

    Is it useful to display node's current/full path on hover?

    Would be useful to have as an option in hovertemplate yes! By default I would say no.

  12. archmoj
    closed this as completedin #4185on Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions