TreeMap same data size, rectangles not equal area size

Community Help
1

Trying to use Treemap to visualize simple data (software, #installs). Confused on the algorithm that determines size of rectangles. If I provide very simple data: [{s:‘Word’,n:10}, {s:‘Excel’, n:10}, {s:‘Powerpoint’, n:10}, {s: ‘Outlook’, n:10 }] the rectangles aren’t a quad pattern of equal size. Can someone help me understand the logic, and how to accomplish rectangle sizes that are directly representational of correlated area size?

2

Looks equal to me? Maybe something else is going on?

untitled (15)
untitled (15)1856×1000 8.19 KB 

Treemap(apps, {
  path: (d) => d.s,
  label: (d) => d.s,
  value: (d) => d?.n,
  width,
  height: 500
})

apps = [
  {s: "Word", n: 10},
  {s: "Excel", n: 10},
  {s: "Powerpoint", n: 10},
  {s: "Outlook", n: 10}
]
1 Like
3

Thank you @mbostock. Using Recharts (recharts-treemap-size - CodeSandbox) so this informs me to investigate elsewhere.

4

The demo there, even though it’s not using Observable or d3 directly, does seem to be working correctly. Although the four boxes aren’t the same width and height, they are approximately the same area. On my screen the top boxes are 137x304, for an area of 41,648. The bottom box is 404x104, for an area of 42,016. This isn’t exactly the same, but they are all within 1%.

5

The Treemap widget on Observable defaults to d3.treemapBinary as tiling method, while recharts appears to hardcode the method to d3.treemapSquarify.

If you add the lines

  tile: d3.treemapSquarify,
  width: 400,
  height: 400

to Mike’s example, you get a similar ordering for the aspect ratio in your CodeSandbox example:

image
image862×1188 37.1 KB

6

Thank you for your further explanations. I discovered that Recharts had a discrepancy in their sample code versus API documentation with regards to the prop ‘ratio’ versus ‘aspectRatio’. With the change to leverage aspectRatio prop Recharts produced the 4x4 equal sized chart I was anticipating.

1 Like