Arrow in polar plot broken #5344
Comments
|
Good catch, and indeed a problem. The fix may be tricky, however... |
|
I concur;
I can confirm that the |
|
Another workaround is to create the arrow at 0-angle, since you've found that it works, then provide a transform to the location you want: fig = plt.figure()
ax = fig.add_subplot(111, polar=True)
ax.arrow(0, 0, 0, 0.8, linewidth=3, width=0.005,
# Remember that you're working in (theta,r) space before the data transform.
transform=mtransforms.Affine2D().translate(np.pi/2, 0) + ax.transData)
ax.yaxis.set_ticklabels([])
ax.tick_params(axis='both', which='major', labelsize=20)but this becomes a bit troublesome if you want to place it in an arbitrary location. |
|
Nice work-arounds, thanks! For me though, a new requirement popped up, in having to draw the arrow inside an ellipse instead of a circle, so I guess I will have to go to free-drawing both elements, and then I might as well do it in a normal plot and switch the axes off. |
|
If you replace the code in patches.py with Then the arrows have both left and right parts drawn fully, they're just pointing in the same wrong directions |
|
The |
|
Its not the list of points generated by ax.arrow() thats the root of the problem, I've tried a few of the lines, they seem to generate passable arrows (when I stick them in gnuplot and see what happens). Must be just the polar plot itself thats rotating points too much. |
|
polartransform.transform_non_affine() is converting this:
into this:
|
|
Yes, that's expected. You are essentially plotting data-space and axes-space (modulo the affine part of the transform) as Cartesian, but they aren't really the same coordinate system. For a polar plot, the data space is (theta,r), so the first plot really shouldn't look anything like the "correct" arrow you see. An addition to the theta component (or "x" in the first plot) results in greater rotation of the arrow head, which is clearly evident in the second plot. The problem with |
|
@QuLogic: I agree. I think we need a new version of arrow that calculates the tip entirely in Cartesian regardless of the underlying projection (though it probably needs to get its orientation from the underlying projection). |
|
well, here's the patch to fix the arrowhead, if you want it. CR #5392 |
|
Just a status update. Linux, Python 2.7, on master ( import matplotlib.pyplot as plt
import numpy as np
fig = plt.figure(figsize=(6.4, 6.4))
for sub, lw, w in [(221, 3, 0.005), (222, 1, 0.005),
(223, 3, 0.05), (224, 1, 0.05)]:
ax = fig.add_subplot(sub, polar=True)
ax.set_yticklabels([])
ax.set_title("linewidth={lw}, width={w}".format(lw=lw, w=w))
for rad in np.pi*np.arange(0.0, 2.0, 0.25):
ax.arrow(0, 0, rad, 0.8, linewidth=lw, width=w)
plt.tight_layout()produces
|
|
I'm going to close this as "it's basically behaving as expected (for an arrow drawn fully in data space); you should anyways use Axes.annotate" (and see the arrow_guide.py example as well). As always feel free to reopen if you disagree. |
It works fine only at angle 0, otherwise the arrow head is corrupted.
Using this code:
Here's how it looks:
At zero for 3rd parameter of above arrow call, it looks okay, but only there:
Version: master on OSX, in the notebook, seen both with
inlineandnbaggbackend.The text was updated successfully, but these errors were encountered: