Thanks--I thought it should work, but when I tried it and it didn't, I
failed to look more closely.
Now a question: is there a reason why the argument order for polar
plotting is (theta, r)? In thinking about polar coordinates, I always
think of them in the reverse order (r, theta), and I think this is the
way I have always seen polar coordinates in math and physics books.
John Hunter wrote:
>>>>>>"Eric" == Eric Firing <efiring@...> writes:
> Eric> Polar axis support is embryonic; I don't see an easy way to
> Eric> make a polar bar chart. You could make the bar outlines
> Eric> using "plot" on a polar axis.
> Although polar support is patchy, it usually can be made to work. Eg,
> it already handles most types of objects (text, lines, collections).
> I took a look and noticed that it did not draw it's patches, though it
> stores them and handles the transformations properly. This is simply
> one line sin of omission (which I've fixed in svn), ie I needed to add
> the patches to the list of artists being drawn in PolarAxes.draw.
> Here is a little script that shows how to add "rectangles" to polar
> plots (requires svn 2258)
> from matplotlib.patches import Rectangle
> from matplotlib.axes import PolarSubplot
> import matplotlib.cm as cm
> from pylab import figure, show, nx
> dtheta = nx.pi/8
> r = 1
> theta = 0
> fig = figure()
> ax = PolarSubplot(fig, 111)
> N = 15
> for i in range(N):
> frac = float(i)/N
> rect = Rectangle( (theta, 0), dtheta, r, facecolor=cm.jet(frac))
> theta += dtheta
> Although I don't have experience with windrose plots, this can
> probably serve as the foundation. The autoscale view functionality is
> clearly off, but it mostly works. One can do the same with arbitrary
> patches (eg Polygons), as long as you construct vertices where the
> x/width attribute is interpreted as radians, and the y/height
> attribute is interpreted as radius.