Plotly.js: Rangeselector is not relative to X-axis data in scatter/lines+marker plots
When drawing a scatter plot with a mode of lines+marker with an xaxis rangeselector enabled, changing ranges results in a range being shown that isn't relative to the actual data itself.
My example is at https://codepen.io/davidjb/pen/dJYWaV (a fork of the example from https://plot.ly/javascript/range-slider/) -- changing between lines and lines+markers down the very bottom shows the difference in behaviour.
With a mode of lines, a plot's X axis ends where the data does, and so choosing 1m, 6m and so in the range selector result in a plot that shows that during from the end of the dataset. In lines+markers, however, choosing a range is relative to the end of the original plot, resulting in an empty or partially empty plot because the range will extend past the end of the dataset. Depending on how spread out your data is, this could result in a fully empty plot (like the example, where it shows a range in 2019 for a dataset in 2016) or a partially visible trace on the left-hand side.
My expectation was that the rangeselector would always operate relative to the data -- so in this case being the same behaviour between lines and lines+marker.
Seems related to #928, with regards to the 'padding' on the far right of the plot. Example tested with plotly.js 1.13.2 (latest at time of writing).
davidjb
All 16 comments
Good point @davidjb - we hadn't considered padded ranges like you get with markers in the behavior of range selectors, but it's pretty useless this way. See also #1876 - the right way to solve the issue here probably needs to be a new autorange mode (which can account for data) rather than a calculation based on the current range as we have now (which knows nothing about the data). This would also be useful for streaming plots where you always want to see for example the last 15 minutes of data.
alexcjohnson
on 16 Dec 2017
Related: if you zoom in on the plot some other way, and change the right edge, that new value gets used as the "now" end of the range selector, rather than referencing the latest data. This aspect too would get fixed by folding range selectors into autorange.
alexcjohnson
on 18 Dec 2017
Any update on this?
ethanopp
on 26 Aug 2019
Hitting same limitation here.
You can calculate your own range, based on the data instead of autorange, and will fix the offset / padding problem when using rangeselector.
However this will cause the following problem: jumping between your own range -> autorange -> back to range when double clicking consecutively the chart to reset the zoom / range.
dan8f
on 20 Sep 2019
However this will cause the following problem: jumping between your own range -> autorange -> back to range when double clicking consecutively the chart to reset the zoom / range.
This problem can be fixed via:
etpinard
on 20 Sep 2019
However this will cause the following problem: jumping between your own range -> autorange -> back to range when double clicking consecutively the chart to reset the zoom / range.
This problem can be fixed via:
Good point @etpinard . Thanks!
dan8f
on 22 Sep 2019
Double click is not the only issue, the axis don't line up when using range selector buttons either...
...Looking for a python solution myself
ethanopp
on 22 Sep 2019
Double click is not the only issue, the axis don't line up when using range selector buttons either...
...Looking for a python solution myself
@ethanopp what do you mean by axis don't line up, could you share an example please?
If it is as per the example provided by davidjb (showed range outside data range on selector button click), a custom range should contain it.
dan8f
on 22 Sep 2019
@dan8f The actual axis is filtered correctly, but the lack of padding cutts of portions of the actual chart since lines+markers go OVER the exact position on the x axis.
Here's an example:
https://imgur.com/a/C7mnndv
ethanopp
on 23 Sep 2019
That is clear. My comment wasn't an actual solution but just trying to go over the limitation.
Probably that is the best you can get with the current solution. Maybe you could try to add some 'padding' to your calculated range (extra range at start & end) and add some extra range to your buttons too to cover the extra padding?
dan8f
on 23 Sep 2019
Unfortunately it happens even at the daily level, so even if i just add -1 day to x min and +1 day to x max it still shows half of the next day's bar...
ethanopp
on 23 Sep 2019
If I understand correctly you would need dynamic range calculations with their respective padding (to cover the bars) and dynamic buttons' count for range selectors too (to cover the offset generated by the padding). Not ideal at all...
For example in the screenshot shared with 'week'' button pressed your calculated range (in blue) would have +- 4 days extra padding and buttons would account for their range + the padding (in red).
dan8f
on 25 Sep 2019
The calculated range (red) is driven by the L6W (last 6 weeks) range selector button. The larger buttons at the top are separate html buttons which trigger a callback that drives the aggregation of each bar. So if “day” we’re selected and L6W, there would be 42 bars in the red range...
That’s besides the point though...those larger buttons are not what cause the issue, it’s just whenever using a regular range-selector button on a chart that has markers+lines, there is no padding for the actual end images (in this case bars) as the bars get centered on the x axis values and the range selector filters EXACTLY on the x axis values, so the minimum X axis value left hand portion of the bar is always cut off, and the max x axis value right half is cut off
The blue range is just all the data, so when the “all” range selector button was selected
ethanopp
on 25 Sep 2019
Has this been fixed or is there any way around it? I tried fixing the range manually but it does not work with the buttons in "backward" mode. The plot starts zoomed in the correct range, but the count for "1 month backward" starts from 3 months in future w.r.t. to my latest date. Moreover fixing the range just determines a correct zoom, not the maximum range of the data to see
alberto-bracci
on 30 May 2020
+1.
Same behaviour.
pacocom
on 23 Jul 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: $5k-$10k
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.
jackparmer
on 10 Sep 2020
Related issues
pynklu
·
3Comments
deecay
·
3Comments
HunterMcGushion
·
3Comments
danielsamuels
·
3Comments
emanuelsetitinger
·
3Comments