matplotlib-users Mailing List for matplotlib

Solved. Sort of. If I run using python it works. It fails if I run using
ipython with --pylab.
On Mon, Mar 29, 2010 at 3:46 PM, Mathew Yeates <mat...@gm...> wrote:
> I don't understand why the following fails.
>
> fig = Figure(figsize=(5,5), dpi=100)
> canvas = FigureCanvas(fig)
> ax = fig.add_subplot(111)
> m = Basemap(resolution='c',projection='cyl',lon_0=0,ax=ax)
> m.drawcoastlines(color='gray',ax=ax)
>
> fails with
> mpl_toolkits\basemap\__init__.pyc in set_axes_limits ....
> 2531 if is_interactive():
> 2532 figManager = _pylab_helpers.Gcf.get_active()
> -> 2533 figManager.canvas.draw()
>
> AttributeError: 'NoneType' object has no attribute 'canvas'
>
> Why isn't my figure being set as active??
>
> Mathew
>
>
>
>
>
>
>
>
> On Mon, Mar 29, 2010 at 11:12 AM, Yeates, Mathew C (388D) <
> mat...@jp...> wrote:
>
>> Hi
>>
>> Anyone have an example? I found some older examples which no longer work.
>>
>>
>>
>> TIA
>>
>>
>>
>> Mathew
>>
>>
>>
>> For grins .... The following does not work. I’ve tried many different
>> variations ...
>>
>>
>>
>> import matplotlib.pyplot as plt
>>
>>
>>
>> import gtk
>>
>> from mpl_toolkits.basemap import Basemap
>>
>> import matplotlib
>>
>> from matplotlib.figure import Figure
>>
>> fig=plt.Figure()
>>
>> ax=fig.add_subplot(111)
>>
>> m = Basemap(llcrnrlon=1, \
>>
>> llcrnrlat=40.6, \
>>
>> urcrnrlon=8.8, \
>>
>> urcrnrlat = 49.6, \
>>
>> projection = 'tmerc', \
>>
>> lon_0 = 4.9, \
>>
>> lat_0 = 45.1,ax=ax)
>>
>>
>>
>> from matplotlib.backends.backend_gtkagg import \
>>
>> FigureCanvasGTKAgg as FigureCanvas
>>
>> canvas = FigureCanvas(fig)
>>
>> m.drawcoastlines(color='gray')
>>
>> m.drawcountries(color='gray')
>>
>> m.fillcontinents(color='beige')
>>
>> builder = gtk.Builder()
>>
>> builder.add_from_file("fluxtool.glade")
>>
>> window1=builder.get_object("window1")
>>
>> window1.connect("destroy", lambda x: gtk.main_quit())
>>
>>
>>
>>
>>
>> vbox=builder.get_object("vbox1")
>>
>> vbox.pack_start(canvas)
>>
>> window1.show()
>>
>> gtk.main()
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>

I don't understand why the following fails.
fig = Figure(figsize=(5,5), dpi=100)
canvas = FigureCanvas(fig)
ax = fig.add_subplot(111)
m = Basemap(resolution='c',projection='cyl',lon_0=0,ax=ax)
m.drawcoastlines(color='gray',ax=ax)
fails with
mpl_toolkits\basemap\__init__.pyc in set_axes_limits ....
 2531 if is_interactive():
 2532 figManager = _pylab_helpers.Gcf.get_active()
