You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The x or y coordinates in shapes currently reference exactly one axis each, but if we could allow multiple axis references within one shape, you could link up features in different subplots in a way that reacts as each subplot is independently zoomed or panned.
My interest in this stems from striplogs, a common tool in mining and oil & gas for analyzing drilling data, where you want to correlate features you see in multiple drillholes, for example https://help.rockware.com/rockworks17/WebHelp/striplog_h2h.htm where you can see lines or filled regions that are paper-referenced in their x coordinates, but their y coordinates reference a different axis for each drill hole:
and it could be particularly powerful to pan each drillhole axis separately to align one of these features and see how the other features do or don't line up.
As to API: for simple shapes (lines are the most important one here) this could be accomplished by extending the idea of xref to add x0ref and x1ref (similarly for y). For path shapes (important for the filled areas in the striplog use case) this would need to be handled within the path string, perhaps something like :x3 after a coordinate to describe its reference, so the paths would look like: "M0:paper 470:y H0.2:paper L0.3:paper 392:y2 H0.5:paper L0.7:paper 524:y3 H0.9:paper". Then we could either ignore xref/yref, require you to set something like xref='variable' to opt in to this behavior, or allow an xref and use that for any coordinate for which you omit the reference.
Then when drawing, the pixel coordinates would need to be re-evaluated every time any of the referenced axes was zoomed or panned - which I think we may do today anyway, unlike graph data that just has a svg transform applied to it during a zoom or pan and is only re-evaluated when the interaction is done.
The text was updated successfully, but these errors were encountered:
I'm hopeful that this can happen as well. We have users who like to have drawn lines between two different Y axes on a single X.
Our workaround is to scale Y-axis 2 to match Y-axis 1 and plot both traces on that same axis and just draw the lines between them that way. Not the greatest solution, but it has worked so far to some degree.
The x or y coordinates in shapes currently reference exactly one axis each, but if we could allow multiple axis references within one shape, you could link up features in different subplots in a way that reacts as each subplot is independently zoomed or panned.
This was mentioned a long time ago on the forum: https://community.plotly.com/t/draw-a-line-between-data-points-of-different-subplots/29115 (with a partial workaround suggested by @empet)
and various times on SO, eg https://stackoverflow.com/questions/44670708/draw-line-on-top-of-subplot-to-render-a-zoom-effect
and https://stackoverflow.com/questions/17543359/drawing-lines-between-two-plots-in-matplotlib
My interest in this stems from striplogs, a common tool in mining and oil & gas for analyzing drilling data, where you want to correlate features you see in multiple drillholes, for example https://help.rockware.com/rockworks17/WebHelp/striplog_h2h.htm where you can see lines or filled regions that are paper-referenced in their x coordinates, but their y coordinates reference a different axis for each drill hole:
and it could be particularly powerful to pan each drillhole axis separately to align one of these features and see how the other features do or don't line up.
As to API: for simple shapes (lines are the most important one here) this could be accomplished by extending the idea of
xref
to addx0ref
andx1ref
(similarly for y). For path shapes (important for the filled areas in the striplog use case) this would need to be handled within the path string, perhaps something like:x3
after a coordinate to describe its reference, so the paths would look like:"M0:paper 470:y H0.2:paper L0.3:paper 392:y2 H0.5:paper L0.7:paper 524:y3 H0.9:paper"
. Then we could either ignorexref
/yref
, require you to set something likexref='variable'
to opt in to this behavior, or allow anxref
and use that for any coordinate for which you omit the reference.Then when drawing, the pixel coordinates would need to be re-evaluated every time any of the referenced axes was zoomed or panned - which I think we may do today anyway, unlike graph data that just has a svg transform applied to it during a zoom or pan and is only re-evaluated when the interaction is done.
The text was updated successfully, but these errors were encountered: