matplotlib-users Mailing List for matplotlib

Jeff, 
I agree with John -- matplotlib and the wxAgg backend 
don't seem slow to me. For simple line drawings in 
'stripchart mode', where a line is being updated as 
fast as possible, I regularly get ~12 plots per second
with wxAgg and mpl 0.81+ on Windows. It's hard for me 
to consider that slow, but you weren't specific about 
what you were expecting.
Do the examples at 
 http://cars.uchicago.edu/~newville/Python/MPlot 
help? MPlot gives a wxPanel and wxFrame for simple line 
drawings that gives GUI-controlled customization of line 
color and style, etc and provides simple ways for end 
users to zoom in/out, print, and saving of images. The 
examples/test.py includes a stripchart-like plot.
--Matt

When I create a plot that is smaller than the figure window, the tickmark=
=20
locator seems to locate the ticks based on the figure size, not the subplot=
=20
size. I tried this several ways.
figure(figsize=3D(3,3))
plot([1000,2000,3000],[1,2,3])
subplots_adjust(right=3D0.5)
This messes up the ticklabels, especially on the x-axis. It should resample=
=20
and only plot a couple of ticks, but I don't know the command to update the=
=20
ticks. The same happens when I resize with the tool on the toolbar. Almost=
=20
the same happens when I use the axes command from the get go:
figure(figsize=3D(3,3))
axes( [.1,.1,.4,.8] )
plot([1000,2000,3000],[1,2,3])
This give fine looking y labels, but the x-axis is still messed up. Does it=
=20
maybe always plot 4 ticks on each axis by default? Should it maybe check if=
=20
there is space for that?
Any suggestions are appreciated,
Thanks,
Mark

>>>>> "Darren" =3D=3D Darren Dale <dd...@co...> writes:
 Darren> Also, if you provide a brief example script, along with
 Darren> any relevant changes you have made to matplotlibrc, and
 Darren> some detail about how long it takes to plot (maybe some
 Darren> profiling?), we might be able to provide some more useful
 Darren> suggestions.
A script is by far the most useful thing you can provide. =20
Note that there was an optimization for line marker drawing on win32
introduced in matplotlib-0.81 From the release notes:
 Fast markers on win32 The marker cache optimization is finally
 available for win32, after an agg bug was found and fixed (thanks
 Maxim!). Line marker plots should be considerably faster now on
 win32. The original optimization announcement is ay
 http://matplotlib.sourceforge.net/whats_new.html#0.72-line_marker_opti=
mizations_in_agg
See also http://matplotlib.sourceforge.net/faq.html#SLOW
JDH
=00

On Thursday 30 June 2005 11:15 am, Jeff Peery wrote:
> Hello,
>
> I wrote a small WXAgg program with wxpython. I'm plotting simple
> datasets, right now I'm plotting an array of approx. 450 points. The
> graphing is very slow. What can I do to speed this up? I have python
> 2.4, wxpython 2.4, and this is what I'm using for matplotlib
> 'matplotlib-0.80.win32-py2.4.exe'.
Have you checked the list archives? There has been some discussion about speed 
traps that you can take steps to avoid. For example, are you running a script 
with interactive mode on? That can cause a big performance hit. 
Also, if you provide a brief example script, along with any relevant changes 
you have made to matplotlibrc, and some detail about how long it takes to 
plot (maybe some profiling?), we might be able to provide some more useful 
suggestions.
-- 
Darren

Hello, 
I wrote a small WXAgg program with wxpython. I'm plotting simple
datasets, right now I'm plotting an array of approx. 450 points. The
graphing is very slow. What can I do to speed this up? I have python
2.4, wxpython 2.4, and this is what I'm using for matplotlib
'matplotlib-0.80.win32-py2.4.exe'.
Thanks.
Jeff

James Boyle writes:
[snip]
 > For values outside the range of the max and min of the normalization, I 
 > have added filled triangles above and below the color bar.
 > This type of display is found in other visualization software. It 
 > allows the scale to just consider values of interest, while providing 
 > information as to the location and relative values of outliers.
I'd also find this very useful. For comparison, there is something
similar (colorscale) on the matlab central file exchange:
http://tinyurl.com/8yzbe
but it looks like it was broken in the change from R13 to R14. Not
that I can be of any use adding this, but colorscale also has a nice
feature that:
"The colormap may contain special values for null data areas, and
these special values may be excluded from the scale bar. Or, the
colormap may be deliberately partitioned and shared with a different
image in the same figure, and that image may have its own, entirely
distinct, color scale."
There's a nice walkthrough here:
http://www.mathworks.com/company/newsletters/digest/nov02/earth.html
Regards, Phil

I have attached a figure (colorBarExample.png) that I hope everybody 
can see.
The figure is for data from a model whose gridbox size is a function of 
time and space. I have done a color fill using a color map (jet) and a
normalization. I use a collection of patches, each patch defines a 
polygon of the vertices of the gridbox and a color indexed to the value 
in that gridbox.
I have to modify the call to the colorbar so that it accepts this 
colormap and normalization.
For values outside the range of the max and min of the normalization, I 
have added filled triangles above and below the color bar.
This type of display is found in other visualization software. It 
allows the scale to just consider values of interest, while providing 
information as to the location and relative values of outliers.
I have also modified the colorbar code( in figure.py) to scale the 
width of the colorbar. I generate plots with aspect ratios of x axis 
long with respect to the y axis and in this situation the colorbar gets 
to be too fat.
The purpose of this long winded message is to advocate that the color 
bar code be modified to make this facility an option( ie specified 
color map, normalization, width scaling and end caps).
I am willing to do this myself - but I would need some help. 
Previously, John suggested that I make the routine that does the fill 
calls derive from ScalarMappable. This would make the colorbar color 
map and scaling come along naturally. My skill level is such that I 
have not been
able to get this to work - I am willing but not very able. My thought 
now is to make some substantial additions to colorbar.
--Jim
\

Thanks John this works just fine - I consistently set the clipping off 
- BEFORE adding the patch.
--Jim
On Jun 29, 2005, at 1:13 PM, John Hunter wrote:
>>>>>> "James" == James Boyle <bo...@ll...> writes:
>
> James> Say I have drawn a plot and now I want to make an
> James> annotation on the top of the plot outside the axis. In my
> James> case I want to put a filled triangle up there in a certain
> James> location. I am using a polygon - patch to make the figure.
>
> James> How does one do this? I have tried turning the clipping off
> James> but to no avail - I can put my triangle anywhere within the
> James> axis but if it is outside it disappears. In the manual
> James> there is an example for placing text outside the axis but
> James> not patches.
>
> The problem you are encountering is that the Axes will automatically
> set the clipbox when you call add_patch, so you need to make the call
> to turn off clipping *after* adding it to the axes
>
> from pylab import figure, show
> from matplotlib.patches import RegularPolygon
>
> fig = figure()
> ax = fig.add_subplot(111)
>
> # above the yaxis and centered on xaxis; Axes coords
> tri = RegularPolygon((0.5, 1.05), 3, radius=0.2, 
> transform=ax.transAxes)
>
> # adding the patch to the axes automatically sets the clipbox
> ax.add_patch(tri)
>
> # so you need to turn it off after adding it
> tri.set_clip_on(False)
>
> show()
>
> You can also add patches and lines directly to the Figure instance, as
> follows, but these are drawn before the Axes and so are behind them
>
> from pylab import figure, show
> from matplotlib.patches import RegularPolygon
>
> fig = figure()
> ax = fig.add_axes([0.1,0.1, 0.8, 0.6])
>
> # Figure coords
> tri = RegularPolygon((0.5, 0.8), 3, radius=0.2, 
> transform=fig.transFigure)
>
> fig.patches.append(tri)
>
> show()
>
> If there is a need to customize this further, let me know. Eg, we
> could move the drawing call for the lines and patches below the Axes
> draw so they come out on top.
>
>
> JDH
>

>>>>> "James" == James Boyle <bo...@ll...> writes:
 James> Say I have drawn a plot and now I want to make an
 James> annotation on the top of the plot outside the axis. In my
 James> case I want to put a filled triangle up there in a certain
 James> location. I am using a polygon - patch to make the figure.
 James> How does one do this? I have tried turning the clipping off
 James> but to no avail - I can put my triangle anywhere within the
 James> axis but if it is outside it disappears. In the manual
 James> there is an example for placing text outside the axis but
 James> not patches.
