You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@echarts.apache.org by GitBox <gi...@apache.org> on 2022/07/11 16:13:07 UTC
[GitHub] [echarts] rj33 opened a new issue, #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
rj33 opened a new issue, #17358:
URL: https://github.com/apache/echarts/issues/17358
### What problem does this feature solve?
I am trying to graph data that is mostly fairly well suited to sunburst, however I'm running into the problem that some nodes in the tree I am trying to graph have children whose value fields add up to a total that is great than the value field of the parent, and the layout doesn't handle this well.
You can see an example of how this looks by modifying the visualmap example at :
https://echarts.apache.org/examples/en/editor.html?c=sunburst-visualMap
And give a value: 3 field to the "Uncle Nike" node,
and then increase Cousin Jenny value from 2 to 12.
This creates a very wide 'cousin jenny' field which overlaps other neighbouring starburst pieces. Not only does this make the chart ugly, but if emphasis is on, it also makes the nodes under 'cousin jenny' non-visible and so unclickable when cousin jenny is being highlighted.
This layout issue can be fixed manually by increasing the value on Uncle Nike from 3 to 13 , making it match the size of the children, thus making appropriate room for the other neighbour nodes that were otherwise being overlapped.
However Uncle Nike's value is NOT 13 (in my example), it is 3, and setting it to 13 gives the impression that it is a much more "important" node from a value point of view than it actually is.
It would be great if this situation could be handled automatically, by detecting the children being greater than the parent, and reserving empty space of the appropriate size in the parent that is transparent , thus avoiding the overlap issue with large children, but without making the parent appear larger than it actually is. Alternatively, if this couldn't be done automatically, being able to manually set the parent's visual size separate from the size it takes up in its place in the sunburst, and so allowing a manual way of solving the problem.
### What does the proposed API look like?
Ideally no API change would be required, as the situation could be automatically detected and the appropriate space reserved. Perhaps a flag to turn the behaviour on would be useful, but given the layout is broken at the moment if children outsize their parents, even a flag would perhaps not be required, as it seems to be a useful default behaviour to handle this case in this manner, and it is hard to imagine people wanting to turn on overlapping large child nodes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org
[GitHub] [echarts] rj33 commented on issue #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
Posted by GitBox <gi...@apache.org>.
rj33 commented on issue #17358:
URL: https://github.com/apache/echarts/issues/17358#issuecomment-1181292800
I think the easiest way to see the issue I'm talking about is to go to:
https://echarts.apache.org/examples/en/editor.html?c=sunburst-visualMap
And change the data to use this:
var data = [
{
name: 'Grandpa',
children: [
{
name: 'Uncle Leo',
value: 15,
children: [
{
name: 'Cousin Jack',
value: 14
},
{
name: 'Cousin Mary',
value: 5,
children: [
{
name: 'Jackson',
value: 1
}
]
},
{
name: 'Cousin Ben',
value: 4
}
]
}
]
}
];
Now you can see that with this configuration with Cousin Jack using a value of 14, Cousin Jack will overflow over Cousin Mary and Cousin Ben, because the parent node (Uncle Leo) is weighted such that not enough room is made for all the children which are relative to the parent size. If you now change Uncle Leo from value 15 to value 23 the layout is fixed, but now Uncle Leo is too big, as his real value should only be 15. My proposal is layout Uncle Leo's layer in the sunburst like it has size 23, but use empty space of value of 9 and keep Unclear Leo at size 15. This will allow the children of Uncle Leo to be layed out properly, as they now have the space required to expand to their full size relative to the parent, but Uncle Leo still has his correct relative size of 15, and the empty space of 9 is taking up the rest. I experimented with adding dummy nodes NEXT to Uncle Leo myself, but that doesn't fix the issue, as the parent layout is still relative to uncle Leo and so can sti
ll overlap.
I hope this explanation and the data example above makes the issue I'm facing clearer.
At the moment my best option seems to be to simply make Uncle Leo bigger, by increasing his value to the sum of the children values, and providing a tooltip that shows his 'true' value instead of the fake value. Unfortunately this runs into the issue you mention which is that a bigger parent that their 'true' value will mislead the user, hence my request for the layout engine to handle this by automatically creating the required empty space at the parent (Uncle Leo) level and therefore allowing both Uncle Leo to keep this true value and size AND layout the children of Uncle Leo without them overlapping eachother.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org
[GitHub] [echarts] rj33 commented on issue #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
Posted by GitBox <gi...@apache.org>.
rj33 commented on issue #17358:
URL: https://github.com/apache/echarts/issues/17358#issuecomment-1181308379
Just to clarify, the empty space needs to be PART of the Uncle Leo node when considering layout the children of Uncle Leo in order to avoid other problems, as the space used by Uncle Leo PLUS the empty space needs to match the space required for the children otherwise the layout algorithm gets confused if it thinks it only has the visible space of Uncle Leo to work with, and in more complex structures the children of Uncle Leo with overlap with the children of siblings of Uncle Leo, which is why my attempt to solve the problem by creating my own empty sibling of Uncle Leo did not solve the issue properly.
I looked at how highcharts deals with this type of case , and they don't end up with the overlap problem, but the children end up having the wrong relative size compared to the parent (and children of other parent's at the same level), which isn't ideal either, and basically the opposite of making 'Uncle Leo' bigger than he should be (the children become smaller than they should be instead).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org
[GitHub] [echarts] Ovilia commented on issue #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
Posted by GitBox <gi...@apache.org>.
Ovilia commented on issue #17358:
URL: https://github.com/apache/echarts/issues/17358#issuecomment-1181604106
Yes, I do understand that current design may have this problem because this is treated as error input. But what I'm not quite sure is, why should this be this regarded as expected input. Can you give a real-world example (not code) rather than the relatives example which doesn't quite explain the problem here.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org
[GitHub] [echarts] rj33 commented on issue #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
Posted by GitBox <gi...@apache.org>.
rj33 commented on issue #17358:
URL: https://github.com/apache/echarts/issues/17358#issuecomment-1181716683
Sure, the domain I'm dealing with is a tree of chess positions (opening positions). I'd like to be able to present the nodes in the tree in a way that recognises the total number of times the position appeared in games. Because one chess opening can transpose into another, sometimes a position can be reached in more than one way. When that happens the position may be reached by a very common sequence of moves or a rare sequence of moves. It is the same position, so has the same number of times it has appeared in games in total, but the tree represents the moves that lead up to the position. In one part of the tree the move sequence may be very rare, but if you can transpose into a position that is very common, because it can be reached by a common sequence of moves then in the rare move path, you end up with a parent with a small number of appearances in games, but a child with a lot of appearances in games. Currently I can't represent that without the feature request that makes
room for the children that are in total larger than the parent. I deliberately want this transpositional nature in the tree, so I don't want the child node in the rare path to count only the number of times it appeared using the leadup moves in the rare sequence, I want it to reflect the total number of times it was seen across all move sequences, because at that point it doesn't matter how it is reached, it is the same position irrespective of how it was reached.
It is not hard to come up with simpler examples of hierarchical data that has the property that children may have values that are larger than the parents. For examples a tree that shows multi-generational wealth by having the value of each node being the net-worth of the person represented by that node. The tree structure represents the multi-generation family relationships (children, parents, grandparents etc), and each generation is given the percentage of that level's available space based on each individual's wealth (or health or any other metric you want to visualise that isn't fully determined by the parents), but if the children end up being wealthier than their parents then the child nodes will break the layout.
Basically any hierarchical data structure where the value of the children are not simple subsets of the value of the parent. Not all hierarchical data is grouped such that value metrics dictate that child nodes are always going to be smaller in total than their parent nodes value, although I would agree this is the more common case, and the 'children can sum to have values higher than the parent' is probably a more unusual case. However, I doubt I'm the only person who could use the ability to use a sunburst to visualise this type of data. There are other visualisations that can be used, but sunburst is quite compact for this type of thing, especially if MOST of the children sum to be smaller than their parent, and only a few cases exhibit the opposite relationship, and require reservation of empty space in the parent (which is the situation in my use case, as transposing moves are considerably less common than non-transposing moves).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org
[GitHub] [echarts] Ovilia commented on issue #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
Posted by GitBox <gi...@apache.org>.
Ovilia commented on issue #17358:
URL: https://github.com/apache/echarts/issues/17358#issuecomment-1181242319
Hi. Can you explain more details about your case. What does it mean to have a children whose value is larger than its parent in the Sunburst chart? Using the sum of the values of children as the maximum value for the parent may mislead the users to believe the children's values add up to the parent's.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org
[GitHub] [echarts] simplg commented on issue #17358: Allow sunburst to render properly when sum of children's value are higher than parent's value
Posted by "simplg (via GitHub)" <gi...@apache.org>.
simplg commented on issue #17358:
URL: https://github.com/apache/echarts/issues/17358#issuecomment-1610991569
I have also encountered the same problem with the library. In our area of field, we are using the sunburst to plot z scores for subdomains and domains. The domain's value is the mean of the z score of the subdomain which are its children. Therefore, the domain's value is always less then the sum of value of its subdomains.
We can't really hack around it with the formatter label (by modifying the displayed label with a different value), since we are using visualmaps to plot colors.
I would propose that an option should be available to disable the link between value and radius of a sunburst element. By doing this, we could put whatever value we want for parents and children and not have any problem with rendering while still having the possibility to have the correct color shown through visualmap.
Basically it would be great to have this rendering:
With this kind of code:
[Codepen](https://codepen.io/akuma06/pen/oNQZBqX)
```js
var data = [
{
name: 'Grandpa',
children: [
{
name: 'Uncle Leo',
value: 15,
children: [
{
name: 'Cousin Jack',
value: 2
},
{
name: 'Cousin Mary',
value: 5,
children: [
{
name: 'Jackson',
value: 2
}
]
},
{
name: 'Cousin Ben',
value: 4
}
]
},
{
name: 'Aunt Jane',
children: [
{
name: 'Cousin Kate',
value: 4
}
]
},
{
name: 'Father',
value: 10,
children: [
{
name: 'Me',
value: 5,
itemStyle: {
color: 'red'
}
},
{
name: 'Brother Peter',
value: 1
}
]
}
]
},
{
name: 'Mike',
children: [
{
name: 'Uncle Dan',
children: [
{
name: 'Cousin Lucy',
value: 3
},
{
name: 'Cousin Luck',
value: 4,
children: [
{
name: 'Nephew',
value: 2
}
]
}
]
}
]
},
{
name: 'Nancy',
children: [
{
name: 'Uncle Nike',
children: [
{
name: 'Cousin Betty',
value: 1
},
{
name: 'Cousin Jenny',
value: 2
}
]
}
]
}
];
option = {
visualMap: {
type: 'continuous',
min: 0,
max: 10,
inRange: {
color: ['#2F93C8', '#AEC48F', '#FFDB5C', '#F98862']
}
},
series: {
type: 'sunburst',
// New property suggested
disableRadiusFromValue: true,
data: data,
radius: [0, '90%'],
label: {
rotate: 'radial'
}
}
};
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@echarts.apache.org
For additional commands, e-mail: commits-help@echarts.apache.org