Beeswarm comparison
This example compares two beeswarm techniques for plotting the flare.csv dataset, in which dots are offset vertically to avoid overlap without changing their x-position. A force-based arrangement uses d3.forceSimulation with x, y, and collision forces, while a second arrangement uses the d3-beeswarm plugin. Red coloring and connecting lines highlight deviations from the exact encoded x-value, showing that the force method shifts dots horizontally more than the beeswarm method. Both use SVG rendering and Voronoi cells for interaction.
AI-generated descriptionThis <a href='http://bl.ocks.org/Kcnarf/5f9491610aa5a5c085d48d66164de36a'>block</a> compares 2 techniques that both produces a static beeswarm.
The top most beeswarm is the one from mbostock's beeswarm block. It is implemented using d3-force’s collision constraint. The bottom most beeswarm is produced with the d3-beeswarm plugin I made (see the Github project).
This block aims to understand the differences, advantages and drawbacks of the 2 techniques. I'm focusing this comparison on the capability of the beeswarm to exactly reflect the encoded data (ie. the x-coordinate should exactly reflects the encoded data): the more it's red, the less it represents the encoded data. That's the main reason why the d3.force technique doesn't suit my needs, and why I made the d3-beeswarm plugin.
Here are some thoughts:
- exactly encoded data: this block allows to vizualize the main drawback of a force-based beeswarm, that allows to re-arrange horizontally each dot; note that this behaviour could be considered marginal and not so important, but this is a high-level constraint for my usecase ... One can notice that most of the deviations come when there is some accumulation (see around 600 or around 3200)
- computation time: force-based beeswarm takes more time to be computed, as the d3.force is a generic algorithm that does a lot more than just producing a beeswarm arrangment
- aesthetic: the 2 beeswarms look great; the second beeswarm is less compact because it exactly encodes data; note that the easthetic of the second beeswarm seems 'to go to the right' because data are sorted from max to min before computing the arrangement
- live arrangement: one can decide to vizualize the live arrangement of the force-based beeswarm ... adding the waouhhh effect
- rearrangement: (not experimented) I guess one can easily add/remove/drag a node on the force-based beeswarm, which will in response rearrange itself automatically ... adding the waouhhh effect once again
Acknowledgments to:
- <a href='https://d3js.org/'>D3.js</a> (v4)
- <a href='http://blockbuilder.org'>blockbuilder.org</a>