matplotlib-users Mailing List for matplotlib

On 09/10/2007, Jeff Whitaker <js...@fa...> wrote:
> Adam: If you can convert your coordinates into latitudes and
> longitudes, then you can plot the data with the basemap tookit on your
> choice of map projection (see
> http://www.scipy.org/Cookbook/Matplotlib/Maps for an example).
Thats just what I'm after. Thanks a lot!
Cheers
Adam

Adam Mercer wrote:
> Hi
>
> I have some skymap data, i.e. theta, phi and some intensity that I
> would like to plot on the surface of a sphere, does matplotlib support
> plotting on the surface of a sphere? I've looked through the examples
> and can't seem to find anything.
>
> Any help would be greatly appreciated.
>
> Cheers
>
> Adam
>
> 
Adam: If you can convert your coordinates into latitudes and 
longitudes, then you can plot the data with the basemap tookit on your 
choice of map projection (see 
http://www.scipy.org/Cookbook/Matplotlib/Maps for an example).
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hi
I have some skymap data, i.e. theta, phi and some intensity that I
would like to plot on the surface of a sphere, does matplotlib support
plotting on the surface of a sphere? I've looked through the examples
and can't seem to find anything.
Any help would be greatly appreciated.
Cheers
Adam

> Hi! I have some code importing MPL and wxmpl; presently, I have 
> version 0.90.1 of the former installed and 1.2.8 of the latter. I 
> hadn't run this code in a while; when I last did, in the late spring 
> sometime, it worked fine. Now, when I do (from the command line), a 
> call in it to <class-derived-from-wxmpl.PlotPanel>.Axes.clear() 
> results in an error seq. ending in AttributeError: 
> VectorLineCollection instance has no attribute 'get_xdata'. One 
> "catch": the "old" version still exists as a py2app-ed stand-alone; I 
> tried it and sure enough, it still works fine. By searching its Mac 
> App file tree, I was able to determine that this old py2app-ed version 
> is using version 0.90.0 of MPL; unfortunately, it (appears to be) 
> using a compiled version of wxmpl, so I don't know how to determine 
> what version of that its using. Did the update of MPL from 0.90.0 to 
> 0.90.1 change anything that might result in this error; has there been 
> a change in wxmpl which might result in this error? (Between then and 
> now, I switched to a new Mac and installed everything from scratch, so 
> it's very likely that my present version of wxmpl is different from 
> the one I had installed when I created the py2app.) Any other ideas? 
> (I'm at a total loss.) Thanks!
>
> DG
> -- 
> ERD/ORR/NOS/NOAA 
> <http://response.restoration.noaa.gov/emergencyresponse/>
Additional info: when I'm in the directory in which wxmpl.pyc resides 
inside the py2app bundle, run Python and import wxmpl, I get:
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "wxmpl.pyc", line 18, in <module>
 (
 File "wx/__init__.pyc", line 45, in <module>
 File "wx/_core.pyc", line 4, in <module>
 File "wx/_core_.pyc", line 18, in <module>
 File "wx/_core_.pyc", line 15, in __load
 ImportError: 
'/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload/wx/_core_.so' 
not found
(Note that the application package from which I got this error is the 
version of the program that works!)
Following a suggestion, I copied this wxmpl.pyc to a place outside the 
application package, ran python, and it imported fine. I checked its 
version number and it's 1.2.8, same as what I have installed presently 
(wxmpl.__file__ verified that the local version was imported, not my 
site-packages version).
I'm at more of a loss than ever...
DG
-- 
ERD/ORR/NOS/NOAA <http://response.restoration.noaa.gov/emergencyresponse/>

On 10/9/07, Michael Droettboom <md...@st...> wrote:
> I don't know of any way to side step this -- for various reasons, the
> backend must be known during pylab initialization. It might be possible
> with fairly significant refactoring... maybe someone has looked deeper
> into this than I have.
There is a "switch_backends" function in pylab that attempts to do a
post import switching. It works reasonably well, but is not
recommended for switching across threaded GUI backends (eg in
ipython), which is why it has mostly remained an experimental feature.
JDH

Chris wrote:
> Updating matplotlib with a new SVN build a couple days ago induced
> the following error:
> 
> RuntimeError: matplotlib.use() must be called *before* pylab
> or matplotlib.backends is imported for the first time.
> 
> This has not occurred before. Am I to understand that once pylab
> is imported, you cannot change backends? That seems strange. Is 
> there a way of side-stepping this?
This has long been the case, but only recently was an error added. (It 
was confusing to many who *thought* they were changing the backend, when 
in fact they weren't.)
I don't know of any way to side step this -- for various reasons, the 
backend must be known during pylab initialization. It might be possible 
with fairly significant refactoring... maybe someone has looked deeper 
into this than I have.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Updating matplotlib with a new SVN build a couple days ago induced
the following error:
RuntimeError: matplotlib.use() must be called *before* pylab
or matplotlib.backends is imported for the first time.
This has not occurred before. Am I to understand that once pylab
is imported, you cannot change backends? That seems strange. Is 
there a way of side-stepping this?

Unfortunately, I'm not able to reproduce this here with the .py you 
attached. Both SVN r3926 (before the PNG resolution change) and SVN 
r3927 (after the PNG resolution change) work for me. Are you comparing 
those two SVN revisions, or SVN vs. 0.90.1?
I can confirm that the PNG you attached is all white and fully transparent.
Just for information, my machine (RHEL4) has libpng 1.2.7.
Can you send a copy of your matplotlibrc? Also, can you save out a .raw 
image? (If you rename it to foo.rgba, you can display these images with 
the ImageMagick command "display -size 1800x1200 -depth 8 foo.rgba") 
That would help determine whether the problem is in the PNG-writing code 
or something higher up.
Cheers,
Mike
Wayne E. Harlan wrote:
> Michael:
> 
> I tried a complete checkout for comparison (3929). In the meantime, my 
> libpng is 1.2.18 (installed from source as is everything - this is an 
> LFS/BLFS system.) Yes, the plot was working before the change and I can 
> send you some png's from that if you need to see them, or I can 
> backtrack to 0.90.1 and repeat this. Please bear in mind that the plot 
> displays (and always has) quite correctly on screen - it's just the 
> saved file that consists of just background. I have attached the 
> script, the resulting png and a saved screenshot from the Gimp. 
> Attachments are gzipped.
> 
> Wayne
> 
> Michael Droettboom wrote:
>> Hmmm. I'm very surprised that this change could cause that. All it 
>> does is add an additional metadata chunk to the PNG file, which 
>> shouldn't have any affect on the image data itself. simple_plot.py 
>> works fine for me in GIMP 2.0.5 both before and after this change. 
>> Can you verify that this plot was working before the change to save 
>> the resolution in the PNG file? If so, can you send me the source for 
>> your plot and the PNG file? Also, what version of libpng are you 
>> using? (pkg-config --version libpng should display this on most recent 
>> Linux distros).
>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael:
I tried a complete checkout for comparison (3929). In the meantime, my 
libpng is 1.2.18 (installed from source as is everything - this is an 
LFS/BLFS system.) Yes, the plot was working before the change and I can 
send you some png's from that if you need to see them, or I can 
backtrack to 0.90.1 and repeat this. Please bear in mind that the plot 
displays (and always has) quite correctly on screen - it's just the 
saved file that consists of just background. I have attached the 
script, the resulting png and a saved screenshot from the Gimp. 
Attachments are gzipped.
Wayne
Michael Droettboom wrote:
> Hmmm. I'm very surprised that this change could cause that. All it 
> does is add an additional metadata chunk to the PNG file, which 
> shouldn't have any affect on the image data itself. simple_plot.py 
> works fine for me in GIMP 2.0.5 both before and after this change. Can 
> you verify that this plot was working before the change to save the 
> resolution in the PNG file? If so, can you send me the source for your 
> plot and the PNG file? Also, what version of libpng are you using? 
> (pkg-config --version libpng should display this on most recent Linux 
> distros).
>