New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mollweide latitude grid #2306
Mollweide latitude grid #2306
Conversation
@@ -1657,7 +1657,7 @@ def _get_pixel_distance_along_axis(self, where, perturb): | |||
# do things correctly, we need to use rmax instead of 1e-10 for a polar axis. But | |||
# since we do not have that kind of information at this point, we just don't try to | |||
# pad anything for the theta axis of a polar plot. | |||
if self.axes.name == 'polar': | |||
if self.axes.name != 'rectilinear': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this might break things for mplot3d. I see what you are trying to fix, but there has to be some other way to identify the axes that should have 0 returned for this function. Perhaps each axes type should have a function defined for themselves to return the appropriate value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that would be an actual API change and would require modifications to many axes subclasses so that the gridlines would appear.
What if we change this back to if self.axes.name == 'polar'
, but then If the return value of this function is nan
(because transform can't give meaningful answers outside of projection region), the pixel distance is assumed to be 0?
@WeatherGod, if you like this, I can squash together commits 1a2a0bb and 1977776. |
👍 from me if @WeatherGod agrees. And it should be backported to |
The function _get_pixel_distance_along_axis does not work for geographic axes, in which pixels that are outside of the map area cannot be meaningfully transformed back to data coordinates. If the return value was nan, set to 0.
Squashed all commits. |
Actually, I think this is a perfectly good solution (much better than my idea). |
I see this Travis failure:
but it appears to be unrelated. And I have found from recent experience that restarting the build fixes it. This seems to happen only under Python 3. |
That is a weird bug, and the RMS error on it is extremely tiny. Could it possibly be a discrepency in different versions of the baseline image (or how they are loaded up)? |
Travis build fixed itself again. @WeatherGod, is there anything else that you want to see in this PR? |
LGTM +1 |
@@ -1190,6 +1190,14 @@ def test_transparent_markers(): | |||
ax = fig.add_subplot(111) | |||
ax.plot(data, 'D', mfc='none', markersize=100) | |||
|
|||
@image_comparison(baseline_images=['mollweide_grid'], remove_text=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know its been merged so we don't need to worry about it, but for future reference we only needed to test one file format (png would be great) - this isn't a backend issue so we needn't repeat out testing.
The function
_get_pixel_distance_along_axis
does not work for geographicaxes, in which pixels that are outside of the map area cannot be
meaningfully transformed back to data coordinates. To be safe, let us
just return
0.0
unless we are onrectilinear
axes.Fixes #2299.