matplotlib-users Mailing List for matplotlib

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

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?
It isn't.
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

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
-- 
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...

On Jun 27, 2005, at 1:45 PM, Chris Barker wrote:
> Michael Brady wrote:
>> 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()
>
>> 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.
>
> 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?
>
> -Chris
>
There is
 http://hobu.biz/software/pyprojection/
which Howard Butler extracted from Thuban
 http://thuban.intevation.org/
cheers,
Sean
--
Sean Gillies
sgillies at frii dot com
http://zcologia.com

Michael Brady wrote:
> 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()
> 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.
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?
-Chris
Jeff, would it be
> possible to restore the v0.2 Basemap class interface which doesn't make 
> any pylab calls?
> 
> What was the intent of the basemap interface change? Was it to present 
> a more "pylab-like" interface? If so, perhaps we could keep the Basemap 
> class pylab-free, and add a "basemap-lab" layer atop it, just as pylab 
> sits atop the Matplotlib classes.
> 
> Anyway, just wanted to get people's thoughts. My agenda is that I'd 
> very much like to get a Basemap pure-OO interface (with no pylab 
> dependencies) restored.
> 
> (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?)
> 
> Thanks,
> 
> Michael Brady
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
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 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?
What was the intent of the basemap interface change? Was it to present a 
more "pylab-like" interface? If so, perhaps we could keep the Basemap 
class pylab-free, and add a "basemap-lab" layer atop it, just as pylab 
sits atop the Matplotlib classes.
Anyway, just wanted to get people's thoughts. My agenda is that I'd very 
much like to get a Basemap pure-OO interface (with no pylab 
dependencies) restored.
(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?)
Thanks,
Michael Brady

On Monday 27 June 2005 12:27 pm, Peter L. Buschman wrote:
> There must be a best-practice for this.... ;-)
>
> How do I control the formatting of high numbers in ticklabels? For
> example, with an xlim of 1,000,000 the my ticklabel at the end of my x axis
> reads x1e6. I'd rather have it be 1000000 since I'll only have 1 or 2 tick
> labels...
>
> What is the recommended way of achieving this?
Let me make sure I understand what you are looking for. You want your 
ticklabels to read "1000000", "2000000", and you dont want the label at the 
end of axis. Is that right?
If so, there are two options at the moment:
1) gca().xaxis.set_major_formatter(OldScalarFormatter())
2) gca().set_xticklabels(('1000000','2000000'))
-- 
Darren

I think that you must install the devel package for Numeric or numarray.
you're problem is this line:
src/_nc_transforms.cpp:8:34: Numeric/arrayobject.h: No such file or directory
Regards,
N.
Jean-Baptiste wrote:
>Hi !
>
>
>I am trying to compile matplotlib-0.82 on my RHEL 4 system.
>But it fails at some point, maybe linked to Numeric.
>
>[lws03] /nfs_mount/home/jcazier/devel/novi/new/matplotlib-0.82 $ python setup.py build
>...
>building 'matplotlib._nc_transforms' extension
>gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -fPIC -Isrc -I. -I/usr/local/include -I/usr/include -I/usr/include/python2.3 -c src/mplutils.cpp -o build/temp.linux-i686-2.3/src/mplutils.o -DNUMERIC=1
>gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -fPIC -Isrc -I. -I/usr/local/include -I/usr/include -I/usr/include/python2.3 -c src/_nc_transforms.cpp -o build/temp.linux-i686-2.3/src/_nc_transforms.o -DNUMERIC=1
>In file included from /usr/include/python2.3/Python.h:8,
> from ./CXX/Objects.hxx:9,
> from ./CXX/Extensions.hxx:18,
> from src/_transforms.h:12,
> from src/_nc_transforms.cpp:2:
>/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" redefined
>In file included from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/os_defines.h:39,
> from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++config.h:35,
> from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/functional:54,
> from src/_nc_transforms.cpp:1:
>/usr/include/features.h:150:1: warning: this is the location of the previous definition
>src/_nc_transforms.cpp:8:34: Numeric/arrayobject.h: No such file or directory
>src/_nc_transforms.cpp: In member function `Py::Object Bbox::update_numerix(const Py::Tuple&)':
>src/_nc_transforms.cpp:436: error: `PyArrayObject' undeclared (first use this function)
>...
>
>
>Any idea ?
>
>Thanks
>
>Jean-Baptiste
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> 
>

Jean-Baptiste wrote:
> src/_nc_transforms.cpp:8:34: Numeric/arrayobject.h: No such file or directory
> Any idea ?
See above: you don't have the Numeric headers installed.
f

I was reading the FAQ, and I believe the following to be true, but just 
want to make sure.
Once a figure is created, there is no way to change the size in a backend 
independent manner. Is this correct?
thanks,
Danny

Hi !
I am trying to compile matplotlib-0.82 on my RHEL 4 system.
But it fails at some point, maybe linked to Numeric.
[lws03] /nfs_mount/home/jcazier/devel/novi/new/matplotlib-0.82 $ python setup.py build
...
building 'matplotlib._nc_transforms' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -fPIC -Isrc -I. -I/usr/local/include -I/usr/include -I/usr/include/python2.3 -c src/mplutils.cpp -o build/temp.linux-i686-2.3/src/mplutils.o -DNUMERIC=1
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -D_GNU_SOURCE -fPIC -fPIC -Isrc -I. -I/usr/local/include -I/usr/include -I/usr/include/python2.3 -c src/_nc_transforms.cpp -o build/temp.linux-i686-2.3/src/_nc_transforms.o -DNUMERIC=1
In file included from /usr/include/python2.3/Python.h:8,
 from ./CXX/Objects.hxx:9,
 from ./CXX/Extensions.hxx:18,
 from src/_transforms.h:12,
 from src/_nc_transforms.cpp:2:
