Support for line width/color array?

[cpsievert]

If there are multiple paths in a single trace (separated by null(s)), it could be useful to have a different stroke-width for each path. This way, I could solve this issue, without having to draw a separate trace for each line.

Minimal example here -- http://codepen.io/cpsievert/pen/wMzdME

[etpinard]

@cpsievert I'm not 100% convinced this is worth implementing.

I think adding colorscale functionality to lines would make more sense.

How does R handle this?

[etpinard]

Ooops, my bad, I thought this issue was asking for line.color array support.

@cpsievert splitting trace data aroung null seems a bit magical to me. If other libraries do it, it might be enough to convince me though.

[cpsievert]

I think adding colorscale functionality to lines would make more sense.

I agree, and would be happy to open another issue for that, if you like :)

In the ggplot2 translator, we translate ggplot2 "groups" (which are sort like traces, but share visual characteristics, and don't require a legend) using this null magic since it is more efficient. I was thinking, with this array support, we could translate ggplot2 "size" in similar way (see plotly/plotly.R#340), but after thinking more carefully, it's probably better to have a traces for each group/size/color so we can have better tooltip info for the more typical use cases -- http://docs.ggplot2.org/current/geom_line.html

[etpinard]

@cpsievert keep the issue open. It's idea worth thinking about.

[etpinard]

@cpsievert looks like plotly.js could use your suggestion

7b07a25#diff-07ad6761e23a0608bb5079b46cce8951R29

The more I think about, the more I like this idea.

[cpsievert]

In addition to https://plot.ly/r/reference/#scatter-line-width accepting a data array, it'd also be useful to have https://plot.ly/r/reference/#scatter-line-color accept a data array, so I can convert a plot like this:

qplot(data = economics, x = date, y = unemploy, colour = unemploy, geom = "line")

[melvynator]

I did work on a network graph at the end of this notebook: http://nbviewer.jupyter.org/github/melvynator/DM_FinalProject/blob/master/data_exploration/.ipynb_checkpoints/data_exploration-checkpoint.ipynb
But the problem is I tried to change the size of the edge between two nodes given the value in the similarity matrix but I didn't succeed it. I think my problem and this issue are linked.

[FilipMiscevic]

I'm also trying to visualize networks and having variable line width for each edge would be desirable. Having each individual edge as a trace and setting its width independently works, but is slow in loading and not as responsive when compared to a single trace for each edge (e.g. 200 vs 1 traces). Here's an example: https://plot.ly/~fmiscevi/3/

The loading issue is so significant that the Plotly Powerpoint addin can't display these graphs... I can't be sure but it seems like it just times out while loading. I get the error "Sorry, we had to restart [the add-in] because this add-in wasn't responding."

[edward-wilson]

Adding my support for this request - I am trying to do the same thing (variable Line width) using the plotly for R package. I have multiple paths in my data, separated by NAs to build (financial candlestick data), for which I'm trying to implement dynamic widths based on the volume in that bar (processed into Low, Medium, High categories). A variable color array option would also be great. For now, I'm going to create separate traces as suggested by cpsievert, as I only have 3 different width/color categories. However, this would become an issue if you had more potential width options. Also, it's not great should I wish to change the categories.

[rreusser]

How would per-segment properties be represented? Is there precedent? Would you say:

y = [1, 2, 3, null, 5, 6]
width = [2, 2, 5, null, 1, 1]

Would the first segment get a width of 2 (the first in the segment)? 3 (the average)?

For anyone waiting on this feature, I made a quick codepen illustrating a way to fake it using fills: http://codepen.io/rsreusser/pen/zZepdO?editors=0010

To summarize, it just draws f(x) + width(x) from 0 to 1 and then walks back from 1 to 0 with f(x) - width(x) and draws it as a fill (i.e no lines).

[cpsievert]

@rreusser great idea! I could definitely take advantage of that work-around in ggplotly(), but I'd still need a workaround for color (see #147 (comment))

[rreusser]

@cpsievert fwiw here's a slight extension that pulls out a couple more tricks to make hover work as if it's a normal trace. 😄 Doesn't handle multiple colors though.

http://codepen.io/rsreusser/pen/VbQJzK?editors=0010

[dfrail24]

If we want to vary size/thickness of the lines using add_segments in plot_geo, is this currently not supported? I know we can do it in add_markers, but I'm wondering if there has been any update since this thread was created.

[vikram-rawat]

We need size in lines too. it's even better if we can change the size on hover. because sometime specially in time series analysis you need to highlight the line in context. color can seperate lines but on hover increase in size would make it much more easy.

[dfrail24]

@vikram-rawat Just an FYI, I ended up using leaflet for now to vary the line thickness. It may be an option for you as well, but the lines don't look as pretty on a map though.

[AlexVvx]

I opened pull request related to that feature, could someone review it?
AlexVvx#5

[etpinard]

@AlexVvx your AlexVvx#5 PR doesn't seem to be related to this ticket at all.

In this ticket, we attempt to find an API to set the trace line.width per-segment (as opposed to only per-trace as currently).

[AlexVvx]

I see what you are talking about: this issue is for trace line width, not legend line width. My apologize, will remove reference

[jusjusjus]

Any news?

[rodrigosnader]

Has the color array feature been added?

[akhmerov]

@etpinard, Re:

I'm not 100% convinced this is worth implementing.

One reasonable and potentially important application for varied line style (both width and color) is the network graph (https://plot.ly/python/network-graphs/).

The common use case is to use the line width and/or color to represent the weight of the connection, see e.g. this plot.

[akhmerov]

Within the context of the network graph, it might perhaps be cleaner to introduce a different data type: an array of line segments. This would avoid the null hack in addition.

[alexcjohnson]

Perhaps this belongs with #2876? Would be fairly natural there.

[akhmerov]

@alexcjohnson you are absolutely right, thanks.

[asherp]

A workaround I've found is that graph_objs.Line actually accepts an array of colors. You'll get a deprecation warning that you'll have to ignore.

Btw, another application is visualizing field lines in a magnetic field simulation, which we do all the time in space weather. Colors can be used to distinguish between different types of topology or to look at other parameters that may vary along a field line (temperature, curvature, etc). Often these plots contain hundreds of field lines, and the overhead for storing them as separate traces is unfeasible.

[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: $10k-$15k

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.

[atomsk121]

Another use for this feature is with large datasets.
Adding ~1000 traces made up of 4097 points takes way too long, because the time it takes to add trace goes up as a function of how many traces were already added.
Adding one trace with gaps is much much faster, but there is no way to differentiate between the lines.

[Erhannis]

Is there a reason this feature is difficult to implement? Speaking specifically of color arrays, I notice that scatter3d accepts arrays for line.color - what makes scatter harder/different?

[nicolaskruchten]

At the moment, I believe that for SVG-based traces (i.e. scatter) the line is a single SVG path, but for WebGL-based traces (i.e. scatter3d) each line segment is drawn separately, which is one reason why this is harder to implement for scatter.

[Erhannis]

Hmm. Is there a clear thing-to-do, it's just hard or time consuming? Or is it a problem with no clear solution? For instance, from your description it sounds like the thing-to-do would be to alter the SVG code to make multiple paths when there are multiple colors. Is that highly inefficient or something?

[nicolaskruchten]

There's a mix of both: it's a big change to our codebase, and it's probably a lot less efficient than the current approach, so might require a lot of optimization work in order not to introduce performance regressions.

[Erhannis]

Hmm. Could you rejigger the webgl code to do it, as a stopgap measure? In the meantime, I've found a vaguely acceptable workaround: aligning a scatter3d plot to look like a 2d plot.

    Plotly.newPlot( document.getElementById('plot1'), [{
      x: [-1, 2, 3, 4, 5],
      y: [-1, 2, 4, 8, 16],
      z: [0, 0, 0, 0, 0],
      type: "scatter3d",
      mode: "lines",
      line: {
        color: [0,1,0,0.5,0]
      },
    }], {
      margin: { t: 0, b:0, l:0, r:0 },
      scene: {
        camera: {
          projection: {
            type: "orthographic"
          },
          up: {
            x: 0,
            y: 1,
            z: 0
          },
          eye: {
            x: 0,
            y: 0,
            z: 1
          }
        },
        zaxis: {
          visible: false
        },
        dragmode: false
      }
    }, {
      scrollZoom: false     
    } );

Do you notice any problems with it? (Aside from that you can't change the viewpoint, and the hover-over shows an extraneous "z" coord.) Also, is there a way to zoom in a bit, programmatically? I didn't find any clear params for it in the docs. The above solution leaves a pretty thick margin around my plots, as shown below:

but, if I zoom in with the mouse a bit, it fits much better.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson