Treemap has problems with repeated leaf values

128 views
Skip to first unread message

NA

unread,
May 26, 2011, 5:45:40 PM5/26/11
to Google Visualization API
Suppose that your DataTable has repeated values for some leaf nodes.
The treemap combines those leaves together under each parent node for
which any of them appear. This means that the leaf nodes appear under
parent nodes that they do not belong to.

It appears that there is an assumption being made internally by the
treemap code that the values for the leaf node are unique. This may
not be the case - instead, uniqueness can be guaranteed by combining
the value along with the row number.

Are there any workarounds to this? I can prob post an example if this
is really needed, but I suppose that by now this may be a known
issue.

MarkC

unread,
Jun 17, 2011, 5:45:23 AM6/17/11
to Google Visualization API
I've stumbled across the same problem - and has gone down the 'making
the values non-unique' route.... essentially concatenating with the
parent node value.
Not ideal... but gets round the problem





On May 26, 10:45 pm, NA <nabeel.a...@gmail.com> wrote:
> Suppose that your DataTable has repeated values for some leaf nodes.
> Thetreemapcombines those leaves together under each parent node for
> which any of them appear.  This means that the leaf nodes appear under
> parent nodes that they do not belong to.
>
> It appears that there is an assumption being made internally by thetreemapcode that the values for the leaf node are unique.  This may

Csaba Balogh

unread,
Jun 17, 2011, 9:07:17 AM6/17/11
to google-visua...@googlegroups.com
Well that's exactly the way i solved the problem... thank you!

2011/6/17 MarkC <Mark....@talk21.com>

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To post to this group, send email to google-visua...@googlegroups.com.
To unsubscribe from this group, send email to google-visualizati...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-visualization-api?hl=en.


Tayeb Karim

unread,
Jun 20, 2011, 5:24:26 PM6/20/11
to google-visua...@googlegroups.com
GoogleVisualization's DataTable allows a distinction between a value
and a formatted value.
You can use the FormattedValue to be the display name, whereas the
Value can be used to unique-ify the element.

--
-
---
Tayeb Al Karim
t...@google.com

NA

unread,
Jun 22, 2011, 1:19:25 PM6/22/11
to Google Visualization API
Yes, but this seems like a problem with Treemap. The Treemap should
realize that each row represents a different node (that's how the data
is specified). It should "unique-ify" the data on its own, perhaps by
internally combining the row number with the value.

However Treemap does this, it's part of implementing a Treemap and
shouldn't be something that each user of the Treemap would have to
reinvent on his/her own

FormattedValue is just a workaround for this problem. Not a pretty
one, either, as it involves first junking up your Treemap datasource,
and then trying to clean it up with formatters...







On Jun 20, 5:24 pm, Tayeb Karim <t...@google.com> wrote:
> GoogleVisualization's DataTable allows a distinction between a value
> and a formatted value.
> You can use the FormattedValue to be the display name, whereas the
> Value can be used to unique-ify the element.
>
>
>
>
>
>
>
>
>
> On Fri, Jun 17, 2011 at 9:07 AM, Csaba Balogh <szonj...@gmail.com> wrote:
> > Well that's exactly the way i solved the problem... thank you!
>
> > 2011/6/17 MarkC <Mark.cop...@talk21.com>

Tayeb Karim

unread,
Oct 7, 2011, 2:44:45 PM10/7/11
to google-visua...@googlegroups.com
Consider the case of specifying a parent. If multiple parent nodes
have the same name, how do you decide what the parent is?

NA

unread,
Oct 24, 2011, 4:23:59 PM10/24/11
to Google Visualization API
Good point - I agree about parents with the same name.

But the problem even exists with terminal leaf nodes that have the
same name. If these are terminal leaf nodes, there shouldn't be any
ambiguity since their parent is defined and they aren't parents for
any other node. In my test cases, however, leaf node with the same
name don't get attached to the proper parents. If we could address
that, it might make my life a little easier.

If for some reason that's not desirable, let me know. It seems ok to
me.

I am willing to compromise - if you can fix this one:

http://code.google.com/p/google-visualization-api-issues/issues/detail?id=625

I will be very happy and probably forget all about the treemap
issue ;)

EMS

unread,
Mar 2, 2012, 12:14:33 PM3/2/12
to google-visua...@googlegroups.com
The current treemap data representation, where all node names must be unique, does not support some very reasonable use cases:
  1. Disk usage.
  2. Budget analysis
I propose a "simple" fix that is backwards compatible to the current implementation.
Support an optional column: data.addColumn('string', 'Header').  If this column is present, show the Header instead of the node ID, otherwise, behave as current.
Then arbitrary IDs could be used for the nodes.  For example:

data.addColumn('string', 'ID')
data.addColumn('string','Parent')
data.addColumn('number','Size')
data.addColumn('string', 'Header')
data.addRows([
  ['1', null, 0, 'root'],
  ['2', '1', 0, 'home'],
  ['6', '1', 0, 'work'],
  ['3', '2', 10, 'documents'],
  ['4', '2', 50, 'pictures'],
  ['5', '4', 50, 'photo.png'],
  ['7', '6', 70, 'documents'],
  ['8', '6', 200, 'pictures',],
  ['9', '8', 150, 'photo.png'],
]);

Tayeb Karim

unread,
Mar 2, 2012, 1:36:38 PM3/2/12
to google-visua...@googlegroups.com
This should already be supported.

You can set the formatted value (the value displayed) separately from
the id itself in column 0.

http://code.google.com/apis/chart/interactive/docs/reference.html#DataTable_setFormattedValue

> --
> You received this message because you are subscribed to the Google Groups
> "Google Visualization API" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/google-visualization-api/-/VYRQZaWL_7AJ.

Reply all
Reply to author
Forward
0 new messages