/usr/include/python2.3/pyconfig.h:850:1: warning: "_POSIX_C_SOURCE" redefined
In file included from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/os_defines.h:39,
 from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/i386-redhat-linux/bits/c++config.h:35,
 from /usr/lib/gcc/i386-redhat-linux/3.4.3/../../../../include/c++/3.4.3/functional:54,
 from src/_nc_transforms.cpp:1:
/usr/include/features.h:150:1: warning: this is the location of the previous definition
src/_nc_transforms.cpp:8:34: Numeric/arrayobject.h: No such file or directory
src/_nc_transforms.cpp: In member function `Py::Object Bbox::update_numerix(const Py::Tuple&)':
src/_nc_transforms.cpp:436: error: `PyArrayObject' undeclared (first use this function)
...
Any idea ?
Thanks
Jean-Baptiste

Jesper Larsen wrote:
>On Friday 24 June 2005 19:13, you wrote:
> 
>
>>Jesper Larsen wrote:
>> 
>>
>>>Hi matplotlib users,
>>>
>>>I'm trying to make some global plots with the basemap toolkit (version
>>>0.4.2). I would like the maps to be centered at arbitrary longitudes. For
>>>this I use the shiftgrid method. When I make the plot and put on
>>>meridians some of them have wrong W/E indicators. I was wondering whether
>>>that was due to a wrong longitude array.
>>>
>>>Let's say I want to make a map with the left and right margin at 150W with
>>>a resolution of 60 degrees. How should the longitude array then look
>>>like? Is it [-150, -90, -30, 30, 90, 150, -150], [210, 270, 330, 30, 90,
>>>150, 210], [210, 270, 330, 390, 450, 510, 570], or something else?
>>>
>>>Kind regards,
>>>Jesper
>>> 
>>>
Jesper: I've now fixed this is CVS - there was indeed a bug in the 
labelling if lon > 360 or lon < -180. To check out a new version from CVS:
cvs -z3 -d:ext:ano...@cv...:/cvsroot/matplotlib co toolkits
-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

There must be a best-practice for this.... ;-)
How do I control the formatting of high numbers in ticklabels? For example,
with an xlim of 1,000,000 the my ticklabel at the end of my x axis reads x1e6.
I'd rather have it be 1000000 since I'll only have 1 or 2 tick labels...
What is the recommended way of achieving this?
--PLB

John Hunter wrote:
> In this
> case you will probably want to change the default backend in
> matplotlibrc to something else *before* you build.
This brings up a question:
Could we make the default back end code a little "smarter":
For example: have the default default be different for different 
platforms, and perhaps have an ordered list of defaults, so that when 
matplotlib starts up, it can try them in order to see if they exist, and 
pick the first one that does? I think that order of that list would 
probably be different in different platforms.
Just a thought
-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...

On Friday 24 June 2005 19:13, you wrote:
> Jesper Larsen wrote:
> >Hi matplotlib users,
> >
> >I'm trying to make some global plots with the basemap toolkit (version
> > 0.4.2). I would like the maps to be centered at arbitrary longitudes. For
> > this I use the shiftgrid method. When I make the plot and put on
> > meridians some of them have wrong W/E indicators. I was wondering whether
> > that was due to a wrong longitude array.
> >
> >Let's say I want to make a map with the left and right margin at 150W with
> > a resolution of 60 degrees. How should the longitude array then look
> > like? Is it [-150, -90, -30, 30, 90, 150, -150], [210, 270, 330, 30, 90,
> > 150, 210], [210, 270, 330, 390, 450, 510, 570], or something else?
> >
> >Kind regards,
> >Jesper
>
> Jesper: I think the correct answer would be "any of the above" -
> assuming your data array actually is ordered the same way as your
> longitude array. It would help if you could post a small example.
>
> -Jeff
Hi Jeff,
Here is an example which results in af plot with some of the longitudes 
wrongly marked W on my computer:
#!/usr/bin/env /usr/bin/python
import pylab
import matplotlib.toolkits.basemap as basemap
def plot_test(filename):
 pylab.clf()
 lat = pylab.arange(-90.,91.,30.)
 lon = pylab.arange(100.,461.,60.)
 data = pylab.zeros((len(lat),len(lon)))
 # Create map with SW corner at 100E,90S and NW corner at 100E,90N
 m = basemap.Basemap(lon[0],lat[0],lon[-1],lat[-1],resolution='l')
 # Compute native map projection coordinates for lat/lon grid.
 xlon, ylat = m(*pylab.meshgrid(lon,lat))
 m.contourf(xlon,ylat,data)
 m.drawcoastlines()
 m.drawparallels(lat,labels=[1,0,0,0])
 m.drawmeridians(lon,labels=[0,0,0,1])
 pylab.savefig(filename)
if __name__ == '__main__':
 plot_test('1.png') # The longitude annotations for 40E and 100E are wrong
Kind regards,
Jesper

>>>>> "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