Axis auto-range improvements

[etpinard]

This issue attempts to combine ideas from several individual feature requests into coherent picture (i.e. the least number of new attribute possible).

In a private conversation with @alexcjohnson , we proposed adding two new (cartesian) axis attributes: bounds and boundmode. bounds would expect 2-item array values similar to the current range. bounds can be thought of as representing the maximum possible extend of the axis ranges. In turn, boundmode would determine if bounds applies during the auto-range routine (i.e. on first view - discuss in https://github.com/plotly/plotly.js/pull/1861#issuecomment-314518657) or during interactions as well (as proposed in https://github.com/plotly/plotly.js/issues/887). For example,

xaxis: {
  autorange: true,
  boundmode: 'soft',
  bounds: [0, 100]
}

would restrict the auto-range logic to compute an x-axis range between 0 and 100. This might be useful when plotting percentages where users don't want the axis ranges to go beyond 100%.

xaxis: {
  boundmode: 'hard',
  bounds: [0, 100]
}

would restrict the axis range to [0,100] in the auto-range logic and during interactions.

In doing so, 1-way bounds values such as [null, 100] or [0, null] should be allowed. null items here mean don't restrict the min (or max) bound acting. This behavior is similar to cmin and cmax for color scales. This call signature should also be extended to the axis range attribute - taking care of https://github.com/plotly/plotly.js/issues/400

---

A few more things to think about:

• Adding a 'tight' value for axis autorange would take care of https://github.com/plotly/plotly.js/issues/928
• Maybe adding 'once' value for axis autorange for https://github.com/plotly/plotly.js/issues/1849
• Maybe allow span axis range (and bounds) values for https://github.com/plotly/plotly.js/issues/387

[alexcjohnson]

One other idea we've discussed is autoranging one axis based on only the data that's visible on the opposite axis or axes - for example zoom in on a particular x range and autorange y based only on the x data in that range. Perhaps autorange: 'visible'?

[petergaultney]

Thanks to @cldougl for pointing me in this direction. I just want to throw my 2 cents in and say that, as per plotly/plotly.py#826, it would be nice if plots where all traces set fill tonexty or tozero did not automatically (or could be configured not to) eliminate all padding on the X and Y axes of cartesian plots. My use case involves adding markers to the lines that make up the filled traces, and those markers get "cut off" near the edges by the forced elimination of all padding around the plot.

[alexcjohnson]

@petergaultney thanks for the note - we definitely intend to make all of this more configurable. But another (fairly new) option that might be useful to you is plotly/plotly.py#1861 - cliponaxis: false, perhaps in conjunction with the layout option margin.pad.

[petergaultney]

sure enough, with those two options combined my problem is actually solvable. I set cliponaxis=False on each of my traces, and then added margin.pad on the layout. thanks!!

[etpinard]

There's also https://github.com/plotly/plotly.js/issues/1022 about adding rangemode="symmetric" which sounds very reasonable.

[alexcjohnson]

From plotly/plotly.py#2083 - certain trace types (bars, fill to zero) currently force the axis autorange to include zero. We should let the user override that.

[apalchys]

Does anyone have a clear picture how to combine all ideas?

Since https://github.com/plotly/plotly.js/issues/2158 closed in favor of this issue, I am ready to contribute but I think I need some guidance.

[etpinard]

Since plotly/plotly.py#2158 closed in favor of this issue, I am ready to contribute but I think I need some guidance.

For resolving plotly/plotly.py#2158, I think all you need (API-wise) is adding autorange: 'once'.

That is, autorange: true (set or implied) would auto-range the axes every time new data comes in. autorange: 'once' would corresponds to the current (arguably-wrong) behavior.

[apalchys]

@etpinard sorry, I am a little bit confused. Based on the discussion above, I need autorange:'visible', not autorange:once

Demo: https://codepen.io/plotly-demo/pen/JOERgj Expect behaviour for plotly/plotly.py#2158 is to enable autorange when a user changes visible area or scroll zoom in/out. @alexcjohnson described it here https://github.com/plotly/plotly.js/issues/1876#issuecomment-314913229

Nevertheless, autorange: 'visible' brings an issue. For example, I want to have autorange when new data comes (auto) and enable autorange when a user interacts with a chart (visible). It leads to an issue: autorange should be flaglist not enumerated, but some values are mutually exclusive. I suggest to keep autorange for the input data only and add a new axis property autosize (?) which will will be responsible for user interactions.

[apalchys]

JFYI: Since this issue is about addressing all auto-range related issues and requires significant amount of time to do in a right way, for now, I will implement a wrapper around PlotlyJS in order to solve my case and continue to watch on progress.

[alexcjohnson]

Per @ IanWorthington in plotly/plotly.py#2439 - we should make sure yaxis.autorange: 'visible' or whatever we end up calling it works with range sliders - ie when you zoom in x with the rangeslider, the y rescales to the visible points.

[jacobq]

I think this use case will be covered by the options discussed above, however, I would like to share it anyway since it hasn't been said explicitly. Often I am working with data sets that whose X or Y coordinates are, for example, only positive, as demonstrated here: jsbin/winaki/6. I would really like to be able to prevent the pan and zoom controls from adjusting the axes to go beyond set limits (instead they should "snap"/"stick"/"rubber band" when they reach them).

[SebastianB12]

Any news on this subject? Especially the "bug" that the y-axis range is not updating when x-axis rangeslider is used (see: plotly/plotly.js#6958, plotly/plotly.py#2439 , #912) and the white spaces when using the "lines+text" mode plotly/plotly.py#1775 . The option yaxis.autorange: 'visible' by @alexcjohnson sounds very reasonable in my opinion. Let me know, if I somehow can help to fast-track the solution by buying a Developer Support plan? I love Plotly, but especially the first function is very basic and very crucial for a lot of use cases.

[grandsmarquis]

Any news for this? The yaxis.autorange: 'visible' is really needed across the forums and is making lot of people moving to other libs.

[dinya007]

Someone know any news about this feature?

[dioscuroi]

Has there been any update?? I'd really love to see the "yaxis.autorange: 'visible'" option supported!

[fenris85]

Any news on this feature? Would be great to have this feature.

[researchintern]

@chriddyp @etpinard Any news for this feature? I think this issue is leading to constant Y-axis scale when I use a slider for X axis, which is not ideal in order to analyze sensitive jumps when sliding into a smaller portion of the graph. Do you think there is any other way to resolve this?

Would greatly appreciate your update on this. Thanks in advance.

[sbussard]

This issue has been open for over two years. What would it take to do an mvp?

[hiramf]

Just wanted to +1 on this.

@etpinard

[julius-datajunkie]

Oh I am so desperate for this feature!

[anton6]

We've started looking for alternatives because we need this feature. Surprised it's been 2 years now.

[chriddyp]

If your organization has a software budget and needs this feature, you can prioritize & sponsor the development of it by reaching out to our team: https://plot.ly/products/consulting-and-oem/. Much of our development is funded this way.

Otherwise, we'll update this issue when it's planned for an upcoming release. There are no updates at this moment and it is still a good idea.

[MrQubo]

I've made some work towards implementing bounds and boundmode here: MrQubo#3 Works for simple cases I've tested it with.

[markzolotoy]

Any movements here?

[markzolotoy]

If your organization has a software budget and needs this feature, you can prioritize & sponsor the development of it by reaching out to our team: https://plot.ly/products/consulting-and-oem/. Much of our development is funded this way.

Otherwise, we'll update this issue when it's planned for an upcoming release. There are no updates at this moment and it is still a good idea.

I used to have a developer license which was 500 US. I wish I could continue buying it but it's not available anymore. So, what do we who have heavily invested company's time (and money) into Plotly technology do? Go for a custom development provided by your team every time something is not working?

[mikekaminsky]

@markzolotoy yes, that is how open-source software works. I really don't want to get involved in a flame war but I feel someone needs to defend the maintainers here -- they've made this incredibly valuable library open-source and free to use. If you don't like, you are 100% free to move to something else, or pick up the burden of maintenance and contribution yourself.

[nicolaskruchten]

I used to have a developer license which was 500 US. I wish I could continue buying it but it's not available anymore.

Just as a point of clarification: to my knowledge we have never sold Plotly.js licenses. The only license under which it is available is the MIT license.

We have in the past offered developer support plans for $500/year but this did not include custom feature development.

[markzolotoy]

I know how open source works. But you should understand my frustration. The main selling point for me was the development support previously available. We have gone through over a year of a heavy development and got very far mainly because of an excellent support from Plotly engineers. Now, the support is not available and problems I am facing are far from being trivial. Going into Plotly source code is just above my head. I tried SO and it is not much there either.

[nicolaskruchten]

I’m genuinely sorry to hear you’re frustrated. We do try to help out users who post in the community forum with questions and if you run into any bugs you should of course feel free to report an issue here in Github.