Skip to content

Support for line width/color array? #147

New issue
New issue
Closed
Closed
Support for line width/color array?#147
Milestone
 
ggplotly parity
@cpsievert

Description

@cpsievert
cpsievert
opened on Dec 24, 2015 · edited by etpinard

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

Activity

etpinard

etpinard commented on Dec 29, 2015

@etpinard
etpinard
on Dec 29, 2015
Contributor

@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

etpinard commented on Dec 29, 2015

@etpinard
etpinard
on Dec 29, 2015
Contributor

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

cpsievert commented on Dec 29, 2015

@cpsievert
cpsievert
on Dec 29, 2015
Author

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

etpinard commented on Dec 29, 2015

@etpinard
etpinard
on Dec 29, 2015
Contributor

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

etpinard

etpinard commented on Jan 5, 2016

@etpinard
etpinard
on Jan 5, 2016
Contributor

@cpsievert looks like plotly.js could use your suggestion

7b07a25#diff-07ad6761e23a0608bb5079b46cce8951R29

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

cpsievert

cpsievert commented on Mar 9, 2016

@cpsievert
cpsievert
on Mar 9, 2016
Author

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")

rplot

etpinard
added
status: discussion needed
on Apr 6, 2016
MonsieurV
mentioned this on May 30, 2016
etpinard
mentioned this on Jun 21, 2016
melvynator

melvynator commented on Dec 12, 2016

@melvynator
melvynator
on Dec 12, 2016

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

FilipMiscevic commented on Mar 25, 2017

@FilipMiscevic
FilipMiscevic
on Mar 25, 2017

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

edward-wilson commented on Apr 2, 2017

@edward-wilson
edward-wilson
on Apr 2, 2017

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

rreusser commented on Apr 2, 2017

@rreusser
rreusser
on Apr 2, 2017 · edited by rreusser
Contributor

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

screen shot 2017-04-02 at 10 07 56

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
added this to the ggplotly parity milestone on May 10, 2017
cpsievert
changed the title [-]Support for line width array?[/-] [+]Support for line width/color array?[/+] on May 10, 2017

19 remaining items

akhmerov

akhmerov commented on Aug 7, 2018

@akhmerov
akhmerov
on Aug 7, 2018

@alexcjohnson you are absolutely right, thanks.

etpinard
mentioned this on Aug 7, 2018
etpinard
mentioned this on Sep 25, 2018
jonmmease
mentioned this on Nov 22, 2018
asherp

asherp commented on Sep 4, 2020

@asherp
asherp
on Sep 4, 2020

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
added
♥ NEEDS SPON$OR
on Sep 10, 2020
jackparmer

jackparmer commented on Sep 10, 2020

@jackparmer
jackparmer
on Sep 10, 2020
Contributor

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

atomsk121 commented on Oct 8, 2020

@atomsk121
atomsk121
on Oct 8, 2020

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

Erhannis commented on Dec 1, 2020

@Erhannis
Erhannis
on Dec 1, 2020

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

nicolaskruchten commented on Dec 1, 2020

@nicolaskruchten
nicolaskruchten
on Dec 1, 2020
Contributor

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

Erhannis commented on Dec 2, 2020

@Erhannis
Erhannis
on Dec 2, 2020

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

nicolaskruchten commented on Dec 2, 2020

@nicolaskruchten
nicolaskruchten
on Dec 2, 2020
Contributor

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

Erhannis commented on Dec 3, 2020

@Erhannis
Erhannis
on Dec 3, 2020 · edited by 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:
plot_margins
but, if I zoom in with the mouse a bit, it fits much better.

gvwilson

gvwilson commented on Jun 5, 2024

@gvwilson
gvwilson
on Jun 5, 2024
Contributor

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

gvwilson
closed this as completedon Jun 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @nicolaskruchten@rreusser@gvwilson@asherp@cpsievert

        Issue actions
          Support for line width/color array? · Issue #147 · plotly/plotly.js