Skip to content
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

Fixed bad vector transforms. #2444

Merged
merged 3 commits into from Feb 27, 2014
Merged

Conversation

pelson
Copy link
Member

@pelson pelson commented Sep 20, 2013

I've finally got around to looking at vector transforms in mpl (obviously for Cartopy functionality) and it turns out that quiver/barbs/streamplot all suffer from an almost identical issue with the way they handle the bounding box updates. This bug fix opens up the get_datalim method so that all Collections can override their own behaviour without needing special cases for each of the datatypes.

This has come from a ticket over at cartopy: SciTools/cartopy#351

Note this PR is against v1.3.x.

return self._bbox
transform = self.get_transform()
transOffset = self.get_offset_transform()
full_transform = (transform + transOffset) - transData
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mdboom - do you know which form is the correct one for the collections offsets transform? Notice that this is different to the quiver one - I'm guessing there is something special about either Quiver or QuadMesh which suggests one of them hasn't implemented the correct Collection API...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P.S. That is not something I wanted to fix in this PR - I was actually trying to limit the scope 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure. I wonder if removing get_datalim altogether here (and letting it fall through to the base class) wouldn't also have the correct result...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is the best review action I've ever had - "delete this and see if it works" - and it did! Hurrah 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, now try rm -rf *!

@pelson
Copy link
Member Author

pelson commented Sep 23, 2013

Looks like this makes an image test fail on the travis machine (not on mine though) and the upload has failed. Any ideas @mdboom?

@mdboom
Copy link
Member

mdboom commented Sep 23, 2013

I think I broke the Travis uploading when I tried to move it to a script. I think Travis (presumably for security reasons) doesn't provide those environment variables to scripts. I've moved it back on v1.3.x and master. If you rebase this on the current v1.3.x it might fix it (I haven't verified my theory, but this will be a good test of it.)

@WeatherGod
Copy link
Member

Looks like pickling broke

@pelson
Copy link
Member Author

pelson commented Sep 25, 2013

Looks like pickling broke

Did you get a look at the differences? It doesn't fail on my machine.

@WeatherGod
Copy link
Member

No, I was just reporting what Travis said failed.

@mdboom
Copy link
Member

mdboom commented Sep 25, 2013

In addition, the uploading of results to S3 appears to still be broken. I'm looking into it.

@mdboom
Copy link
Member

mdboom commented Sep 25, 2013

I forgot: The uploading of test results doesn't work on pull requests. The reason for this is that anyone can submit a pull request and "steal" the Amazon S3 keys, whereas those that can commit code to the main repository are at least theoretically trusted 😉.

To get around this, @pelson since you have commit rights to the main repository, you could push your branch to a "staging" branch in the main repo and then monitor Travis for the results, for example:

git push upstream quiver_trans:pelson_staging

@pelson
Copy link
Member Author

pelson commented Sep 25, 2013

Thanks Mike. Will do.

@pelson
Copy link
Member Author

pelson commented Sep 25, 2013

@mdboom
Copy link
Member

mdboom commented Sep 25, 2013

Sorry -- I left an errant cd in the .travis.yml when I last tried to fix it. Should be fixed in 16a051c (v1.3.x) and f071cc00eae6 (master). Rebasing should "hopefully" resolve it.

@pelson
Copy link
Member Author

pelson commented Sep 27, 2013

Ok, I've managed to find that this is related to the plot limits of the pickle test. I've tested the appropriate method with the same data in test_collections, and removed the autolimit for the plot in the pickle test.

@mdboom
Copy link
Member

mdboom commented Sep 30, 2013

Travis doesn't seem to be picking up the latest commit for this PR...

@ajdawson
Copy link
Contributor

ajdawson commented Jan 7, 2014

@pelson - this one seems close, can it be ready before 1.4.0rc1?

@pelson
Copy link
Member Author

pelson commented Jan 9, 2014

I can't download the tar file @mdboom - any ideas?
I've attempted to update the pickle image result file - hopefully that will do the trick.

@mdboom
Copy link
Member

mdboom commented Jan 13, 2014

It seems my AWS account has been deleted. I'll have to investigate further...

@mdboom
Copy link
Member

mdboom commented Jan 13, 2014

Sorry for the false alarm -- my S3 account was under a different e-mail than I was trying.

The issue (and I had to jog my memory here, of course), is that the uploading of test results doesn't work on Pull Requests, for security reasons (otherwise anybody could file a pull request and steal my Amazon credentials). I realize that makes the whole thing less than useful. I should add a message to the log about this so we don't forget in the future.

I believe, however, since you and I have commit rights to the main repo, we can push this branch to a temporary branch in the main repo (e.g. "staging") and Travis should test it. At least I tried that [1] -- let's see if it works:

https://travis-ci.org/matplotlib/matplotlib/builds/16879992

plt.subplot(3, 3, 7)
ax = plt.subplot(3, 3, 7)
ax.set_xlim(0, 7)
ax.set_ylim(0, 9)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like the failure is due to the y-extent of the streamplot plot. Might you need to set these limits explicitly for the streamplot case too?

@pelson
Copy link
Member Author

pelson commented Jan 14, 2014

Thanks for the nudge @ajdawson - you were right about that.

Ok. I think this is properly ready now - the test failure is a known one (#2413).

@pelson
Copy link
Member Author

pelson commented Jan 14, 2014

Thanks @mdboom - I've also tidied up the "staging" branch.

@pelson
Copy link
Member Author

pelson commented Jan 22, 2014

The test failing is a red-herring - would it be preferred if I based this against master rather than v1.3?

tacaswell added a commit that referenced this pull request Feb 27, 2014
Fixed bad vector transforms.
@tacaswell tacaswell merged commit 169a2f6 into matplotlib:v1.3.x Feb 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants