feature request: scale extents a bit more than the absolute fit

[basnijholt]

Right now:

hv.Scatter([[-1,-1], [-1, 1], [0, 1], [1,1]])

gives points that you cannot even see:

Preferably the plot would take the extent and make it 10% bigger or so, like:

hv.Scatter([[-1,-1], [-1, 1], [0, 1], [1,1]])[-1.1:1.1, -1.1:1.1]

which does show the points:

[philippjfr]

Agreed, this is something we should have added a long time ago. All our plots should automatically pad the axis ranges by a few percent. The question has always been how precisely the padding is calculated. Is it a fixed 10% or is there special handling around zero? Other plotting libraries have had this discussion (see matplotlib/matplotlib#4891) and have generally settled on a fixed 4-5% padding along each axis:

The easiest way to handle this is to simply ensure that the axis limits are slightly larger than necessary to cover all the data, and then leave it at that. It avoids the really nasty cases, avoids surprises, and if people want something fancier than they almost always have to tweak the limits by hand anyway. As further evidence that this works, this is what R does and it basically just works -- no-one complains.

Specifically, base R calculates default axis limits by: taking the min and max of the data, and then setting the limits 4% further beyond each of those. ggplot2 uses a similar algorithm, but uses 5% by default. (See here, semantics of expand= is (multiplicative expansion, additive expansion).)

If we agree with both matplotlib and ggplot2 (and bokeh?) that's what we can use by default as well. It's trivial to do and I strongly believe this belongs in 1.7 as part of changing our global styling defaults (#823).

[jbednar]

I agree.

[jlstevens]

I think this is a good idea and I agree that we should use someone else's magic value for this parameter (and stick to it). My preference for conventions would be to follow that matplotlib does, then bokeh and then ggplot2.

[philippjfr]

They all do the same thing 5% padding on each end of an axis.

[jbednar]

5% it is, then!

[philippjfr]

Note that I do not want to add automatic padding to raster types because it's ugly. Therefore I'd suggest a plot option, which has different defaults for chart and raster plots. The difficulty then is figuring out what happens when overlaying the two. I'd suggest the bottom layer determines the padding since that will usually be the raster type.

[jlstevens]

I would be tempted to say that if there is any raster type in the overlay, don't apply any padding.

[jbednar]

Either of those two policies seems fine, as long as we choose it and stick with it. Whichever one seems more consistent with other things we do where one layer needs to determine the overall behavior.

Presumably a GeoViews tile source wouldn't count as a raster, for this purpose? Those generally have effectively infinite extent, and thus expanding to show the points or box seems appropriate.

[philippjfr]

Let's try implementing this for 1.7, setting the margin parameter to zero and then add some default padding in 2.0.

[jbednar]

Sounds like a good plan. Do we want to make a 2.0 branch now, to include these breaking changes, that we keep rebasing as needed, so that we can try out the new version in practice? If it's just a parameter change as in this case, seems like such rebasing will be simple.

[philippjfr]

Sounds good, I'll open one as soon as there is a breaking change I can apply to it.

[jbednar]

Changing the default colormap could be the first one. :-)

[philippjfr]

So this turns out to be a bit more complex than anticipated. The main question is what this should apply to, we have the data ranges, explicitly set ranges and extents. Presumably it should not apply to explicitly set values, but currently we have no way of distinguishing a Dimension.range from a data range and the get_extents method in plotting and the normalization system are not set up to handle the distinction between the two. The other complication are log axes where computing padding requires some transforms.

At minimum this will require #1212 to be implemented but probably requires at least a partial rewrite of range handling in general. I'm unfortunately going to have to postpone this until 2.0.

[philippjfr]

This has finally been merged, we should however decide whether to enable padding by default in 1.11 or wait on another release and pre-announce the change as part of the 1.11 release notes.

[philippjfr]

We have definitely decided not to enable this by default in 1.11.

[jlstevens]

@philippjfr @jbednar I assume it is now time to switch this on immediately after the upcoming release?

I assume the diff will be to set this value to 0.05. To achieve 5% padding. Then we can add something in the release notes to help people set it back to zero if they want to restore the old behavior.

[philippjfr]

I assume the diff will be to set this value to 0.05

Not sure, I usually use 0.1 for 5% padding on each end.

[SandervandenOord]

I hope padding can be added as a default in one of the upcoming releases, as I find myself continuously setting xlim and ylim manually.

[basnijholt]

Happy we were able to close this with a successful end 3 years later 😂 🎉

[SandervandenOord]

I just tested this with the newest holoviews for scatter and bar. Works nice. What a difference a little bit of padding makes for the way plots look :)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.