matplotlib-users Mailing List for matplotlib (Page 2)

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

>>>>> "LUK" == LUK ShunTim <shu...@po...> writes:
 LUK> Hello, I saw John Hunter's post a moment ago on building a
 LUK> win installer for the basemap module. Is is possible to build
 LUK> the matplotlib package itself with mingw/msys?
Yes, that is how I build the win32 installers. Look at the
instructions in setupext.py for win32 -- they point you to a tarfile
win32_static.tar.gz of dependencies (zlib, png and freetype) that you
will need to untar in your build dir. You can skip the GTK stuff in
the build instructions if you do not want to use GTK on win32; in this
case you will probably want to change the default backend in
matplotlibrc to something else *before* you build. Also, note that
matplotlib uses a conditional compilation depending on what modules it
finds at compile time. So if you want to build for Numeric and
numarray, make sure you have installed both before compiling
matplotlib. If you want to compile the gtk* backends, make sure you
have installed pygtk and the gtk runtime and dev libs. And so on.
JDH

Hello,
I saw John Hunter's post a moment ago on building a win installer for
the basemap module. Is is possible to build the matplotlib package
itself with mingw/msys?
Regards,
ST
--

>>>>> "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.
I will try and get this done on Monday. 
Note that setting up a free win32 build environment using mingw is
not very difficult. Here are my notes for setting it up -- replace any
version numbers with the most recent
== Required setup ==
 * Download MinGW-3.1.0-1.exe and MSYS-1.0.10.exe from
 http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721
 and install both in C:\MinGW
 * Download pexports-0.42h 
 from http://starship.python.net/crew/kernr/mingw32/pexports-0.42h.zip 
 and extract it to C:\Program Files\pexports-0.42h
For compiling C++ extensions under mingw, I found I needed to patch
c:/Python23/Lib/distutils/cygwinccompiler.py to work with g++. Find
the set_executables part and change it to
 self.set_executables(compiler='gcc -mcygwin -O -Wall',
 compiler_cxx='g++ -mcygwin -O -Wall',
 compiler_so='gcc -mcygwin -mdll -O -Wall',
 linker_exe='gcc -mcygwin',
 linker_so=('%s -mcygwin %s' %
 (self.linker_dll, shared_option)))
The compiler_cxx is where the change is.
For Python2.4 there is another oneline change you must make; see
http://mail.python.org/pipermail/python-list/2004-December/254826.html.
You must comment out
 #self.dll_libraries = ['msvcr71']
== THE BUILD ==
Execute the following profile batch file to setup path and
environment variables
 SET PATH=C:\WINDOWS;C:\WINDOWS\COMMAND;c:\Python23;c:\mingw\bin;c:\mingw\mingw32\bin;c:\msys1円.0\bin
 set LDD=gcc
 set CC=gcc
 set CXX=g++
 set CFLAGS=-mms-bitfields
Execute the command below, changing the version numbers for other
pythons
 copy c:\windows\system32\python24.dll .
 c:\progra~1\pexports-0.42h\bin\pexports python24.dll > python24.def
 c:\MinGW\bin\dlltool --dllname python24.dll --def python24.def --output-lib libpython24.a
 copy libpython24.a c:\python24\libs
 del python24.dll
 del libpython24.a
Build the python binary installer for the package of your choice
 python setup.py build --compiler=mingw32 bdist_wininst --install-script postinstall.py 
JDH

On 2005年6月24日, Fernando Perez apparently wrote: 
> fig, ax, im = matshow(samplemat(d),returnall=True) 
Yes, this works.
(And indeed is documented.)
Thank you,
Alan Isaac

Hi folks,
There are now binary installers for OS-X for matplotlib 0.82 for both 
Apple's python2.3.0 and the 2.4.1 Framework build (available at:
http://undefined.org/python/)
They were built on OS-X 10.3.9, and should work there and on 10.4
They work with Agg, Tk and Wx back ends, and require Numeric or numarray
You can find them at:
http://pythonmac.org/packages/
(the 10.4 one may not be there just yet, but should be there soon.)
Have fun!
-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...

jl...@dm... 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
-- 
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

Alan G Isaac wrote:
> If I run the script below (taken straight from 
> the docs except for the imports) the script fails 
> with a message that matshow does not return a tuple, which 
> appears true. Dropping the extra LHS variables allows the 
> script to run, but produces 4 separate figures.
> 
> Thanks, 
> Alan Isaac 
> 
> 
> ============================================ 
> 
> from scipy import * 
> from pylab import * 
> def samplemat(dims): 
> aa = zeros(dims) 
> for i in range(min(dims)): 
> aa[i,i] = i 
> return aa 
> 
> dimlist = [(12,12),(128,64),(64,512),(2048,256)] 
> 
> for d in dimlist: 
THIS LINE:
> fig, ax, im = matshow(samplemat(d)) 
should be:
 > fig, ax, im = matshow(samplemat(d),returnall=True)
> show() 
Cheers,
f

>>>>> "dswesty" == dswesty <ds...@bl...> writes:
 dswesty> Can anyone help me to figure out how to get tick colors
 dswesty> to be anything other than black?
 dswesty> I am trying to produce a plot with a gray background
 dswesty> and red axes and tick lines. My code to do this is as
 dswesty> follows:
 dswesty> plot1 = subplot(111,axisbg='#444444')
 dswesty> plot1.plot(xarr,y1arr,'bo',xarr,y2arr,'r^',xarr,y3arr,'gs')
 dswesty> set(plot1.get_xticklabels(), 'color', 'r', fontsize=18)
 dswesty> set(plot1.get_yticklabels(), 'color', 'r', fontsize=18)
 dswesty> set(plot1.get_ygridlines(), 'color', 'w', linewidth=2)
 dswesty> set(plot1.get_xgridlines(),visible=False)
 dswesty> set(plot1.get_yticklines(),color='r', linewidth=2)
 dswesty> xlabel('r (Kilometers)',color='y',fontsize=20)
 dswesty> ylabel('Luminosity (foes/s)',color='y',fontsize=20)
 dswesty> I have tried numerous tricks to get the ticklines to be
 dswesty> anything other than black with no success. Any help
 dswesty> would be greatly appreciated.
You have the right approach, but there is a subtly that is tripping
you up. It took me a good 5 minutes to figure out why your approach
wasn't working. matplotlib.lines.Line2D objects can have both a
linestyle and a marker. Hence the command 
 plot(x, y, '-o', color='red', mfc='blue', mec='g')
creates a *single* Line2D object which renders as a solid red line
with the x,y vertices marked by circles with a blue markerfacecolor
and a green markeredgecolor (mfc and mec are aliases)
The trick you are missing is that the tick lines are *markers* (their
marker symbols are an enum in matplotlib.lines: TICKLEFT, TICKRIGHT,
TICKUP, TICKDOWN).
To set the color or tick markers, you need to set the markeredgecolor
property
 setp(ax.get_xticklines() + ax.get_yticklines() , mec='red')
A bit non-intuitive, admittedly, but it does work.
JDH

 Can anyone help me to figure out how to get tick 
 colors to be anything other than black?
 I am trying to produce a plot with a gray background
 and red axes and tick lines. My code to do this is
 as follows:
 plot1 = subplot(111,axisbg='#444444')
 plot1.plot(xarr,y1arr,'bo',xarr,y2arr,'r^',xarr,y3arr,'gs')
 set(plot1.get_xticklabels(), 'color', 'r', fontsize=18)
 set(plot1.get_yticklabels(), 'color', 'r', fontsize=18)
 set(plot1.get_ygridlines(), 'color', 'w', linewidth=2)
 set(plot1.get_xgridlines(),visible=False)
 set(plot1.get_yticklines(),color='r', linewidth=2)
 xlabel('r (Kilometers)',color='y',fontsize=20)
 ylabel('Luminosity (foes/s)',color='y',fontsize=20)
 I have tried numerous tricks to get the ticklines to be anything
 other than black with no success. Any help would be greatly
 appreciated.
 Doug

I would like to announce PyUniversalLibrary version 20050623.
PyUniversalLibrary is a Python wrapper for Measurement Computing's
Universal Library for data acquisition on Microsoft Windows operating
systems.
http://www.its.caltech.edu/~astraw/pyul.html
Work in Progress
----------------
Currently PyUniversalLibrary is incomplete. I have only wrapped the
functions which I have personally needed, primarily buffered analog
input. If you need more functionality, you will hopefully find that
the start I have made in wrapping this library useful. I welcome your
changes and additions. I will include them with the next release with
appropriate credit.