Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for line width/color array? #147

Open
cpsievert opened this issue Dec 24, 2015 · 32 comments
Open

Support for line width/color array? #147

cpsievert opened this issue Dec 24, 2015 · 32 comments

Comments

@cpsievert
Copy link

@cpsievert cpsievert commented Dec 24, 2015

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
Copy link
Contributor

@etpinard etpinard commented Dec 29, 2015

@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
Copy link
Contributor

@etpinard etpinard commented Dec 29, 2015

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
Copy link
Author

@cpsievert cpsievert commented Dec 29, 2015

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 ropensci/plotly#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
Copy link
Contributor

@etpinard etpinard commented Dec 29, 2015

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

@etpinard
Copy link
Contributor

@etpinard etpinard commented Jan 5, 2016

@cpsievert looks like plotly.js could use your suggestion

7b07a25#diff-07ad6761e23a0608bb5079b46cce8951R29

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

@cpsievert
Copy link
Author

@cpsievert cpsievert commented Mar 9, 2016

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

@melvynator
Copy link

@melvynator melvynator commented 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
Copy link

@FilipMiscevic FilipMiscevic commented 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
Copy link

@edward-wilson edward-wilson commented 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
Copy link
Collaborator

@rreusser rreusser commented Apr 2, 2017

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 cpsievert added this to the ggplotly parity milestone May 10, 2017
@cpsievert cpsievert changed the title Support for line width array? Support for line width/color array? May 10, 2017
@cpsievert
Copy link
Author

@cpsievert cpsievert commented May 10, 2017

@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
Copy link
Collaborator

@rreusser rreusser commented May 10, 2017

@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
Copy link

@dfrail24 dfrail24 commented Sep 5, 2017

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
Copy link

@vikram-rawat vikram-rawat commented Oct 11, 2017

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
Copy link

@dfrail24 dfrail24 commented Oct 11, 2017

@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
Copy link

@AlexVvx AlexVvx commented Dec 19, 2017

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

@etpinard
Copy link
Contributor

@etpinard etpinard commented Dec 20, 2017

@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
Copy link

@AlexVvx AlexVvx commented Dec 20, 2017

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

@jusjusjus
Copy link

@jusjusjus jusjusjus commented Jun 22, 2018

Any news?

@rodrigosnader
Copy link

@rodrigosnader rodrigosnader commented Jul 13, 2018

Has the color array feature been added?

@akhmerov
Copy link

@akhmerov akhmerov commented Aug 7, 2018

@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
Copy link

@akhmerov akhmerov commented Aug 7, 2018

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
Copy link
Contributor

@alexcjohnson alexcjohnson commented Aug 7, 2018

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

@akhmerov
Copy link

@akhmerov akhmerov commented Aug 7, 2018

@alexcjohnson you are absolutely right, thanks.

@asherp
Copy link

@asherp asherp commented 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
Copy link
Contributor

@jackparmer jackparmer commented Sep 10, 2020

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
Copy link

@atomsk121 atomsk121 commented 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
Copy link

@Erhannis Erhannis commented 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
Copy link
Member

@nicolaskruchten nicolaskruchten commented Dec 1, 2020

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
Copy link

@Erhannis Erhannis commented 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
Copy link
Member

@nicolaskruchten nicolaskruchten commented Dec 2, 2020

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
Copy link

@Erhannis Erhannis commented Dec 3, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet