Chord shape and layout?

[mbostock]

Slight complication: there’s both the chord shape (d3.svg.chord in D3 3.x) and the chord layout (d3.layout.chord).

I think they should live together, either in this module or in a separate d3-chord module. Chord diagrams aren’t especially common relative to line, area and pie charts, so there’s some argument to putting them in a separate module. On the other hand, the implementation isn’t especially complicated, and you’re going to need the d3-shape module to create a chord diagram anyway, assuming you’re using the arc generator for the exterior groups.

But then there’s the question of what to call the shape and the layout. Some options:

1. chordShape and chordLayout
2. chord and chordLayout
3. chord and chordDiagram
4. chord and chords
5. chord and circle
6. chord.shape and chord.layout (in the d3-chord repository)

We might also want to consider another type of chord diagram which uses unidirectional links, rather than bidirectional asymmetric links as in Circos. For example:

[mbostock]

The naming question feels related to arc and pie: the arc is the shape and the pie is the layout. But this isn’t a perfect analogy because there are different terms for a pie chart (the pie) and its constituent marks (arc, wedge, slice). With a chord diagram, the mark and the chart has the same name: chord.

Also, “pie” is not a great name because the pie generator is used more often for donut charts. And a pie generator doesn’t really produce a pie because it only computes the angles, without any representation of radius. Worst of all, the pie generator isn’t even specific to angles because it simply divides a range proportionally by value! It just happens that the range defaults to [0, τ].

So, maybe we should rename “pie” to something else, while we’re at it? Back in the Protovis days, there was pv.normalize. Though, it is convenient that the pie generator returns objects with startAngle, endAngle and padAngle properties, since those match the default accessors for the arc generator.

[jasondavies]

Æsthetically, I like the idea of chord.{shape,layout} (assuming it lives in d3-chord).

[mbostock]

I see the appeal. I am less pleased that the names are so different than arc and pie, though.

Also, I still haven’t figured out exactly how namespacing works across modules, since ES6 imports offer tremendous flexibility (import {arc as arcShape} from "d3-shape") but also favor a flat namespace (e.g., export {arc, pie} from "d3-shape") rather than a nested object. For example, we probably don’t want to namespace all the d3-arrays methods (e.g., d3.arrays.min) in the default build because that’s different than 3.x and those functions are often used, making brevity appealing.

So, I think short words that are descriptive and unique are probably best. I feel like “chord” is a good name for the shape, but I’m less certain about the other part, which is computing the angular spans of the chord ends and the chord groups. I suppose “arcLayout” and “chordLayout” is an option. I could maybe see “chord” and “circle” too, although the latter is likely too vague since it only conveys a circular layout. The plural “chords” and “arcs” (or even “chordset” and “arcset”) also has a nice appeal since it emphasizes the relationship with the singular shape, and also that it takes plural data as input (as opposed to the shape, which takes a singular datum as input).

[mbostock]

Interestingly, Circos uses the name “ribbon” to describe fat links, so that might be a good name for the chord shape. (Especially since chord already has a slightly different geometric definition.) Of course, that might introduce a new issue that a “chord diagram” now consists of ribbons rather than chords.

Wikipedia also suggests an alternative name for a chord diagram: a radial network diagram, which is nicely specific. I suppose “chord network” or “ribbon network” might also be a decent name.

[mbostock]

Another thing I don’t like about how I’ve used chord diagrams for visualizing flow networks in the past is having to pick either in-flow or out-flow to size the groups. This isn’t an issue if the flow is symmetric, as when showing similarities between genomes.

For example, in this alternative to a Bill Marsh graphic showing European debt, the left chart sizes by credit, and the right sizes by debt:

If you size by credit, then the United States is invisible since they only have debt (almost $2T of it). But if you size by debt, then Japan is nearly invisible since they almost exclusively have credit ($7.7B in debt, $1T in credit).

If you used unidirectional chords as in the migrant flow chart above, then you could size the groups (the countries) by credit + debt, which might work better. But then you need an arrow head or equivalent to indicate the direction of flow.

[jasondavies]

I think directional ribbons with a simple triangular arrow head would be a great addition. The “ribbon” terminology is also used in parallel sets.

[mbostock]

Okay, I’ve created a d3-chord module, so we’ll put the chord shapes and layouts there. I think that’s appropriate given that chord diagrams are relatively specialized compared to your standard line & area charts.

[mykabir]

Can you give any idea how to draw a parallel relation ship like chord diagram?

[curran]

@mykabir Perhaps a Sankey diagram? https://bost.ocks.org/mike/sankey/