-> 2533 figManager.canvas.draw()
AttributeError: 'NoneType' object has no attribute 'canvas'
Why isn't my figure being set as active??
Mathew
On Mon, Mar 29, 2010 at 11:12 AM, Yeates, Mathew C (388D) <
mat...@jp...> wrote:
> Hi
>
> Anyone have an example? I found some older examples which no longer work.
>
>
>
> TIA
>
>
>
> Mathew
>
>
>
> For grins .... The following does not work. I’ve tried many different
> variations ...
>
>
>
> import matplotlib.pyplot as plt
>
>
>
> import gtk
>
> from mpl_toolkits.basemap import Basemap
>
> import matplotlib
>
> from matplotlib.figure import Figure
>
> fig=plt.Figure()
>
> ax=fig.add_subplot(111)
>
> m = Basemap(llcrnrlon=1, \
>
> llcrnrlat=40.6, \
>
> urcrnrlon=8.8, \
>
> urcrnrlat = 49.6, \
>
> projection = 'tmerc', \
>
> lon_0 = 4.9, \
>
> lat_0 = 45.1,ax=ax)
>
>
>
> from matplotlib.backends.backend_gtkagg import \
>
> FigureCanvasGTKAgg as FigureCanvas
>
> canvas = FigureCanvas(fig)
>
> m.drawcoastlines(color='gray')
>
> m.drawcountries(color='gray')
>
> m.fillcontinents(color='beige')
>
> builder = gtk.Builder()
>
> builder.add_from_file("fluxtool.glade")
>
> window1=builder.get_object("window1")
>
> window1.connect("destroy", lambda x: gtk.main_quit())
>
>
>
>
>
> vbox=builder.get_object("vbox1")
>
> vbox.pack_start(canvas)
>
> window1.show()
>
> gtk.main()
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Sami-Matias Niemi wrote:
> Hi,
> 
> When using scatter plotting method and linestyles argument the output 
> seems to ignore the linestyles keyword value at least in SVN. Can 
> someone confirm this or did I misunderstood the functionality?
Yes, scatter is designed to plot markers only, and it does ignore the 
linestyles kw.
> 
> I am trying to make a plot where the colour of the line changes as a 
> function of data value, but I don't want that each point (marker) is 
> plotted separately, but that the colour changes smoothly. I believe 
> scatter method could be used when optional arguments "c = values" and 
> linestyles = 'solid' are used. However, independent what the 
> linestyles argument value is, I always get the markers plotted and no 
> line appears.
We don't have anything that gives this behavior directly, but it can be 
simulated with a LineCollection. See 
http://www.scipy.org/Cookbook/Matplotlib/MulticoloredLine.
Eric
> 
> 
> Cheers,
> Sami
> 
> 
> Example code (markers, but no solid line!?):
> 
> import numpy as np
> import pylab as p
> 
> data = np.arange(10)
> 
> p.scatter(data, data, c = data, s = data*10, linestyles = 'solid')
> 
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi
Anyone have an example? I found some older examples which no longer work.
TIA
Mathew
For grins .... The following does not work. I've tried many different variations ...
import matplotlib.pyplot as plt
import gtk
from mpl_toolkits.basemap import Basemap
import matplotlib
from matplotlib.figure import Figure
fig=plt.Figure()
ax=fig.add_subplot(111)
m = Basemap(llcrnrlon=1, \
 llcrnrlat=40.6, \
 urcrnrlon=8.8, \
 urcrnrlat = 49.6, \
 projection = 'tmerc', \
 lon_0 = 4.9, \
 lat_0 = 45.1,ax=ax)
from matplotlib.backends.backend_gtkagg import \
 FigureCanvasGTKAgg as FigureCanvas
canvas = FigureCanvas(fig)
m.drawcoastlines(color='gray')
m.drawcountries(color='gray')
m.fillcontinents(color='beige')
builder = gtk.Builder()
builder.add_from_file("fluxtool.glade")
window1=builder.get_object("window1")
window1.connect("destroy", lambda x: gtk.main_quit())
vbox=builder.get_object("vbox1")
vbox.pack_start(canvas)
window1.show()
gtk.main()

Hi,
When using scatter plotting method and linestyles argument the output 
seems to ignore the linestyles keyword value at least in SVN. Can 
someone confirm this or did I misunderstood the functionality?
I am trying to make a plot where the colour of the line changes as a 
function of data value, but I don't want that each point (marker) is 
plotted separately, but that the colour changes smoothly. I believe 
scatter method could be used when optional arguments "c = values" and 
linestyles = 'solid' are used. However, independent what the 
linestyles argument value is, I always get the markers plotted and no 
line appears.
Cheers,
Sami
Example code (markers, but no solid line!?):
import numpy as np
import pylab as p
data = np.arange(10)
p.scatter(data, data, c = data, s = data*10, linestyles = 'solid')