The problem you are encountering is that the Axes will automatically
set the clipbox when you call add_patch, so you need to make the call
to turn off clipping *after* adding it to the axes
 from pylab import figure, show
 from matplotlib.patches import RegularPolygon
 fig = figure()
 ax = fig.add_subplot(111)
 # above the yaxis and centered on xaxis; Axes coords
 tri = RegularPolygon((0.5, 1.05), 3, radius=0.2, transform=ax.transAxes)
 # adding the patch to the axes automatically sets the clipbox
 ax.add_patch(tri)
 # so you need to turn it off after adding it
 tri.set_clip_on(False)
 show()
You can also add patches and lines directly to the Figure instance, as
follows, but these are drawn before the Axes and so are behind them
 from pylab import figure, show
 from matplotlib.patches import RegularPolygon
 fig = figure()
 ax = fig.add_axes([0.1,0.1, 0.8, 0.6])
 # Figure coords
 tri = RegularPolygon((0.5, 0.8), 3, radius=0.2, transform=fig.transFigure)
 fig.patches.append(tri)
 show()
If there is a need to customize this further, let me know. Eg, we
could move the drawing call for the lines and patches below the Axes
draw so they come out on top.
JDH

Say I have drawn a plot and now I want to make an annotation on the top 
of the plot outside the axis. In my case I want to put a filled 
triangle up there in a certain location. I am using a polygon - patch 
to make the figure.
How does one do this? I have tried turning the clipping off but to no 
avail - I can put my triangle anywhere within the axis but if it is 
outside it disappears. In the manual there is an example for placing 
text outside the axis but not patches.
Thanks for any help.
--Jim

Hi Matt,
Matt Newville wrote:
>Hi Werner, 
>
>This should be tested on Mac and Linux too. I had portability
>problems when I originally wrote the printing support. I can
>believe that wx has gotten better.
> 
>
Agree, however I don't have access to either of those, like to get a Mac 
but this won't be in the future.
>But also, the current Printer_Setup() provides a simple way to
>control the size of the image on the paper. I didn't see that on
>yours.
> 
>
I did not see Printer_Setup2() as a replacement of Printer_Setup() but 
as an alternative. It uses the wxPython standard stuff, so I don't know 
if the image size can be done with it, will have another look at this 
sometimes next week.
See you
Werner
>--Matt
>
>On 2005年6月28日, Werner F. Bruhin wrote:
>
> 
>
>>Hi John,
>>
>>The attached backend_wx contains "def Printer_Setup2(self, 
>>event=None):", which uses the standard wxPython printer setup dialog 
>>this works for me on Windows XP Pro SP1, and Windows 2000.
>>
>>Any chance that this could go into the next release?
>>
>>See you
>>Werner
>>
>> 
>>
>
>
>
>
>
> 
>

>>>>> "Brent" == Brent Hueth <bh...@ia...> writes:
 Brent> This is a problem for me only b/c I'm trying to generate a
 Brent> plot with a total number of subplots > 10.
 Brent> I can't seem to track down the source of the discrepancy.
 Brent> Thanks,
This is a bug in 0.82 that is fixed in CVS and will be fixed in the
next bugfix release.
The patch that fixed it is
http://sourceforge.net/tracker/index.php?func=detail&aid=1222180&group_id=80706&atid=560722
JDH

Hello,
Is this a bug, or am I missing something:
 
>>> from pylab import *
>>> s = subplot(211)
>>> s._num
0
>>> s = subplot(212)
>>> s._num
1
>>> t = subplot(2,1,1)
>>> t._num
0
>>> t = subplot(2,1,2)
>>> t._num
0
This is a problem for me only b/c I'm trying to generate a plot with a total
number of subplots > 10.
I can't seem to track down the source of the discrepancy. 
Thanks,
Brent

