new Quiver progress

Robert Hetland wrote:

Let me know if you would like to do a quick alpha test before you commit. I'll help to put it through the paces..

-Rob.

Rob,

Thanks. Attached are a diff against svn and a test script to get you started. If you apply the diff as a patch, you should be able to call quiver2 from the pylab interface. Docstrings are provided. I made no attempt to copy the kwarg part of the API from the old quiver; this one is just too different. Most of the arg part of the API is the same, except that the optional third or fifth argument is a mappable array instead of a scale; I made the scale a kwarg, and it operates completely differently from the one in the old quiver--but for good reason, I think.

The key idea for the scale is that the "units" kwarg establishes a unit of measure ("arrow unit") for the arrows, and the scale gives the U,V data units per arrow unit. For example, if units="inches" and you have a 1 m/s velocity vector, then setting scale=2 will mean 2 m/s per inch, and the vector will be half an inch (assuming the figure dpi value is correct), regardless of how you change the window size or zoom. If units="x", and your x-axis goes from 0 to 50 km, then you might set scale=1/5.0 so that 1 m/s corresponds to 5 km along the x-axis; if you zoom in, the vector will grow. If units="width" (present default, though maybe not a good one), then the unit is the width of the plot, so you might make scale=50, so that 1 m/s makes an arrow 1/50th the width of the plot. Change the window width, and the arrow length changes along with it. Zoom, and it does not change, however. In all cases, the arrow direction remains constant, regardless of window or view limit manipulations. (This is all because of John's transform magic--it is a little hard to understand at first, but it certainly provides wonderful functionality.)

There is a simple auto-scaling algorithm, so one does not have to specify the scale kwarg initially.

Once quiver.py is in place, I will add related functionality such as ellipses, so you can plot mean velocities and standard error ellipses, for example.

One thing I have not looked into yet is what it will take to do all this correctly with polar axes and with basemap, which I will need.

Eric

quiver.diff (14.1 KB)

quiver2_demo.py (1.09 KB)

Hi Eric,

Having entered the build-from-source world with the latest ubuntu, I applied your patch and tried it out with the example code I sent you using a call similar to

quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2)

This works very nicely for my purposes - perfectly in fact.
Many thanks for your work on this.
The only thing I think might be nice to add is some sort of minsize parameter so that you could get a pixel or something marking the existence of a data value for a grid point or a tiny arrowhead, sort of like the current svn quiver behaves, but size settable. I tried adding linewidths=(1,) to see if this would work. It sort of works, but looks pretty ugly and I think confirms my suspicion that the problems I had seen in my attempts were due to line stroking.

Thanks and good work!

Gary

Gary,

Thanks for the prompt test and report.

I agree that the ability to put a dot at locations where arrows are below a threshold would be good. I will add it. I think it should be similar to a circle marker that scales with the arrow width, and has a diameter that is a fraction of that width.

I also observed the stroking problem with small arrows and finite linewidth. I haven't checked into it, but I am wondering whether the problem is in the specification of the line join type.

Eric

Gary Ruben wrote:

ยทยทยท

Hi Eric,

Having entered the build-from-source world with the latest ubuntu, I applied your patch and tried it out with the example code I sent you using a call similar to

quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2)

This works very nicely for my purposes - perfectly in fact.
Many thanks for your work on this.
The only thing I think might be nice to add is some sort of minsize parameter so that you could get a pixel or something marking the existence of a data value for a grid point or a tiny arrowhead, sort of like the current svn quiver behaves, but size settable. I tried adding linewidths=(1,) to see if this would work. It sort of works, but looks pretty ugly and I think confirms my suspicion that the problems I had seen in my attempts were due to line stroking.

Thanks and good work!

Gary

Eric Firing wrote:

Gary,

Thanks for the prompt test and report.

I agree that the ability to put a dot at locations where arrows are below a threshold would be good. I will add it. I think it should be similar to a circle marker that scales with the arrow width, and has a diameter that is a fraction of that width.

That sounds like a good idea.

I also observed the stroking problem with small arrows and finite linewidth. I haven't checked into it, but I am wondering whether the problem is in the specification of the line join type.

I suspect you're right about the join type. When I was building arrows out of LineCollections I had my suspicions that this was the problem. I didn't look into what control Agg gives you over this - there may not be an appropriate join type which always looks good.

regards,
Gary