Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node size is not showing correctly according to the size value #99

Open
ajaybiswas01 opened this issue Sep 29, 2022 · 4 comments
Open

Comments

@ajaybiswas01
Copy link

Describe the bug
All node size now generate different size. But size respect ordering is ok.

To Reproduce
Steps to reproduce the behavior:

  1. see the screenshot. then you can understand.

Expected behavior
Node size will be showing correctly according to the size value

Screenshots

IMG_06693

@georgejohnson-us
Copy link

georgejohnson-us commented Jun 8, 2023

Without seeing your raw data, it could be that any element that has children should NOT have a size property. If parent elements have a size property, their node size will calculate incorrectly. It would be great if the sunburst could automatically discard a "size" property if a node has children.

I used this code to disregard the size attribute if a node has children.
Sunburst()
.data(data3)
.size(function(d) {
if (d.children) {
return null;
} else {
return d.size;
}
})

@schobernoise
Copy link

So how would I go at it, if I wanted to divide my four root-segments into four equal parts?

@georgejohnson-us
Copy link

I suppose it would be even better if the size attribute was directly calculated against its parent irregardless of child nodes, but it seems that this tool does it the other way. So the issue request here should go something like this:

Describe the bug:
Node sizes don't calculate in ways that support a hierarchical visualization.

To reproduce:
Create a JSON file where all nodes have size attributes, choose an element that has children and give it a large size value. The children will not cover the parent node - there will be gaps in the visualization. The following workaround code is used to prevent this behavior:
Sunburst()
.data(data3)
.size(function(d) {
if (d.children) {
return null;
} else {
return d.size;
}
})

Hoped for behavior:
Root node should (obviously) always be 100%, each child element from there down should use the size attribute to calculate against its parent node. If no size is given then each element should be spread equally (if there are two children they are each 50%, 4 would get 25%, etc.) across its parent node. If a child element has children with sizes that don't calculate to 100%, then the children should be automatically spread proportionately to get to 100% of the parent.

I can't foresee a use case where a parent element should be larger than the combined size value of the children.

@ZorGleH
Copy link

ZorGleH commented Jul 4, 2024

Hi ! Here is my dataset:

{
  name: "root",
  children: [
    {
      name: "mineral",
      value: 180,
    },
    {
      name: "animal",
      value: 90,
      children: [
        {
          name: "animal/mammal",
          value: 40,
          children: [
            {
              name: "animal/mammal/quadrupede",
              value: 70,
            },
            {
              name: "animal/mammal/cetacean",
              value: 30,
            },
          ],
        },
        {
          name: "animal/fish",
          value: 20,
        },
      ],
    },
    {
      name: "vegetal",
      value: 90,
      children: [
        {
          name: "vegetal/tree",
          value: 150,
        },
        {
          name: "vegetal/lichen",
          value: 50,
        },
      ],
    },
  ],
}
```�

The "mineral" sector should make 50% of the total and the "animal" and "plant" sectors should each make 25%, without taking into account the value of their children.

Here is what I get:

![Capture d’écran 2024-07-04 à 18 05 20](https://github.com/vasturiano/sunburst-chart/assets/301781/1fc0f590-320f-4054-8d6b-d0d3b829263f)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants