Fix twoslopenorm colorbar #20582
Fix twoslopenorm colorbar #20582
Conversation
bd4102c to
78ddee0
Compare
You could also write that |
78ddee0 to
9ef1caa
Compare
|
As a general question, do you actually want to add extrapolation to these functions, or should we just set the left/right bounds to -inf/+inf to not make any assumptions beyond the data interval? np.interp([self.vmin, self.vcenter, self.vmax], [0, 0.5, 1], left=-np.inf, right=np.inf) |
266eac6 to
a2f5a77
Compare
|
@greglucas Yep, you are right, that works as well and is more elegant. |
a2f5a77 to
38ad08e
Compare
| # defining your own norm. Note for the colorbar to work, you must | ||
| # define an inverse for your norm: |
There was a problem hiding this comment.
I wonder if it would make sense to create an abstract base class for Norms that raises NotImplemented for inverse() so that it doesn't accidentally work with a colorbar? (I think right now it is inheriting the inverse from the standard "Linear" Normalize class. We could catch the NotImplemented in the Colorbar code and warn appropriately there that the inverse method needs to be implemented.
There was a problem hiding this comment.
I think that would be sensible.
|
I feel like the custom norm example never intended the 0 to be in the middle; maybe it needs to be written another way? |
|
I wrote that example and indeed it's pretty common for water depths to have a different vertical scale than land relief. If you want the size of the color ranges to be proportionate you would make the color map disproportionate with more land colours than ocean colours. But that is the opposite of the desired effect here. |
|
Ah, I see that was mentioned in the |
|
The first sentence of the example says that it is the same as the TwoSlopeNorm example? |
|
Or I'm just blind today... |
PR Summary
Closes #20581
#20054 makes it so the scale on a colorbar is set via the norm, and the inverse of its norm. The problem with scales, and tickers, is that they seek ticks beyond the min/max of their axis. PreviouslyTwoSlopeNorm linearly interpolated between vmin and vcenter and vcenter and vmax, but anything beyond vmax or less than vmin was also mapped to 0 and 1. So in the broken example a tick was sought at -1000, with vmin =-500. The norm processed this as 0 instead of a negative number, and hence it showed up on the axis.
Here we fix that by simply doing some linear extrapolation on the TwoSlopeNorm and its inverse.
np.interpdoesn't have linear extrapolation by default, and we can't use scipy, so just do it by hand. (yes I know thatvcenter - 2 * (vcenter - vmin) = 2 * vmin - vcenter, but that is not as easy to parse).PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).