matplotlib-users Mailing List for matplotlib

jas...@cr... wrote:
> Eric Firing wrote:
>> Jason,
>>
>>> In looking at the basemap examples (specifically quiver_demo.py), it 
>>> looks like you specifically rotate the vectors to match up with map 
>>> coordinates; is that right? Applying to the situation above, do I need 
>> Yes.
>>> to rotate my vectors to respect the aspect ratio? What's the easiest 
>>> way to get quiver(X,Y,U,V) to behave so that the vectors plotted 
>>> would, for each coordinate (x,y) and corresponding (u,v), be parallel 
>>> to the vector between (x,y) and (x+u, y+v) (where (x, y) and (u,v) 
>>> are taken as coordinates in the axis coordinate system).
>> Well, the easiest way is to build mpl from svn; a few minutes ago I 
>> added this capability to quiver, selectable with an "angles" kwarg.
> 
> Thanks!
> 
> I'm working with matplotlib in Sage, so I'll probably update the
> matplotlib package in Sage if it is fairly stable. Do you know when the
> next release of matplotlib will be, in case it isn't stable for me?
No, as far as I know there is no release schedule. The last one, 
0.98.3, was not very long ago--early August--so I would not expect 
another until a couple more months have elapsed. But I could be wrong 
about that.
Eric

Eric Firing wrote:
> Jason,
>
>>
>> In looking at the basemap examples (specifically quiver_demo.py), it 
>> looks like you specifically rotate the vectors to match up with map 
>> coordinates; is that right? Applying to the situation above, do I need 
> Yes.
>> to rotate my vectors to respect the aspect ratio? What's the easiest 
>> way to get quiver(X,Y,U,V) to behave so that the vectors plotted 
>> would, for each coordinate (x,y) and corresponding (u,v), be parallel 
>> to the vector between (x,y) and (x+u, y+v) (where (x, y) and (u,v) 
>> are taken as coordinates in the axis coordinate system).
>
> Well, the easiest way is to build mpl from svn; a few minutes ago I 
> added this capability to quiver, selectable with an "angles" kwarg.
Thanks!
I'm working with matplotlib in Sage, so I'll probably update the
matplotlib package in Sage if it is fairly stable. Do you know when the
next release of matplotlib will be, in case it isn't stable for me?
P.S. Sorry for the duplicate messages to you, Eric. I keep hitting 
reply instead of reply-all.
Jason