On 2005年6月28日, Jeff Whitaker wrote:
> John: OK, I've fixed it so pylab is not imported at all if either (1) the 
> 'ax' keyword is used in Basemap.__init__ (in which case only one axes 
> instance is used by that Basemap instance), or (2) the 'ax' keyword is used 
> in all Basemap method calls that do drawing (in which case different axes may 
> be used by the same Basemap instance). If you don't use the 'ax' keyword, 
> basemap methods behave like their pylab counterparts (i.e. pylab.gca is used 
> to get the current axis).
Great! That's perfect for us. Thanks for the quick response.
We have exactly the setup that John was describing. We use Basemap in 
cron jobs that don't have any X windows support. Our default backend is 
Qt, and Qt itself aborts and core dumps (!) if you try to use it when 
there's no X server present. So we wanted to avoid pylab loading a 
backend.
I guess we'll see these changes in the next release, 0.5.2 or 0.6, 
whichever is next, yes?
Thanks again,
Michael
========================================================================
 Michael Brady
 Jet Propulsion Laboratory (M/S 301-140L)
 4800 Oak Grove Drive
 Pasadena, CA 91109 E-mail: Mic...@jp... 
========================================================================

Jeff Whitaker wrote:
> John: OK, I've fixed it so pylab is not imported at all if either (1) 
> the 'ax' keyword is used in Basemap.__init__ (in which case only one 
> axes instance is used by that Basemap instance), or (2) the 'ax' keyword 
> is used in all Basemap method calls that do drawing (in which case 
> different axes may be used by the same Basemap instance). If you don't 
> use the 'ax' keyword, basemap methods behave like their pylab 
> counterparts (i.e. pylab.gca is used to get the current axis).
Nice job Jeff. You've come up with a solution that satisfies a wide 
variety of uses. Hurray for keyword arguments!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi Werner, 
This should be tested on Mac and Linux too. I had portability
problems when I originally wrote the printing support. I can
believe that wx has gotten better.
But also, the current Printer_Setup() provides a simple way to
control the size of the image on the paper. I didn't see that on
yours.
--Matt
On 2005年6月28日, Werner F. Bruhin wrote:
> Hi John,
> 
> The attached backend_wx contains "def Printer_Setup2(self, 
> event=None):", which uses the standard wxPython printer setup dialog 
> this works for me on Windows XP Pro SP1, and Windows 2000.
> 
> Any chance that this could go into the next release?
> 
> See you
> Werner
> 

John Hunter wrote:
>>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes:
>>>>>> 
>>>>>>
>
> Jeff> Michael: By popular demand, I put this back in 0.5.1. You
> Jeff> can now pass an axes instance to any Basemap method. The
> Jeff> default is 'ax=None', in which case pylab.gca is used to get
> Jeff> the current one. Does this solve your problem?
>
>You can potentially get into trouble by simply importing the pylab
>module at all since pylab will try and import the default backend.
>This usually isn't fatal, but isn't ideal either. I would suggest
>conditionally importing pylab only if it is needed, eg when ax=None.
>
>The use case you would be avoiding is for example when the user hasn't
>changed the default backend (GTKAgg) from .matplotlibrc. They may be
>using non-pylab basemap in pure agg mode over a web app server. When
>you import pylab, the module will try and import pygtk, which will
>fail if pygtk is not installed or if there is no X11 connection. Of
>course, the user could change the default backend in the rc file, but
>one point of the OO interface is to have as little magic as possible.
>By conditionally importing pylab, you can avoid these kinds of
>problems.
>
>JDH 
> 
>
John: OK, I've fixed it so pylab is not imported at all if either (1) 
the 'ax' keyword is used in Basemap.__init__ (in which case only one 
axes instance is used by that Basemap instance), or (2) the 'ax' keyword 
is used in all Basemap method calls that do drawing (in which case 
different axes may be used by the same Basemap instance). If you don't 
use the 'ax' keyword, basemap methods behave like their pylab 
counterparts (i.e. pylab.gca is used to get the current axis).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449
325 Broadway Web : http://www.cdc.noaa.gov/~jsw
Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124

Hi John,
The attached backend_wx contains "def Printer_Setup2(self, 
event=None):", which uses the standard wxPython printer setup dialog 
this works for me on Windows XP Pro SP1, and Windows 2000.
Any chance that this could go into the next release?
See you
Werner