Hi Jae-Joon,
Thanks for your quick reply! Since for example LineCollections can be created independent of the Axes in which they are going to be plotted through the creation of a LineCollection instance, would it not be possible to have a method that allows one to retrieve an Axes-independent LineCollection from an Axes instance? (for example a get_collection method) This would then allow one to 'recycle' existing collections.
Cheers,
Thomas
On Mar 29, 2010, at 1:40 PM, Jae-Joon Lee wrote:
> As far as I can say, moving around artists from one axes to the other
> is NOT recommended. And I encourage you to create separate artists for
> each axes rather than try to reuse the existing ones.
> 
> For your particular example,
> 
> fig = mpl.figure()
> ax2 = fig.add_subplot(1,1,1)
> for c in ax1.collections:
> c._transOffset=ax2.transData
> ax2.add_collection(c)
> 
> should work.
> 
> Regards,
> 
> -JJ
> 
> 
> 
> 
> On Mon, Mar 29, 2010 at 12:24 PM, Thomas Robitaille
> <tho...@gm...> wrote:
>> Hello,
>> 
>> In the following example, I am trying to copy over existing collections from one plot to another:
>> 
>> import matplotlib.pyplot as mpl
>> 
>> fig = mpl.figure()
>> ax1 = fig.add_subplot(1,1,1)
>> ax1.scatter([0.5],[0.5])
>> fig.savefig('test1.png')
>> 
>> fig = mpl.figure()
>> ax2 = fig.add_subplot(1,1,1)
>> for c in ax1.collections:
>> ax2.add_collection(c)
>> fig.savefig('test2.png')
>> 
>> However, the circle appears in the wrong place in test2.png (close to 0.4, 0.4 instead of 0.5,0.5). Is it not possible/safe to copy over collections in this way? If not, then how should this be done?
>> 
>> Thanks,
>> 
>> Thomas
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 

Dear All,
 I want to make minor ticks working in following program.
