Plotly.js: `fromto` trace type proposal

[nicolaskruchten]

I'd like to propose a new trace type, provisionally called fromto, which would be inspired partly by ggplot2's geom_segment (paging @cpsievert!)

The behaviour would be to draw onto cartesian axes a line segment from x/ y to xend/yend (all 4 being data arrays) with the ability to specify what the start/end points look like: arrows, points etc. More advanced variations might include curved lines, or manhattan lines or whatever. We would be able to reuse a lot of pre-existing machinery to do this: lines, points, arrows from annotations etc :)

The use-cases for such a trace-type are multiple:

1. Gantt charts (both for the time-bars and for the dependencies!)
2. Connected dot-plots
3. Quiver plots
4. The 'link' portion of a node-link diagram

[alexcjohnson]

Interesting idea @nicolaskruchten - I like it. I do recall hacking something like this at least once myself:

Perhaps we generalize a bit so x and y are required, but then you can have xend (absolute) or dx (relative) or neither (start = end for x), and yend or dy or neither, as long as either x or y (or both) has endpoint data.

I'm not sure about using this for Gantt - it would work for presentation, but not for analysis. Better than current options but perhaps not our final answer on the topic...

Some potential name options: link? segment (per R)? pair is already used as a synonym for splom, maybe couple, couplet, or doublet?

[etpinard]

Thanks for writing this down @nicolaskruchten !

Referencing https://github.com/plotly/plotly.js/issues/147 and https://github.com/plotly/plotly.js/issues/581 which could benefit from this development.

Quiver plots

Here I disagree though. Quiver plots could surely use the same renderer (i.e. the _module.plot method), but I think the attributes for quiver plots should be similar to our 3D vector field trace types (cone and streamtubes) where we have coordinates arrays (x and y) and velociity componente arrays (u and v).

[alexcjohnson]

Quiver plots could surely use the same renderer (i.e. the _module.plot method), but I think the attributes for quiver plots should be similar to our 3D vector field trace types (cone and streamtubes) where we have coordinates arrays (x and y) and velocity component arrays (u and v).

Good point - generally neither head nor tail will be exactly at (x,y) but somewhere in the middle, and velocity doesn't have the same units as (x,y) - actually, depending on how we want it to scale with zoom, it's possible we wouldn't even want the same plot method, so we can create a group for each arrow for efficient scaling.

I guess it's in the same category as Gantt, that we could use this kind of trace to more efficiently display a quiver plot, but it's not really natural for the data, would require a bunch of preprocessing.

[nicolaskruchten]

Thanks for considering this idea!

@alexcjohnson can you say more about

I'm not sure about using this for Gantt - it would work for presentation, but not for analysis. Better than current options but perhaps not our final answer on the topic...

please?

I'll admit that this is likely not the final word for quiver plots but for both 2-point connected dot-plots and Gantt charts this seems totally reasonable to me, just with different formatting options...

[alexcjohnson]

When you use Gantt charts for analysis, they contain features that would need to be precomputed if done using a 2-point framework:

• dependencies: you set a duration for a certain task, but rather than a start time you want it to be "as soon as tasks X, Y, and Z are finished" and perhaps even resources "don't allocate Bob to two tasks at once"
• aggregations: you may want to group tasks, functionally (permitting, engineering, construction, testing...) or in some other way, and display the composite durations, possibly with the option to collapse the details.

I don't expect we're going to build an entire project management tool inside plotly.js, but some of these would be straightforward extensions that seem to me they'd add a lot of value over simply presenting a static chart, and they would not be possible using this more general trace type.

[nicolaskruchten]

Makes sense, thanks for expanding!

So I think this trace type still makes sense even if it's just mainly aimed at connected-dot-plots of the type you made above or the more boring shared-x case. And if we build this, we give nicer JS-level (i.e. Chart Studio-level!!) support for building simple, non-automated Gantt charts, and we can refactor stuff like the figure factory (which itself doesn't today support dependency and subtask modelling, right?), and this is a 'building block' trace type that can be used to approximate all sorts of other things like quiver plots, until such time as we can build out "proper" ones :)

[akhmerov]

Speaking of gantt: I had a use case of plotting a distribution of grades for each problem within an exam. This is neatly represented by a plot like this: http://antonakhmerov.org/misc/plotly_summary_test.html

Interestingly, a stacked bar chart was too limiting because all bars within a group must have the same color. Therefore I hacked my way around this limitation by (ab)using a gantt chart. A fromto trace would of course suit this purpose more naturally.

[johentsch]

IMHO this feature would make Plotly the greatest plotting library of all!

It has been mentioned in several places (e.g. in #147) that it is needed for professionally plotting weighted and potentially directed network plots. Not only do you want to set direction, width and color of edges (which you can awkwardly do with annotations), you also want them to be data themselves with their own hover information giving information about weights and (in the case I am currently working on) previous nodes included in the path.

[deecay]

If one axis can be category like this one, it would be really great.

[jackparmer]

This issue has been tagged with NEEDS SPON$OR

A community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.

Sponsorship range: $25k-$30k

What Sponsorship includes:

• Completion of this feature to the Sponsor's satisfaction, in a manner coherent with the rest of the Plotly.js library and API
• Tests for this feature
• Long-term support (continued support of this feature in the latest version of Plotly.js)
• Documentation at plotly.com/javascript
• Possibility of integrating this feature with Plotly Graphing Libraries (Python, R, F#, Julia, MATLAB, etc)
• Possibility of integrating this feature with Dash
• Feature announcement on community.plotly.com with shout out to Sponsor (or can remain anonymous)
• Gratification of advancing the world's most downloaded, interactive scientific graphing libraries (>50M downloads across supported languages)

Please include the link to this issue when contacting us to discuss.