Rangeselector is not relative to X-axis data in scatter/lines+marker plots

[davidjb]

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

[alexcjohnson]

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]

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.

[ethanopp]

Any update on this?

[dan8f]

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.

[etpinard]

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:

plotly.js/src/plot_api/plot_config.js

Lines 160 to 174 in 56f6983

	doubleClick: {
	valType: 'enumerated',
	values: [false, 'reset', 'autosize', 'reset+autosize'],
	dflt: 'reset+autosize',
	description: [
	'Sets the double click interaction mode.',
	'Has an effect only in cartesian plots.',
	'If *false*, double click is disable.',
	'If *reset*, double click resets the axis ranges to their initial values.',
	'If *autosize*, double click set the axis ranges to their autorange values.',
	'If *reset+autosize*, the odd double clicks resets the axis ranges',
	'to their initial values and even double clicks set the axis ranges',
	'to their autorange values.'
	].join(' ')
	},

[dan8f]

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:

plotly.js/src/plot_api/plot_config.js

Lines 160 to 174 in 56f6983

	doubleClick: {
	valType: 'enumerated',
	values: [false, 'reset', 'autosize', 'reset+autosize'],
	dflt: 'reset+autosize',
	description: [
	'Sets the double click interaction mode.',
	'Has an effect only in cartesian plots.',
	'If *false*, double click is disable.',
	'If *reset*, double click resets the axis ranges to their initial values.',
	'If *autosize*, double click set the axis ranges to their autorange values.',
	'If *reset+autosize*, the odd double clicks resets the axis ranges',
	'to their initial values and even double clicks set the axis ranges',
	'to their autorange values.'
	].join(' ')
	},

Good point @etpinard . Thanks!

[ethanopp]

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

[dan8f]

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.

[ethanopp]

@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

[dan8f]

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?

[ethanopp]

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...

[dan8f]

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

[ethanopp]

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

[alberto-bracci]

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

[pacocom]

+1.
Same behaviour.

[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.

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.

[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