On Monday 27 June 2005 16:22, John Hunter wrote:
> >>>>> "Jesper" == Jesper Larsen <jl...@dm...> writes:
>
> Jesper> Dear matplotlib-users, I have made an application for
> Jesper> tsunami wave travel time prediction (slowmo.sf.net). The
> Jesper> application uses the basemap toolkit and is developed on
> Jesper> Linux. I would like to offer potential Windows users an
> Jesper> easier way to install and test it than is currently
> Jesper> available.
>
> Jesper> For this I would need a binary windows package of the
> Jesper> basemap toolkit in a newer version than 0.21 which is
> Jesper> currently available. Unfortunately I do not have access to
> Jesper> the windows compilers that are necessary to make this
> Jesper> binary package. I would therefore be very grateful if
> Jesper> anyone from this list has the binary or could easily
> Jesper> produce it.
>
> OK, I just uploaded win32 binaries for basemap 0.5.1 for python2.3 and
> 2.4. Give them and test drive and let us know if there are any
> problems.
>
> JDH
Thanks John,
I only tested the binaries for Python2.3. They seem to work fine.
Jesper

Jeff Whitaker wrote:
> Chris Barker wrote:
> It makes sense to me to have a given Basemap[ object 
>> associated with one and only one axes, but maybe I'm weird. 
> 
> No you're not weird. But I've been told that some people building GUI 
> apps want to use the same Basemap instance to draw in different windows.
Fair enough. OO is not always the best way to go.
>> I did use it at first, but decided that a simple pyrex wrapper was 
>> simpler and easier to maintain.
You're probably right about that. I still haven't used pyrex, but it 
looks like a great idea. Maybe I have a reason to now.
>> My module is not really fully optimized to take advantage of numarray 
>> - it does the transformation one point at a time in a c-loop and 
>> stuffs the result in a list. So, there's a lot of overhead in 
>> repeatedly calling the proj4 c-routine.
Darn, that's exactly the kind of thing I'm hoping to avoid,.
>> It would be a lot faster to 
>> recode the proj4 c-routine to process the whole array at once.
I hope I'll get a chance to do this, but I'll probably start by using it 
like it is, and see how the performance is. If do work on it, I'm going 
to try to use the new "array interface" in the latest Numeric (at least 
I think it's there, the Numeric list has been quite lately).
> Chris: I should say that the reason I haven't done this is related to 
> the reason I decided to not use the Thuban module - I know very little 
> about C programming and didn't want to mess with C code.
I can understand that. I'm pretty weak in C myself. Every time I use it, 
I find it painful, and run back to Python as soon as I can.
I hope you won't mind helping me out a bit with PROJ4, I'm still having 
a hard time wrapping my brain around projections.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
 Jeff> Michael: By popular demand, I put this back in 0.5.1. You
 Jeff> can now pass an axes instance to any Basemap method. The
 Jeff> default is 'ax=None', in which case pylab.gca is used to get
 Jeff> the current one. Does this solve your problem?
You can potentially get into trouble by simply importing the pylab
module at all since pylab will try and import the default backend.
This usually isn't fatal, but isn't ideal either. I would suggest
conditionally importing pylab only if it is needed, eg when ax=None.
The use case you would be avoiding is for example when the user hasn't
changed the default backend (GTKAgg) from .matplotlibrc. They may be
using non-pylab basemap in pure agg mode over a web app server. When
you import pylab, the module will try and import pygtk, which will
fail if pygtk is not installed or if there is no X11 connection. Of
course, the user could change the default backend in the rc file, but
one point of the OO interface is to have as little magic as possible.
By conditionally importing pylab, you can avoid these kinds of
problems.
JDH 

Jeff Whitaker wrote:
> Chris Barker wrote:
>
>>
>>
>> Sean Gillies wrote:
>>
>>> There is
>>>
>>> http://hobu.biz/software/pyprojection/
>>
>>
>>
>> Thanks! I thought I'd seen that but couldn't find it just now. Does 
>> anyone know if it is Numeric/numarray aware? I'd need that to get he 
>> performance I'd need. It look like Jeff's code is.
>>
>> Jeff, any particular reason you didn't use this?
>
>
>
> Chris:
>
> I did use it at first, but decided that a simple pyrex wrapper was 
> simpler and easier to maintain.
> My module is not really fully optimized to take advantage of numarray 
> - it does the transformation one point at a time in a c-loop and 
> stuffs the result in a list. So, there's a lot of overhead in 
> repeatedly calling the proj4 c-routine. It would be a lot faster to 
> recode the proj4 c-routine to process the whole array at once.
> -Jeff
>
>
>
Chris: I should say that the reason I haven't done this is related to 
the reason I decided to not use the Thuban module - I know very little 
about C programming and didn't want to mess with C code.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Chris Barker wrote:
>
>
> Sean Gillies wrote:
>
>> There is
>>
>> http://hobu.biz/software/pyprojection/
>
>
> Thanks! I thought I'd seen that but couldn't find it just now. Does 
> anyone know if it is Numeric/numarray aware? I'd need that to get he 
> performance I'd need. It look like Jeff's code is.
>
> Jeff, any particular reason you didn't use this?
Chris:
I did use it at first, but decided that a simple pyrex wrapper was 
simpler and easier to maintain. 
My module is not really fully optimized to take advantage of numarray - 
it does the transformation one point at a time in a c-loop and stuffs 
the result in a list. So, there's a lot of overhead in repeatedly 
calling the proj4 c-routine. It would be a lot faster to recode the 
proj4 c-routine to process the whole array at once. 
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Chris Barker wrote:
>> For us, it's important to have a pure OO-interface.
>
>
> I totally agree. But it's not really about OO vs. imperative, the 
> problem is counting on gca() and friends. I just plain find this ugly.
>
> Anyway while we're talking about it, it would be much more OO to have:
>
> axes = figure.add_axes( ... )
> bMap = Basemap( axes )
>
> (having passed in an axes object to the Basemap constructor)
>
> bMap.drawcoastlines()
> bMap.drawcountries()
> bMap.fillcontinents()
>
> Now you don't need to pass in the axes each time, but it's not use 
> gca() either. It makes sense to me to have a given Basemap[ object 
> associated with one and only one axes, but maybe I'm weird.
Chris: I agree relying on gca is not good in general, and in 0.5.1 I've 
fixed this (see my reply to Michael Brady). The problem with your 
solution is that you can't use the same Basemap instance to plot on 
different axes.
>
> By the way, Jeff. I've taken a quick look at your Proj4 code. I'm 
> hoping to make use of it for another project (the wxPython 
> FloatCanvas). It looks to me like to would make sense to make that a 
> separate library that could be used with other projects. I nice 
> Pythonic projection module would be great. Do you think this makes sense?
Sure, I could easily do that. Let me know if you think the Thuban 
module that Sean mentioned would be a better all-purpose solution.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Michael Brady wrote:
> Hi Jeff and Basemap users,
>
> Here at NASA's Jet Propulsion Laboratory, we're very happy Basemap 
> users. We've been using it to create plots of spacecraft launch 
> trajectory ground tracks.
>
> I've just attempted to upgrade from basemap 0.2 to 0.5. I have a problem.
>
> The basemap 0.2 interface worked with an Axes object that you supplied 
> explicitly:
>
> axes = figure.add_axes( ... )
> bMap = Basemap( ... )
>
> bMap.drawcoastlines( axes )
> bMap.drawcountries( axes )
> bMap.fillcontinents( axes )
>
> The basemap 0.5 interface has changed so that you don't pass in an 
> Axes object to Basemap functions. Instead, functions are called like so:
>
> bMap.drawcoastlines()
> bMap.drawcountries()
> bMap.fillcontinents()
>
> and inside each function there's a call to mpylab.gca(), so that the 
> map gets drawn on the pylab current axes.
>
> Our software is written without any dependencies on pylab, so we are 
> unable to upgrade to basemap 0.5.
>
> For us, it's important to have a pure OO-interface. Jeff, would it be 
> possible to restore the v0.2 Basemap class interface which doesn't 
> make any pylab calls?
Michael: By popular demand, I put this back in 0.5.1. You can now pass 
an axes instance to any Basemap method. The default is 'ax=None', in 
which case pylab.gca is used to get the current one. Does this solve 
your problem?
>
> (Another less important question: why did the name of the basemap 
> data directory change from 'basemap' to 'basemap-pyVERSION'? Is there 
> something python-version-specific in there?)
This is for package managers like apt and rpm which have different 
packages for different python versions. If the directory name is the 
same, the packages will collide with each other. The other way to solve 
this is to have a separate package for the data files, but I thought 
this was easier.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg