Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.1k
Mollweide latitude grid#2306
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
lib/matplotlib/axis.py Outdated
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 toif self.axes.name == 'polar', but then If the return value of this function isnan (because transform can't give meaningful answers outside of projection region), the pixel distance is assumed to be 0?
lpsinger commentedAug 23, 2013
@WeatherGod, if you like this, I can squash together commits1a2a0bb and1977776. |
mdboom commentedAug 26, 2013
👍 from me if@WeatherGod agrees. And it should be backported to |
The function _get_pixel_distance_along_axis does not work for geographicaxes, in which pixels that are outside of the map area cannot bemeaningfully transformed back to data coordinates. If the return valuewas nan, set to 0.
lpsinger commentedAug 26, 2013
Squashed all commits. |
WeatherGod commentedAug 26, 2013
Actually, I think this is a perfectly good solution (much better than my idea). |
lpsinger commentedAug 26, 2013
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. |
WeatherGod commentedAug 26, 2013
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)? |
lpsinger commentedAug 27, 2013
Travis build fixed itself again.@WeatherGod, is there anything else that you want to see in this PR? |
WeatherGod commentedAug 27, 2013
LGTM +1 |
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_axisdoes 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.0unless we are onrectilinearaxes.Fixes#2299.