Tanks, Michael. Maybe I'll try to build from SVN this weekend.
Goyo
El jue, 18-09-2008 a las 09:31 -0400, Michael Droettboom escribió:
> Proper NaN handling has been a long and winding road. 
> 
> This particuar bug you're running into was fixed about a week *after* 
> the 0.98.3 release. Here's the patch:
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=6018
> 
> So SVN trunk currently works. The patch against 0.98.3 is non-trivial 
> -- there were actually many changes throughout the code to make all this 
> work, so there isn't an easy workaround, and in any case requires a 
> recompile.
> 
> If you can build from SVN, that's what I would suggest -- otherwise wait 
> for the 0.98.4 release (I don't believe we have an ETA on that, yet).
> 
> Cheers,
> Mike
> 
> Goyo wrote:
> > I'm having trouble plotting data with NaN values. My plot has lines and
> > markers and usually both are skipped for NaN values. But when I have
> > more than 127 data a line is drawn from the last non-NaN to the next.
> >
> > I read somewhere about a similar issue (maybe here? sorry I can't find
> > it just now), it seems like it has to do with some optimization
> > performed for large datasets and the use if lineto instead of moveto or
> > something like that. It was supposed to be fixed in 0.98.2 but I'm using
> > 0.98.3 from Benjamin Drung's PPA (http://ppa.launchpad.net/bdrung).
> >
> > This code shows the difference between plotting 127 and 128 data (look
> > at the left of each figure):
> >
> > import pylab as pl
> > x = pl.random(128)
> > x[4:7] = pl.NaN
> > y = x[:-1]
> > pl.figure(1)
> > pl.plot(x, '-o')
> > pl.grid(True)
> > pl.figure(2)
> > pl.plot(y, '-o')
> > pl.grid(True)
> > pl.show()
> >
> > Is this a known issue? Is there any workaround?
> >
> > Thanks
> >
> > Goyo
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > 
> 

First off, in rereading my message, it sounded more abrasive than I
intended. I should have asked more questions and complained less; sorry.
Eric Firing wrote:
> jas...@cr... wrote:
>
>>
>> Is there an easy way to get a correct quiver plot (i.e., correct 
>> slopes) now if the aspect ratio is not 1?
>
> Please provide a script that illustrates what you think is the 
> problem. Exactly what is it that you want to do, and don't know how 
> to do with quiver as it is?
One application I'd like to use it for is direction field plots for
first order linear differential equations (i.e., y' = some function of x
and y). Given the function y'(x,y), I plot a quiver where U is a vector
of ones and V is a vector of y'(corresponding x and y coordinates), so
for the arrow based at point (x,y), the arrow has slope corresponding to
the slope of the solution that passes through (x,y).
However, when the aspect ratio is not one, a solution will have a
different slope (because the slope is measured in coordinates
corresponding to the axes) than the slope of the arrow.
Here is a small example, modified from the quiver examples in matplotlib.
from pylab import *
X,Y = meshgrid( arange(0,1,.2),arange(0,1,.2) )
def yprime(x,y):
 return 1
U,V = meshgrid([1]*len(X), [1]*len(Y))
figure()
Q = quiver(X,Y,U, V)
# This is a solution to the differential equation y'=1, but it doesn't
# look like it because the slopes do not respect the aspect ratio of
# the plot. What should happen is the arrows should point along the
# line.
plot([0,1],[0,1])
axis([0,1,0,0.5])
title("Slope Field for $dy/dx=1$")
show()
In looking at the basemap examples (specifically quiver_demo.py), it
looks like you specifically rotate the vectors to match up with map
coordinates; is that right? Applying to the situation above, do I need
to rotate my vectors to respect the aspect ratio? What's the easiest
way to get quiver(X,Y,U,V) to behave so that the vectors plotted would,
for each coordinate (x,y) and corresponding (u,v), be parallel to the
vector between (x,y) and (x+u, y+v) (where (x, y) and (u,v) are taken as
coordinates in the axis coordinate system).
Please let me know if I'm not clear in what I'm asking.
Thanks,
Jason
>
> Note that you have full control over U and V; you can make the arrows 
> point any direction you want, and be any length you want. And you can 
> locate them anywhere you want.
>
> Basemap illustrates how quiver can be used with curvilinear 
> coordinates; the U and V are adjusted to align the arrows with the 
> coordinates.
>
> It is possible that quiver needs more modification to work properly 
> and flexibly with the new transforms implementation; in fact I know of 
> a bug that this introduced, and I will commit a correction shortly. 
> I have not looked into quiver behavior with transforms-based 
> projections. They might indeed call for a design change.
>
> Eric
>
>

Jeff,
No the example doesn't show that line
If I reduce the amount of data, the border will be on every side of the plot
I'll show you an orthographic plot with no maskinf tomorrow and you will see the problem easily, it wraps in a white line along the 0° meridian and a white circle in the pole
I think it's the imshow layer that is not totally transparent on the map background.. I tried every trick I could for example to put some zero-valued points on each corner to make imshow interpolate correctly the sides, but that doesn't make any difference
>De Pauw Antoine wrote:
>> Jeff,
>>
>> Yes they disappear, and they fluctuate with the interpolation method used
>>
>> For example, nearest interpolation don't show the line
>>
>> Also, if I reduce the grid resolution, the line is thicker, and if I use a
>> masked array to get rid of undesired values, the border shows really
>> strongly
>>
>> Here's an example everyone will see:
>>
>> http://img225.imageshack.us/img225/2671/testfigep2.png
>>
>> (everything except the clouds is noise)
>>
>> Antoine De Pauw
>> Collaborateur de recherches, Informatique - Research collaborator, IT
>> Laboratoire de chimie quantique et photophysique - Quantum chemistry and
>> photophysics laboratory
>> Université Libre de Bruxelles - ULB
>> 
>
>Antoine: Sorry to seem dense, but I don't see anything wrong with that 
>plot. I see a white border along the north and south pole, but I 
>intrepret that to be missing values. However, my eyes are notoriously 
>bad. I'd like to be to run a script that generates the artifacts 
>myself, so I can zoom in and see the problem myself. Does the 
>griddata_demo.py script show the same problem for you?
>
>-Jeff
>>
>> -----Original Message-----
>> From: Jeff Whitaker [mailto:js...@fa...] 
>> Sent: mercredi 17 septembre 2008 19:05
>> To: John Hunter
>> Cc: De Pauw Antoine; Matplotlib Users
>> Subject: Re: [Matplotlib-users] Information request
>>
>> John Hunter wrote:
>> 
>>> On Wed, Sep 17, 2008 at 11:54 AM, John Hunter <jd...@gm...> wrote:
>>>
>>> 
>>> 
>>>> Attached is a screenshot (zoom.png) from the gimp, zoomed in near the
>>>> axes border. The black horizontal line is the top axes border, the
>>>> horizontal grey line is the artifact, the vertical dashed line is a
>>>> grid line. I don't know if this offers a clue, but if you look at a
>>>> zoom in the upper right corner, the grey line seems to break up and
>>>> curve down and to the right (corner.png)
>>>> 
>>>> 
>>> Sorry, screwed up corner.png (I attached the original and not the
>>> screenshot). The correct screenshot is attached
>>> 
>>>
>>>
>>> 
>>
>> John: OK, now I finally see it. Antoine: Do these artifacts 
>> disappear if you comment out the imshow call?
>>
>> -Jeff
>>
>> 
>
>
>-- 
>Jeffrey S. Whitaker Phone : (303)497-6313
>Meteorologist FAX : (303)497-6449
>NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
>325 Broadway Office : Skaggs Research Cntr 1D-113
>Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
>
>
>

De Pauw Antoine wrote:
> Jeff,
>
> Yes they disappear, and they fluctuate with the interpolation method used
>
> For example, nearest interpolation don't show the line
>
> Also, if I reduce the grid resolution, the line is thicker, and if I use a
> masked array to get rid of undesired values, the border shows really
> strongly
>
> Here's an example everyone will see:
>
> http://img225.imageshack.us/img225/2671/testfigep2.png
>
> (everything except the clouds is noise)
>
> Antoine De Pauw
> Collaborateur de recherches, Informatique - Research collaborator, IT
> Laboratoire de chimie quantique et photophysique - Quantum chemistry and
> photophysics laboratory
> Université Libre de Bruxelles - ULB
> 
Antoine: Sorry to seem dense, but I don't see anything wrong with that 
plot. I see a white border along the north and south pole, but I 
intrepret that to be missing values. However, my eyes are notoriously 
bad. I'd like to be to run a script that generates the artifacts 
myself, so I can zoom in and see the problem myself. Does the 
griddata_demo.py script show the same problem for you?
-Jeff
>
> -----Original Message-----
> From: Jeff Whitaker [mailto:js...@fa...] 
> Sent: mercredi 17 septembre 2008 19:05
> To: John Hunter
> Cc: De Pauw Antoine; Matplotlib Users
> Subject: Re: [Matplotlib-users] Information request
>
> John Hunter wrote:
> 
>> On Wed, Sep 17, 2008 at 11:54 AM, John Hunter <jd...@gm...> wrote:
>>
>> 
>> 
>>> Attached is a screenshot (zoom.png) from the gimp, zoomed in near the
>>> axes border. The black horizontal line is the top axes border, the
>>> horizontal grey line is the artifact, the vertical dashed line is a
>>> grid line. I don't know if this offers a clue, but if you look at a
>>> zoom in the upper right corner, the grey line seems to break up and
>>> curve down and to the right (corner.png)
>>> 
>>> 
>> Sorry, screwed up corner.png (I attached the original and not the
>> screenshot). The correct screenshot is attached
>> 
>>
>>
>> 
>
> John: OK, now I finally see it. Antoine: Do these artifacts 
> disappear if you comment out the imshow call?
>
> -Jeff
>
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Proper NaN handling has been a long and winding road. 
This particuar bug you're running into was fixed about a week *after* 
the 0.98.3 release. Here's the patch:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=rev&revision=6018
So SVN trunk currently works. The patch against 0.98.3 is non-trivial 
-- there were actually many changes throughout the code to make all this 
work, so there isn't an easy workaround, and in any case requires a 
recompile.
If you can build from SVN, that's what I would suggest -- otherwise wait 
for the 0.98.4 release (I don't believe we have an ETA on that, yet).
Cheers,
Mike
Goyo wrote:
> I'm having trouble plotting data with NaN values. My plot has lines and
> markers and usually both are skipped for NaN values. But when I have
> more than 127 data a line is drawn from the last non-NaN to the next.
>
> I read somewhere about a similar issue (maybe here? sorry I can't find
> it just now), it seems like it has to do with some optimization
> performed for large datasets and the use if lineto instead of moveto or
> something like that. It was supposed to be fixed in 0.98.2 but I'm using
> 0.98.3 from Benjamin Drung's PPA (http://ppa.launchpad.net/bdrung).
>
> This code shows the difference between plotting 127 and 128 data (look
> at the left of each figure):
>
> import pylab as pl
> x = pl.random(128)
> x[4:7] = pl.NaN
> y = x[:-1]
> pl.figure(1)
> pl.plot(x, '-o')
> pl.grid(True)
> pl.figure(2)
> pl.plot(y, '-o')
> pl.grid(True)
> pl.show()
>
> Is this a known issue? Is there any workaround?
>
> Thanks
>
> Goyo
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I worked around this using masked arrays from numpy.ma.
import numpy.ma as ma
import pylab as pl
import numpy as np
x = ...
x = ma.masked_where(np.isnan(x), x)
pl.plot(x)
pl.show()
On Wed, Sep 17, 2008 at 6:36 PM, Goyo <goy...@gm...> wrote:
> I'm having trouble plotting data with NaN values. My plot has lines and
> markers and usually both are skipped for NaN values. But when I have
> more than 127 data a line is drawn from the last non-NaN to the next.
>
> I read somewhere about a similar issue (maybe here? sorry I can't find
> it just now), it seems like it has to do with some optimization
> performed for large datasets and the use if lineto instead of moveto or
> something like that. It was supposed to be fixed in 0.98.2 but I'm using
> 0.98.3 from Benjamin Drung's PPA (http://ppa.launchpad.net/bdrung).
>
> This code shows the difference between plotting 127 and 128 data (look
> at the left of each figure):
>
> import pylab as pl
> x = pl.random(128)
> x[4:7] = pl.NaN
> y = x[:-1]
> pl.figure(1)
> pl.plot(x, '-o')
> pl.grid(True)
> pl.figure(2)
> pl.plot(y, '-o')
> pl.grid(True)
> pl.show()
>
> Is this a known issue? Is there any workaround?
>
> Thanks
>
> Goyo
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Can you show us what you've tried thus far? This is a rather open-ended 
question...
Cheers,
Mike
Ryan Pavlovicz wrote:
> Hi. I'd like to add a filled area on my graph to denote the standard 
> deviation from an average. Additionally, i'd prefer the fill to be a 
> diagonal hatch. Reading online, i found that there is a 'Rectangle' 
> class, but i can't get this to work. Can someone suggest a good way 
> to get the results i'm looking for? Thanks!
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

It seems you're getting bitten by the brain-dead interpolation of points 
(which is meant to draw line segments as curves that follow the radii). 
I have fixed the polar drawing code in SVN r6106 to normalize theta to 
(0.0 <= theta <= 2pi) before doing the interpolation, which seems to fix 
your example. The user doesn't/shouldn't have to care about whether 
theta is negative.
Cheers,
Mike
jan gillis wrote:
> Hi Tony,
>
> Thank you for the reply, the solutions you propose are fine in this 
> case. But I'm trying to use the polar plot
> as a smith chart for an instrument and there i will receive data that is 
> unknown but can be something like this:
>
> r = np.transpose(.1+np.arange ( 0 , 0.7 , 0.001))
> theta = -4.5 * np.pi *r
> freq = r*10e9
> data = np.multiply(r,np.exp(1j*theta))
> ax.plot(angle(data),abs(data))
>
> Any idea why Polar plot can't handle theta going from negative to 
> positive radians?
>
> Jan
>
> Tony S Yu wrote:
> 
>> On Sep 17, 2008, at 1:59 AM, jan gillis wrote:
>>
>> 
>>> Hello,
>>>
>>> I have a problem with polar plot, if i run the following code in
>>> matplotlib 0.98.3, polar plot is drawing a extra circle to go from
>>> angle -3.14159265 to angle 3.03753126. Is there a solution for this
>>> problem?
>>>
>>> ********************
>>> import numpy as np
>>> from matplotlib.pyplot import figure, show, rc, grid
>>>
>>> # radar green, solid grid lines
>>> rc('grid', color='#316931', linewidth=1, linestyle='-')
>>> rc('xtick', labelsize=15)
>>> rc('ytick', labelsize=15)
>>>
>>> # force square figure and square axes looks better for polar, IMO
>>> fig = figure(figsize=(8,8))
>>> ax = fig.add_axes([0.1, 0.1, 0.8, 0.8], polar=True, axisbg='#d5de9c')
>>>
>>> z = np.zeros((1,2000),complex)
>>> z.real = 0.2
>>> z.imag = np.arange(-50,50,0.05)
>>> gamma_r = np.transpose((z-1)/(z+1))
>>>
>>> ax.plot(np.angle(gamma_r), np.abs(gamma_r), '.-', zorder=0)
>>> 
>> Hi Jan,
>>
>> It looks like you get the circle because the angles you're plotting go 
>> from negative to positive radians in a weird way. The circle being 
>> drawn starts around 0 radians and goes clockwise by negative values. 
>> Then when it gets to - pi, it switches to positive indices, i.e. pi. 
>> Of course, these are the same points on a polar plot, but different 
>> angles, if you want to be consistent.
>>
>> Here are a couple of quick solutions, but there but there maybe better 
>> ways of handling this.
>>
>> # ~~~~~~~~~~~~~~~~~~
>> # get rid of the plot line above, and add the following
>> theta = np.angle(gamma_r)
>> mag = np.abs(gamma_r)
>>
>> # option 1
>> ordered = np.argsort(theta, axis=0).squeeze()
>> ax.plot(theta[ordered], mag[ordered], '.-', zorder=0)
>>
>> # option 2
>> neg_theta = np.where(theta < 0)
>> theta[neg_theta] += 2 * np.pi
>> ax.plot(theta, mag, '.-', zorder=0)
>> # ~~~~~~~~~~~~~~~~~~
>>
>> I hope that's helpful,
>> -Tony
>>
>> 
>>> ax.set_rmax(2.0)
>>> grid(True)
>>>
>>> show()
>>>
>>> ********************
>>> Kind regards,
>>> Jean
>>>
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the 
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>> 
>> 
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Sep 15, 2008 at 1:51 PM, Mathieu Dubois <mat...@li...> wrote:
> Hi,
>
> I'm a (still) beginner in scipy and I have a small problem with figures.
> Let me
> explain.
>
> I have to plot a lot of huge data so I have a lot of figures. I have set
> title and axes names. All the handles are in a list (the list can vary
> at run time according to the user input).
>
> My goal is to save the figures (with savefig()). For this I want to
> write a loop which look like this:
> for fig in fig_list
> figure(fig) # Select current figure
> savefig('%s.png' % fig.title, format='png') # Save it as 'title'.png
>
> The problem is well explained in a previous message:
> http://sourceforge.net/mailarchive/message.php?msg_id=a7f1ef730709101012o20abd37aj116e100d9b105d52%40mail.gmail.com
> but nobody has answered to this post.
>
The matplotlib figure is contained in a FigureCanvas which is
contained in a FigureManager, and the manager has a method to set the
window title:
 fig.canvas.manager.set_window_title('some title')
unfortunately, there is no method provided to *get* the window title
for reuse later by savefig (we need to add it). You can, however, use
the figure label (all matplotlib artists from lines, to text, to the
axes to the figure have a label property. So something like this
should work
 import matplotlib.pyplot as plt
 fig = plt.figure()
 title = 'some title'
 fig.set_label(title)
 fig.canvas.manager.set_window_title(title)
and later:
 fig.savefig(fig.get_label())
Hope this helps,
JDH

Hi everyone,
Sorry for the delayed response.
Thank you very much everyone for the help.
Maybe it would be a good idea to add a 'window_title' keyword to 
figure() (à la matlab ;).
kind regards,
Mathieu
Jae-Joon Lee wrote:
>> Kind of awkward, but
>>
>> fig.canvas.manager.window.wm_title()
>>
>> 
>
> I guess this is backend dependent. In my Gtk backend, I don't have
> such a method. But I found fig.canvas.manager.window.get_title().
> Thanks!
>
> -JJ
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

Jeff,
Yes they disappear, and they fluctuate with the interpolation method used
For example, nearest interpolation don't show the line
Also, if I reduce the grid resolution, the line is thicker, and if I use a
masked array to get rid of undesired values, the border shows really
strongly
Here's an example everyone will see:
http://img225.imageshack.us/img225/2671/testfigep2.png
(everything except the clouds is noise)
Antoine De Pauw
Collaborateur de recherches, Informatique - Research collaborator, IT
Laboratoire de chimie quantique et photophysique - Quantum chemistry and
photophysics laboratory
Université Libre de Bruxelles - ULB
-----Original Message-----
From: Jeff Whitaker [mailto:js...@fa...] 
Sent: mercredi 17 septembre 2008 19:05
To: John Hunter
Cc: De Pauw Antoine; Matplotlib Users
Subject: Re: [Matplotlib-users] Information request
John Hunter wrote:
> On Wed, Sep 17, 2008 at 11:54 AM, John Hunter <jd...@gm...> wrote:
>
> 
>> Attached is a screenshot (zoom.png) from the gimp, zoomed in near the
>> axes border. The black horizontal line is the top axes border, the
>> horizontal grey line is the artifact, the vertical dashed line is a
>> grid line. I don't know if this offers a clue, but if you look at a
>> zoom in the upper right corner, the grey line seems to break up and
>> curve down and to the right (corner.png)
>> 
>
> Sorry, screwed up corner.png (I attached the original and not the
> screenshot). The correct screenshot is attached
> 
>
>
John: OK, now I finally see it. Antoine: Do these artifacts 
disappear if you comment out the imshow call?
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

jas...@cr... wrote:
> Recently I noticed that the quiver plots all make the arrows as if the 
> plot had aspect ratio 1. See, for example, the documentation for quiver:
> 
> In all cases the arrow aspect ratio is 1, so that if *U*==*V* the
> angle of the arrow on the plot is 45 degrees CCW from the *x*-axis.
> 
> 
> This seems to make the plot pretty useless if the aspect ratio is not 1, 
> since then the slopes of the arrows do not match up with the coordinate 
> axes. What is the reason for this design decision? Does it have to do 
> with the arrows distorting if the aspect ratio is not 1? At one time, 
No, the design suits my applications: I want to plot arrows indicating 
ocean current vectors as a function of position in the horizontal, or as 
a function of depth and time. But I don't think the design is limiting. 
 See below.
> there was talk of adding a line version of quiver (as opposed to the 
> patch version there now). See 
> http://article.gmane.org/gmane.comp.python.matplotlib.devel/1885. Has 
> that happened? I suppose a line version would allow different aspect 
> ratios.
No, in this respect it would be no different. And no, a line version 
has not been added.
> 
> Is there an easy way to get a correct quiver plot (i.e., correct slopes) 
> now if the aspect ratio is not 1?
Please provide a script that illustrates what you think is the problem. 
 Exactly what is it that you want to do, and don't know how to do 
with quiver as it is?
Note that you have full control over U and V; you can make the arrows 
point any direction you want, and be any length you want. And you can 
locate them anywhere you want.
Basemap illustrates how quiver can be used with curvilinear coordinates; 
the U and V are adjusted to align the arrows with the coordinates.
It is possible that quiver needs more modification to work properly and 
flexibly with the new transforms implementation; in fact I know of a bug 
 that this introduced, and I will commit a correction shortly. I have 
not looked into quiver behavior with transforms-based projections. They 
might indeed call for a design change.
Eric