Here only major ticks are dis[played in grpah though i have declared the
minor ticks
minorticks_on() doesnt work in my code. How to fix that.Please help me
out.Thanks in advance !!!!!!!!!!!!'
Regards
Yogesh
from numpy import *
from scipy import *
from scipy import signal, misc
import sys,time,os,gc
import matplotlib
import matplotlib.pyplot as plt
from numpy.random import *
from pylab import plot, show, ylim, yticks,xlim
from pylab import *
x=loadtxt('/home/jaguar/Desktop/45.txt')
x=x[0:1399]
y=arange(len(x))
plt.figure(2)
plt.plot(y,x,'k-')
#minorticks_on()
grid(True)#, color="r", ls="-")
gca().xaxis.grid(True, which="minor", color="r")
#gca().yaxis.grid(True, which='minor')
#grid(True, which="minor", color="r")
show()#l

As far as I can say, moving around artists from one axes to the other
is NOT recommended. And I encourage you to create separate artists for
each axes rather than try to reuse the existing ones.
For your particular example,
fig = mpl.figure()
ax2 = fig.add_subplot(1,1,1)
for c in ax1.collections:
 c._transOffset=ax2.transData
 ax2.add_collection(c)
should work.
Regards,
-JJ
On Mon, Mar 29, 2010 at 12:24 PM, Thomas Robitaille
<tho...@gm...> wrote:
> Hello,
>
> In the following example, I am trying to copy over existing collections from one plot to another:
>
> import matplotlib.pyplot as mpl
>
> fig = mpl.figure()
> ax1 = fig.add_subplot(1,1,1)
> ax1.scatter([0.5],[0.5])
> fig.savefig('test1.png')
>
> fig = mpl.figure()
> ax2 = fig.add_subplot(1,1,1)
> for c in ax1.collections:
>  ax2.add_collection(c)
> fig.savefig('test2.png')
>
> However, the circle appears in the wrong place in test2.png (close to 0.4, 0.4 instead of 0.5,0.5). Is it not possible/safe to copy over collections in this way? If not, then how should this be done?
>
> Thanks,
>
> Thomas
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hello,
In the following example, I am trying to copy over existing collections from one plot to another:
import matplotlib.pyplot as mpl
fig = mpl.figure()
ax1 = fig.add_subplot(1,1,1)
ax1.scatter([0.5],[0.5])
fig.savefig('test1.png')
fig = mpl.figure()
ax2 = fig.add_subplot(1,1,1)
for c in ax1.collections:
 ax2.add_collection(c)
fig.savefig('test2.png')
However, the circle appears in the wrong place in test2.png (close to 0.4, 0.4 instead of 0.5,0.5). Is it not possible/safe to copy over collections in this way? If not, then how should this be done?
Thanks,
Thomas

Hi Matthias,
Thanks for the help. The problem is, however, that the 'extent' parameter
only manipulates the range of the (integer) values on the axis. Before
setting the *axis_date property, I need to set the axes data to arrays of
(non-equidistant) floats.
Best Regards,
Micha
Matthias Michler wrote:
> 
> 
> Did you already set the date-xaxis by hand?
> -> for axes 'ax' using e.g.
> ax.xaxis_date(tz=None)
> ax.yaxis_date(tz=None)
> 
> 
-- 
View this message in context: http://old.nabble.com/matshow---imshow-with-date-axis-tp28068228p28070890.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Friedrich Romstedt wrote:
> 2010年3月29日 Eric Firing <ef...@ha...>:
>> It already has this. You can pass in a custom locator or set of tick
>> locations via the "ticks" kwarg, but if you don't, a locator is chosen
>> automatically. Except in special cases, this will be a MaxNLocator. See the
>> ColorbarBase._ticker method.
> 
> Ah, thanks, It escaped my notice that there is a toplevel "if
> self.locator is None:" statement ... ok.
> 
>> Ah, maybe what you mean is a text option to the "ticks" kwarg that would
>> specify MaxNLocator without requiring one to instantiate a MaxNLocator? I
>> don't think this makes sense for the case when boundaries are specified
>> explicitly.
> 
> No, what I intended is exactly what you pointed out.
> 
> Btw, can you tell me what the *values* kwarg's semantic is? I guess,
> it shall be the center values of the values displayed, but then the
> implementation for this in ColorbarBase._process_values() would be
> broken.
The ColorbarBase simply makes a strip of colored blocks, with their 
sizes and locations determined by the boundaries kwarg (together with 
the "spacing" kwarg) and their colors determined from the values kwarg 
via color mapping. If either or both of these kwargs is None, the 
boundaries and/or values will be generated in _process_values. The use 
of the non-default values kwarg is illustrated by the special-case 
handling of colorbars for contouring in the Colorbar class.
Can you give a test case showing a problem with _process_values?
> 
> Friedrich
> 
> P.S.: I assume you have be caught by the "misconfiguration" of the
> list that the sender is used as the default recipient, so I post back
> to the list?
The mpl lists have been unusual (at least compared to lists for numpy, 
scipy, and cython) in this respect for years. Usually I remember to 
reply to all, but you are right--this time I goofed.
Eric

2010年3月29日 Friedrich Romstedt <fri...@gm...>:
> Note that the ticking is a bit weird, there is also a bug in
> matplotlib I will report on right after this e-mail, whose bugfix you
> will maybe want to apply to get ticking properly working. When you
> have insane values for C.min() and C.max() anyway, I'm afraid you have
> to retick manually with *ticks* to colorbar(). The ticker.MaxNLocator
> is only used when not using the *boundaries* arg to colorbar(),
> unfortunately. Otherwise it tries to create maximal many and less
> than 11 ticks by using the lowest value and an appropriate step in
> *boundaries*. I think the implementation of ticking is cumbersome and
> never optimal.
You can get rid of this night mare by giving the kwarg "ticks =
matplotlib.ticker.MaxNLocator()" to fig.colorbar(). Then the
*boundaries* aren't used for ticking (but still for plotting).
Friedrich

Hello,
It looks like the zlib website removes previous version of its library that were previously available for download, so the part in make.osx where http://www.zlib.net/zlib-1.2.3.tar.gz is fetched now fails (since the current version is 1.2.4). The error in the matplotlib building is not explicit enough (incorrect archive type) - maybe one could catch such 404s and print out an error suggesting to increase the ZLIBVERSION variable?
I tried changing ZLIBVERSION to 1.2.4 and the following occurs when building zlib:
...
gcc -arch i386 -arch x86_64 -I/Users/tom/install/include -I/Users/tom/install/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -c -o inftrees.o inftrees.c
gcc -arch i386 -arch x86_64 -I/Users/tom/install/include -I/Users/tom/install/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -c -o trees.o trees.c
gcc -arch i386 -arch x86_64 -I/Users/tom/install/include -I/Users/tom/install/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -c -o uncompr.o uncompr.c
gcc -arch i386 -arch x86_64 -I/Users/tom/install/include -I/Users/tom/install/include/freetype2 -isysroot /Developer/SDKs/MacOSX10.6.sdk -c -o zutil.o zutil.c
make[1]: *** No rule to make target `libz.dylib', needed by `install-libs'. Stop.
make[1]: *** Waiting for unfinished jobs....
make: *** [zlib] Error 2
If I manually go to the zlib directory and type make, it builds without a problem, so it looks like there is some kind of problem in the make.osx script.
Thanks in advance for any help,
Thomas

2010年3月29日 Eric Firing <ef...@ha...>:
> It already has this. You can pass in a custom locator or set of tick
> locations via the "ticks" kwarg, but if you don't, a locator is chosen
> automatically. Except in special cases, this will be a MaxNLocator. See the
> ColorbarBase._ticker method.
Ah, thanks, It escaped my notice that there is a toplevel "if
self.locator is None:" statement ... ok.
> Ah, maybe what you mean is a text option to the "ticks" kwarg that would
> specify MaxNLocator without requiring one to instantiate a MaxNLocator? I
> don't think this makes sense for the case when boundaries are specified
> explicitly.
No, what I intended is exactly what you pointed out.
Btw, can you tell me what the *values* kwarg's semantic is? I guess,
it shall be the center values of the values displayed, but then the
implementation for this in ColorbarBase._process_values() would be
broken.
Friedrich
P.S.: I assume you have be caught by the "misconfiguration" of the
list that the sender is used as the default recipient, so I post back
to the list?

I once had a similar issue. I solved it like this. It takes the minimum and
maximum of the data and returns a colormap: Zero: White, Positive values:
blue, Negative values: red.
def mxcmap(_min,_max):
 if _min >= 0 and _max >= 0:
 cdict = {'red': ((0.0, 1.0, 1.0),
 (1.0, 0.0, 0.0)),
 'green': ((0.0, 1.0, 1.0),
 (1.0, 0.0, 0.0)),
 'blue': ((0.0, 1.0, 1.0),
 (1.0, 1.0, 1.0))}
 elif _min <= 0 and _max <= 0:
 cdict = {'red': ((0.0, 1.0, 1.0),
 (1.0, 1.0, 1.0)),
 'green': ((0.0, 0.0, 0.0),
 (1.0, 1.0, 1.0)),
 'blue': ((0.0, 0.0, 0.0),
 (1.0, 1.0, 1.0))}
 else:
 full_red = 1
 full_blue = 1
 if -_min > _max:
 full_blue = -float(_max)/_min
 else:
 full_red = -float(_min)/_max
 zero = 0.5-((_max+_min)/2.)/(_max-_min)
 cdict = {'red': ((0.0, 1.0, 1.0),
 (zero, 1.0, 1.0),
 (1.0, 1-full_blue, 1-full_blue)),
 'green': ((0.0, 1-full_red, 1-full_red),
 (zero, 1.0, 1.0),
 (1.0, 1-full_blue, 1-full_blue)),
 'blue': ((0.0, 1-full_red, 1-full_red),
 (zero,1.0, 1.0),
 (1.0, 1.0, 1.0))}
 return
pylab.matplotlib.colors.LinearSegmentedColormap('my_colormap',cdict,256)
-- 
View this message in context: http://old.nabble.com/Making-a-data-driven-colormap-tp28050311p28067995.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi,
is it possible to perform a surface plot a NxM matrix with date-axes?
Similar to plot_date for 1D-Plots. The dates are available as an N-sized (or
M-sized) array of float values.
At the moment, I am using imshow or matshow for the color plots, but the
only way I found to manipulate the axes is the 'extent' keyword argument,
which is not sufficient in this context.
Any hints?
Micha
-- 
View this message in context: http://old.nabble.com/matshow---imshow-with-date-axis-tp28068228p28068228.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

2010年3月29日 Alan G Isaac <ala...@gm...>:
> Can you explain this:
> norm = colors.Normalize(vmin = -1, vmax = 1)
The normaliser takes some arbitrary value and returns a value in [0,
1]. Hence the name. The value \in [0, 1] is handed over to the
cmap's __call__(), resulting in the color value. And yes, I guess you
can use vmin and vmax directly, it's just a matter of taste.
As you can pass in also *boundaries* to Colorbar(), this may be an
alternative. It will display all red above the max value, though it's
harder to tick. When you want the highest value to be really
represented by red, not near-to-red.
Friedrich

I noticed that colorbar.Colorbar treats segmentation via *boundaries*
as compulsory, i.e., it thinks it must tick at the *boundaries* or
nowhere. Wouldn't it be useful to have an kwarg which overrides this
and always uses ticker.MaxNLocator()?
Friedrich

matplotlib.ticker:748:
 # ORIGINAL:
 # step = max(int(0.99 + len(self.locs) / float(self.nbins)), 1)
 step = int(math.ceil(len(self.locs) / (self.nbins + 1)))
There is a from __future__ import division statement.
Who verifies (or falsifies)? I checked with values len(locs) = 10,
11, 12, 100, 101, 110, 111, and nbins = 10, and it works (it didn't
before) for me. I have a proof available.
Friedrich

On 3/28/2010 7:19 PM, Friedrich Romstedt wrote:
> I fixed your problem
Can you explain this:
norm = colors.Normalize(vmin = -1, vmax = 1)
I take it that this scales the range for the
color bar, which is what 'luminance' must
refer to in the docs? In which case, can
we just set vmin and vmax as imshow keywords?
 patch = ax.imshow(Z, interpolation='nearest', extent=[-5,5,-5,5], 
vmin = -1, vmax = 1)
(Seems to work.)
Thanks!
Alan

Yeates, Mathew C (388D) wrote:
> Hi
> 
> I would expect
> 
> hgt=ma.masked_where(div == 0,hgt)
> 
> m.contourf(x,y,hgt,15,cmap=plt.cm.jet)
> 
> 
> 
> to produce a map complementary to the map produced by
> 
> 
> 
> hgt=ma.masked_where(div != 0,hgt)
> 
> m.contourf(x,y,hgt,15,cmap=plt.cm.jet)
> 
> 
> 
> But, this is not the case.
> 
> What am I missing?
Basemap contourf calls mpl contourf, and mpl contourf leaves a grid box 
empty if any of its corners is masked. Does this account for what you 
are seeing?
Eric

2010年3月28日 Chloe Lewis <ch...@be...>:
> That would be a lot nicer, Friedrich; could you share demo code? I can't
> make the set_ylim work, but I think I'm being clumsy with the object model.
It seems that I cannot read the sections following after the "From
this:" and "I get this:"?
But anyway, I solved it for you :-) See attached script. colorbar()
takes the argument *boundaries*, defining the region to draw. It's
code from Alan G Isaac slightly modified and also posted there back,
too. You will want to run the code via python -i norm.py.
For the vmin and vmax, if you like it more you can also pass in norm =
matplotlib.colors.Normalize(vmin, vmax) instead.
Note that the ticking is a bit weird, there is also a bug in
matplotlib I will report on right after this e-mail, whose bugfix you
will maybe want to apply to get ticking properly working. When you
have insane values for C.min() and C.max() anyway, I'm afraid you have
to retick manually with *ticks* to colorbar(). The ticker.MaxNLocator
is only used when not using the *boundaries* arg to colorbar(),
unfortunately. Otherwise it tries to create maximal many and less
than 11 ticks by using the lowest value and an appropriate step in
*boundaries*. I think the implementation of ticking is cumbersome and
never optimal.
Friedrich