matplotlib-users Mailing List for matplotlib (Page 2)

Hi, I'm still working on my interpolating from an irregularly space grid
and then running pcolormesh on the resulting output. With some of the newer
data I've been plotting I've noticed that my plots are complete garbage. I
realized that this was actually because of the output from griddata rather
than some problem with pcolormesh/pcolor/etc (basically I get huge negative
values like -80000 from the interpolation when all of my data points lie
within [0,20]) .
Googling I found out that the default griddata has some problems, and that
there is a better, more robust version available through natgrid. I
downloaded the natgrid-0.2.1 package from here
http://sourceforge.net/projects/matplotlib/files%2Fmatplotlib-toolkits%2Fnatgrid-0.2/
.
My question now is, how do I install this and give it a shot? I'm running
on Ubuntu (or Xubuntu rather). The README doesn't seem to have any
directions.
Also, let's say that this new griddata doesn't work for me, is there
something else I could try? The interpolation problems are strange, because
I can break my data into 3 segments (I read 3 files to obtain the data so
this is the natural way to do it) and I can plot and interpolate correctly
any segment individually. It's only when I do all 3 segments together that
the interpolation begins to fail.
Any ideas?
Thanks for the continued help!
Brad

On 12/20/2011 10:48 AM, Brad Malone wrote:
> Tony,
>
> Thanks for the pcolormesh suggestion! It is quite a bit faster than
> pcolor for me (maybe 50-100x faster)!
There is also the Axes.pcolorfast() method. It has no pylab wrapper, 
and it is fussier than the others about its input arguments, but it uses 
the fastest method that the input grid permits. In your case it would 
be the speed of imshow, which is faster than pcolormesh.
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.pcolorfast
Note that like pcolor and pcolormesh its grid is based on the 
specification of the boundaries, not the centers, but unlike pcolormesh 
and pcolor it will not automatically chop off a row and a column of the 
2-D color array to be plotted if you give it a grid with the same 
dimensions as the color array.
Eric
>
> Best,
> Brad
>
> On Tue, Dec 20, 2011 at 10:10 AM, Tony Yu <ts...@gm...
> <mailto:ts...@gm...>> wrote:
>
>
>
> On Tue, Dec 20, 2011 at 9:22 AM, Brad Malone <bra...@gm...
> <mailto:bra...@gm...>> wrote:
>
> HI Paul,
>
> Thanks. I didn't realize it was that simple (appears that doing
> this essentially plots everything against integers in x and y).
> This will be a good backup plan if I can't get pcolor to work,
> although as you say, I'll have to fiddle around some with the
> axis formatters and such I suppose to get a good final plot out
> of this.
>
> Best,
> Brad
>
> On Tue, Dec 20, 2011 at 12:12 AM, Paul Ivanov
> <piv...@gm... <mailto:piv...@gm...>> wrote:
>
> Hey again, Brad,
>
> Brad Malone, on 2011年12月19日 23:44, wrote:
> > Hi, I am plotting a grid with pcolor. Below I've got a
> 1000x1000 grid.
> >
> > xi=linspace(-0.1,x[-1]+2,1000)
> > > yi=linspace(-0.1,maxfreq+10,1000)
> > > print 'Calling griddata...'
> > > zi=griddata(x,y,z,xi,yi,interp='nn')
> > > plt.pcolor(xi,yi,zi,cmap=plt.cm.hot)
> ...
> > How could I modify my above data (which is in xi,yi,and
> zi) to
> > work with imshow (which seems to take 1 argument for data).
>
> Try either:
>
> plt.matshow(zi,cmap=plt.cm.hot)
>
> or
>
> plt.imshow(zi,cmap=plt.cm.hot)
>
> The first should be the quickest - it doesn't do any
> fancy interpolation, and actually just passes some arguments to
> the second. Using imshow directly, however, allows you to set a
> different type of interpolation, should you desire it. If
> you want xi and yi to be accurately reflect in the plot, you
> might have to play around with changing the axis formatters
> (though there might be an easier way of doing that, which
> escapes
> me right now)
>
> best,
> --
> Paul Ivanov
>
>
> You may also want to try:
>
> plt.pcolormesh(xi,yi,zi,cmap=plt.cm.hot)
>
> If I remember correctly, pcolormesh is faster but a bit more
> restrictive. (I think it's slower than matshow and imshow).
>
> -Tony
>
> P.S. I never knew about matshow; thanks Paul!
>
>
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Tony,
Thanks for the pcolormesh suggestion! It is quite a bit faster than pcolor
for me (maybe 50-100x faster)!
Best,
Brad
On Tue, Dec 20, 2011 at 10:10 AM, Tony Yu <ts...@gm...> wrote:
>
>
> On Tue, Dec 20, 2011 at 9:22 AM, Brad Malone <bra...@gm...>wrote:
>
>> HI Paul,
>>
>> Thanks. I didn't realize it was that simple (appears that doing this
>> essentially plots everything against integers in x and y). This will be a
>> good backup plan if I can't get pcolor to work, although as you say, I'll
>> have to fiddle around some with the axis formatters and such I suppose to
>> get a good final plot out of this.
>>
>> Best,
>> Brad
>>
>> On Tue, Dec 20, 2011 at 12:12 AM, Paul Ivanov <piv...@gm...>wrote:
>>
>>> Hey again, Brad,
>>>
>>> Brad Malone, on 2011年12月19日 23:44, wrote:
>>> > Hi, I am plotting a grid with pcolor. Below I've got a 1000x1000 grid.
>>> >
>>> > xi=linspace(-0.1,x[-1]+2,1000)
>>> > > yi=linspace(-0.1,maxfreq+10,1000)
>>> > > print 'Calling griddata...'
>>> > > zi=griddata(x,y,z,xi,yi,interp='nn')
>>> > > plt.pcolor(xi,yi,zi,cmap=plt.cm.hot)
>>> ...
>>> > How could I modify my above data (which is in xi,yi,and zi) to
>>> > work with imshow (which seems to take 1 argument for data).
>>>
>>> Try either:
>>>
>>> plt.matshow(zi,cmap=plt.cm.hot)
>>>
>>> or
>>>
>>> plt.imshow(zi,cmap=plt.cm.hot)
>>>
>>> The first should be the quickest - it doesn't do any
>>> fancy interpolation, and actually just passes some arguments to
>>> the second. Using imshow directly, however, allows you to set a
>>> different type of interpolation, should you desire it. If
>>> you want xi and yi to be accurately reflect in the plot, you
>>> might have to play around with changing the axis formatters
>>> (though there might be an easier way of doing that, which escapes
>>> me right now)
>>>
>>> best,
>>> --
>>> Paul Ivanov
>>>
>>
> You may also want to try:
>
> plt.pcolormesh(xi,yi,zi,cmap=plt.cm.hot)
>
> If I remember correctly, pcolormesh is faster but a bit more restrictive.
> (I think it's slower than matshow and imshow).
>
> -Tony
>
> P.S. I never knew about matshow; thanks Paul!
>

Jeff,
Here are the versions that I'm working with:
basemap: 1.0.2
matplotlib: 1.1.0
numpy: 1.5.1
libgeos: 3.2.0
I ran the coordinate conversion on another computer with the same system
configuration and there it works as it should.
I have tried to clean my system and removed all the packages related to
basemap (geos, proj) and only reinstalled the required libgeos packages.
I deleted the basemap directory from
the /usr/local/lib/python2.7/dist-packages.
I deleted the _geoslib.so from /usr/local/lib/python2.7/dist-packages.
After that I rebuilt and installed basemap.
The problem still remains.
Don't know what's going wrong.
Stefan.
Am Montag, den 19.12.2011, 18:33 -0700 schrieb Jeff Whitaker:
> On 12/19/11 4:47 PM, Stefan Mertl wrote: 
> > Hi Jeff,
> > 
> > I'm not an expert in coordinate transformation and the usage of proj, so
> > I can't exactly tell you if I have all the datum files installed. If you
> > could tell me what files could be missing I could search for them.
> > 
> > What makes me wonder, is that you get the results that my
> > mpl_toolkits.basemap.pyproj.Proj usage produced. When using some
> > conversion tools on the internet like
> > http://home.hiwaay.net/~taylorc/toolbox/geodesy/datumtrans/ or
> > http://www.uwgb.edu/dutchs/UsefulData/ConvertUTMNoOZ.HTM
> > I get the results that my commandline proj produces.
> > So I think that something with my pyproj installation is not working.
> > 
> > Regards,
> > Stefan.
> 
> Stefan: I mis-spoke in my earlier email - the answer I get with pyproj
> is the same as you get with command line proj. What version of
> basemap do you have installed?
> 
> -Jeff 
> > 
> > Am Montag, den 19.12.2011, 15:51 -0700 schrieb Jeff Whitaker: 
> > > On 12/19/11 2:23 PM, Stefan Mertl wrote:
> > > > Hello,
> > > > 
> > > > I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
> > > > lon/lat to UTM coordinate conversion.
> > > > I did some tests and noticed that there is a discrepancy between the
> > > > mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
> > > > output.
> > > > 
> > > > e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
> > > > coordinates UTM zone 33 with WGS84 ellipse.
> > > > I'm using the following proj4 string for the conversion:
> > > > +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> > > > 
> > > > The output using mpl_toolkits.basemap.pyproj.Proj is:
> > > > x: 611458.865; y: 5339596.032
> > > > 
> > > > The proj commandline tool using the same proj4 string gives:
> > > > x: 611458.69 y: 5339617.54
> > > > 
> > > > As you can see, the y coordinate differs significantly.
> > > > 
> > > > Here's the code used with the basemap pyproy classes:
> > > > 
> > > > --------------------------------------------------
> > > > 
> > > > from mpl_toolkits.basemap.pyproj import Proj
> > > > 
> > > > # I got the proj string from
> > > > # http://spatialreference.org/ref/epsg/32633
> > > > myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
> > > > +no_defs")
> > > > 
> > > > lat = 48.2
> > > > lon = 16.5
> > > > 
> > > > (x,y) = myProj(lon, lat)
> > > > 
> > > > print "x: %.3f; y: %.3f" % (x,y)
> > > > 
> > > > ---------------------------------------------------
> > > > 
> > > > Can somebody explain me this behavior?
> > > > 
> > > > Regards,
> > > > Stefan.
> > > > 
> > > Stefan:
> > > 
> > > When I run this test, I get the same answer with both, and it is the 
> > > same as the answer basemap.pyproj gave you. I suspect you didn't 
> > > install the extra datum files with your command-line proj distribution.
> > > 
> > > -Jeff
> > > 
> > > 
> > > 
> > > ------------------------------------------------------------------------------
> > > Write once. Port to many.
> > > Get the SDK and tools to simplify cross-platform app development. Create 
> > > new or port existing apps to sell to consumers worldwide. Explore the 
> > > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> > > http://p.sf.net/sfu/intel-appdev
> > > 
> > > 
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

On Tue, Dec 20, 2011 at 9:22 AM, Brad Malone <bra...@gm...> wrote:
> HI Paul,
>
> Thanks. I didn't realize it was that simple (appears that doing this
> essentially plots everything against integers in x and y). This will be a
> good backup plan if I can't get pcolor to work, although as you say, I'll
> have to fiddle around some with the axis formatters and such I suppose to
> get a good final plot out of this.
>
> Best,
> Brad
>
> On Tue, Dec 20, 2011 at 12:12 AM, Paul Ivanov <piv...@gm...>wrote:
>
>> Hey again, Brad,
>>
>> Brad Malone, on 2011年12月19日 23:44, wrote:
>> > Hi, I am plotting a grid with pcolor. Below I've got a 1000x1000 grid.
>> >
>> > xi=linspace(-0.1,x[-1]+2,1000)
>> > > yi=linspace(-0.1,maxfreq+10,1000)
>> > > print 'Calling griddata...'
>> > > zi=griddata(x,y,z,xi,yi,interp='nn')
>> > > plt.pcolor(xi,yi,zi,cmap=plt.cm.hot)
>> ...
>> > How could I modify my above data (which is in xi,yi,and zi) to
>> > work with imshow (which seems to take 1 argument for data).
>>
>> Try either:
>>
>> plt.matshow(zi,cmap=plt.cm.hot)
>>
>> or
>>
>> plt.imshow(zi,cmap=plt.cm.hot)
>>
>> The first should be the quickest - it doesn't do any
>> fancy interpolation, and actually just passes some arguments to
>> the second. Using imshow directly, however, allows you to set a
>> different type of interpolation, should you desire it. If
>> you want xi and yi to be accurately reflect in the plot, you
>> might have to play around with changing the axis formatters
>> (though there might be an easier way of doing that, which escapes
>> me right now)
>>
>> best,
>> --
>> Paul Ivanov
>>
>
You may also want to try:
plt.pcolormesh(xi,yi,zi,cmap=plt.cm.hot)
If I remember correctly, pcolormesh is faster but a bit more restrictive.
(I think it's slower than matshow and imshow).
-Tony
P.S. I never knew about matshow; thanks Paul!

HI Paul,
Thanks. I didn't realize it was that simple (appears that doing this
essentially plots everything against integers in x and y). This will be a
good backup plan if I can't get pcolor to work, although as you say, I'll
have to fiddle around some with the axis formatters and such I suppose to
get a good final plot out of this.
Best,
Brad
On Tue, Dec 20, 2011 at 12:12 AM, Paul Ivanov <piv...@gm...> wrote:
> Hey again, Brad,
>
> Brad Malone, on 2011年12月19日 23:44, wrote:
> > Hi, I am plotting a grid with pcolor. Below I've got a 1000x1000 grid.
> >
> > xi=linspace(-0.1,x[-1]+2,1000)
> > > yi=linspace(-0.1,maxfreq+10,1000)
> > > print 'Calling griddata...'
> > > zi=griddata(x,y,z,xi,yi,interp='nn')
> > > plt.pcolor(xi,yi,zi,cmap=plt.cm.hot)
> ...
> > How could I modify my above data (which is in xi,yi,and zi) to
> > work with imshow (which seems to take 1 argument for data).
>
> Try either:
>
> plt.matshow(zi,cmap=plt.cm.hot)
>
> or
>
> plt.imshow(zi,cmap=plt.cm.hot)
>
> The first should be the quickest - it doesn't do any
> fancy interpolation, and actually just passes some arguments to
> the second. Using imshow directly, however, allows you to set a
> different type of interpolation, should you desire it. If
> you want xi and yi to be accurately reflect in the plot, you
> might have to play around with changing the axis formatters
> (though there might be an easier way of doing that, which escapes
> me right now)
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists, off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk7wQ30ACgkQe+cmRQ8+KPdN8gCfY3SlI7F5zoXVrDL86VRyq3pC
> SwwAn2bc6MBQjasKVxVzrvVRxaPJKiUP
> =NmWr
> -----END PGP SIGNATURE-----
>
>

On Tue, Dec 20, 2011 at 8:00 AM, Nils Wagner
<nw...@ia...> wrote:
> Hi all,
>
> How do I use animation.FuncAnimation to plot real-life
> data from parsing a text file ?
Here's a version that does what I think you want:
import matplotlib.pyplot as plt
import matplotlib.animation as animation
import sys
import time
import re
x_data = [] # x
y_data = [] # y
fig = plt.figure()
ax = fig.add_subplot(111)
curve,= ax.plot([],[],lw=2)
ax.set_xlim(0,5)
ax.set_ylim(0,25)
ax.grid()
def tail_f(file):
 while True:
 where = file.tell() # current file position, an integer (may
be a long integer).
 line = file.readline()
 if re.search('without errors',line): break
 # Always yield the line so that we return back to the event loop. If we
 # need to go back and read again, we'll get a free delay from the
 # animation system.
 yield line
 if not line:
 file.seek(where) # seek(offset[, whence]) ->None. Move to
new file position.
def run(line, curve, x, y):
 if re.search('x=',line):
 liste = line.split('=')
 x.append(liste[1].strip())
 if re.search('y=',line):
 liste = line.split('=')
 y.append(liste[1].strip())
 curve.set_data(x,y)
 print x,y
 return curve
# The passed in frames can be a func that returns a generator. This
# generator keeps return "frame data"
def data_source(fname=sys.argv[1]):
 return tail_f(open(fname))
# This init function initializes for drawing returns any initialized
# artists.
def init():
 curve.set_data([],[])
 return curve
line_ani = animation.FuncAnimation(fig, run, data_source, init_func=init,
 fargs=(curve,x_data,y_data), interval=100)
plt.show()
Ben was also right in that you could subclass FuncAnimation and
override/extend methods. This would have the benefit of giving more
control over the handling of seek(). (Something else for my todo
list...)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Dec 20, 2011 at 8:00 AM, Nils Wagner
<nw...@ia...>wrote:
> Hi all,
>
> How do I use animation.FuncAnimation to plot real-life
> data from parsing a text file ?
>
>
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib.animation as animation
>
> import sys
> import time
> import re
>
> x = [] # x
> y = [] # y
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
> curve,= ax.plot([],[],lw=2)
> ax.set_xlim(0,5)
> ax.grid()
>
> def tail_f(file):
> interval = 1.0
>
> while True:
> where = file.tell() # current file position, an
> integer (may be a long integer).
> line = file.readline()
> if re.search('without errors',line): break
> if not line:
> time.sleep(interval)
> file.seek(where) # seek(offset[, whence]) ->
> None. Move to new file position.
> else:
> yield line
>
>
> def run():
> for line in tail_f(open(sys.argv[1])):
> print line,
> if re.search('x=',line):
> liste = line.split('=')
> x.append(liste[1].strip())
> if re.search('y=',line):
> liste = line.split('=')
> y.append(liste[1].strip())
>
> curve.set_data(x,y)
> print x,y
> #
> #
> #
> run()
> plt.show()
>
>
> The text file looks like
>
> x=0.0
> y=0.0
> blabla
> x=1.0
> y=1.0
> blabla
> x=2.0
> y=4.0
> blabla
> ...
>
>
>
> Nils
>
>
Nils,
I think the key thing to keep in mind when using any of the animators is
that the animator in question is driving the calls to update the plot from
its own event source. In most cases, that source is a timer. For
FuncAnimator, the function passed into the constructor must perform
whatever actions are needed for a single update.
What I would do is Subclass FuncAnimator so that its constructor will
create an empty Line2D object that has already been added to an axes object
(or you can pass an empty one yourself as an argument to the function). In
the function run(), you would obtain the next chunk of data and then update
the Line2D object with that information.
I think you have it mostly done, just need a few extra pieces.
Cheers!
Ben Root

Hi all,
How do I use animation.FuncAnimation to plot real-life 
data from parsing a text file ?
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animation
import sys
import time
import re
x = [] # x
y = [] # y
fig = plt.figure()
ax = fig.add_subplot(111)
curve,= ax.plot([],[],lw=2)
ax.set_xlim(0,5)
ax.grid()
def tail_f(file):
 interval = 1.0
 while True:
 where = file.tell() # current file position, an 
integer (may be a long integer).
 line = file.readline()
 if re.search('without errors',line): break
 if not line:
 time.sleep(interval)
 file.seek(where) # seek(offset[, whence]) -> 
None. Move to new file position.
 else:
 yield line
def run():
 for line in tail_f(open(sys.argv[1])):
 print line,
 if re.search('x=',line):
 liste = line.split('=')
 x.append(liste[1].strip())
 if re.search('y=',line):
 liste = line.split('=')
 y.append(liste[1].strip())
 curve.set_data(x,y)
 print x,y
#
#
#
run()
plt.show()
The text file looks like
x=0.0
y=0.0
blabla
x=1.0
y=1.0
blabla
x=2.0
y=4.0
blabla
...
Nils

Hey again, Brad,
Brad Malone, on 2011年12月19日 23:44, wrote:
> Hi, I am plotting a grid with pcolor. Below I've got a 1000x1000 grid.
> 
> xi=linspace(-0.1,x[-1]+2,1000)
> > yi=linspace(-0.1,maxfreq+10,1000)
> > print 'Calling griddata...'
> > zi=griddata(x,y,z,xi,yi,interp='nn')
> > plt.pcolor(xi,yi,zi,cmap=plt.cm.hot)
... 
> How could I modify my above data (which is in xi,yi,and zi) to
> work with imshow (which seems to take 1 argument for data).
Try either:
 plt.matshow(zi,cmap=plt.cm.hot)
or
 plt.imshow(zi,cmap=plt.cm.hot)
The first should be the quickest - it doesn't do any
fancy interpolation, and actually just passes some arguments to
the second. Using imshow directly, however, allows you to set a
different type of interpolation, should you desire it. If
you want xi and yi to be accurately reflect in the plot, you
might have to play around with changing the axis formatters
(though there might be an easier way of doing that, which escapes
me right now)
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi, I am plotting a grid with pcolor. Below I've got a 1000x1000 grid.
xi=linspace(-0.1,x[-1]+2,1000)
> yi=linspace(-0.1,maxfreq+10,1000)
> print 'Calling griddata...'
> zi=griddata(x,y,z,xi,yi,interp='nn')
> plt.pcolor(xi,yi,zi,cmap=plt.cm.hot)
I am able to plot this on my computer, but it's very slow and monitoring
'top' while python is running shows it using up quite a bit of memory. This
data set that I'm currently using is only about 1/10 of what I eventually
want to plot. While I may be able to drop the resolution to some degree,
I'd like to be able to speed this up if possible. Google searches reveal
different people talking about imshow and pcolormesh being faster than
pcolor. Is this true? How could I modify my above data (which is in
xi,yi,and zi) to work with imshow (which seems to take 1 argument for
data).
Thanks for the help.
Brad

Paul, thanks so much for that explanation. I appreciate it!
On Mon, Dec 19, 2011 at 9:20 PM, <
mat...@li...> wrote:
> Send Matplotlib-users mailing list submissions to
> mat...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> or, via email, send a message with subject or body 'help' to
> mat...@li...
>
> You can reach the person managing the list at
> mat...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Matplotlib-users digest..."
>
>
> Today's Topics:
>
> 1. Re: basemap UTM conversion discrepancy (Jeff Whitaker)
> 2. Re: basemap UTM conversion discrepancy (Stefan Mertl)
> 3. Re: basemap UTM conversion discrepancy (Jeff Whitaker)
> 4. constant spacing with griddata (Brad Malone)
> 5. Re: constant spacing with griddata (Paul Ivanov)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 2011年12月19日 15:51:47 -0700
> From: Jeff Whitaker <jef...@no...>
> Subject: Re: [Matplotlib-users] basemap UTM conversion discrepancy
> To: in...@st...
> Cc: Matplotlib Users <mat...@li...>
> Message-ID: <4EE...@fa...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 12/19/11 2:23 PM, Stefan Mertl wrote:
> > Hello,
> >
> > I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
> > lon/lat to UTM coordinate conversion.
> > I did some tests and noticed that there is a discrepancy between the
> > mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
> > output.
> >
> > e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
> > coordinates UTM zone 33 with WGS84 ellipse.
> > I'm using the following proj4 string for the conversion:
> > +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> >
> > The output using mpl_toolkits.basemap.pyproj.Proj is:
> > x: 611458.865; y: 5339596.032
> >
> > The proj commandline tool using the same proj4 string gives:
> > x: 611458.69 y: 5339617.54
> >
> > As you can see, the y coordinate differs significantly.
> >
> > Here's the code used with the basemap pyproy classes:
> >
> > --------------------------------------------------
> >
> > from mpl_toolkits.basemap.pyproj import Proj
> >
> > # I got the proj string from
> > # http://spatialreference.org/ref/epsg/32633
> > myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
> > +no_defs")
> >
> > lat = 48.2
> > lon = 16.5
> >
> > (x,y) = myProj(lon, lat)
> >
> > print "x: %.3f; y: %.3f" % (x,y)
> >
> > ---------------------------------------------------
> >
> > Can somebody explain me this behavior?
> >
> > Regards,
> > Stefan.
> >
> Stefan:
>
> When I run this test, I get the same answer with both, and it is the
> same as the answer basemap.pyproj gave you. I suspect you didn't
> install the extra datum files with your command-line proj distribution.
>
> -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-113
> Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: 2011年12月20日 00:47:07 +0100
> From: Stefan Mertl <in...@st...>
> Subject: Re: [Matplotlib-users] basemap UTM conversion discrepancy
> To: Jeff Whitaker <jef...@no...>
> Cc: Matplotlib Users <mat...@li...>
> Message-ID: <1324338427.9176.7.camel@hirn>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jeff,
>
> I'm not an expert in coordinate transformation and the usage of proj, so
> I can't exactly tell you if I have all the datum files installed. If you
> could tell me what files could be missing I could search for them.
>
> What makes me wonder, is that you get the results that my
> mpl_toolkits.basemap.pyproj.Proj usage produced. When using some
> conversion tools on the internet like
> http://home.hiwaay.net/~taylorc/toolbox/geodesy/datumtrans/ or
> http://www.uwgb.edu/dutchs/UsefulData/ConvertUTMNoOZ.HTM
> I get the results that my commandline proj produces.
> So I think that something with my pyproj installation is not working.
>
> Regards,
> Stefan.
>
> Am Montag, den 19.12.2011, 15:51 -0700 schrieb Jeff Whitaker:
> > On 12/19/11 2:23 PM, Stefan Mertl wrote:
> > > Hello,
> > >
> > > I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
> > > lon/lat to UTM coordinate conversion.
> > > I did some tests and noticed that there is a discrepancy between the
> > > mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
> > > output.
> > >
> > > e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
> > > coordinates UTM zone 33 with WGS84 ellipse.
> > > I'm using the following proj4 string for the conversion:
> > > +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> > >
> > > The output using mpl_toolkits.basemap.pyproj.Proj is:
> > > x: 611458.865; y: 5339596.032
> > >
> > > The proj commandline tool using the same proj4 string gives:
> > > x: 611458.69 y: 5339617.54
> > >
> > > As you can see, the y coordinate differs significantly.
> > >
> > > Here's the code used with the basemap pyproy classes:
> > >
> > > --------------------------------------------------
> > >
> > > from mpl_toolkits.basemap.pyproj import Proj
> > >
> > > # I got the proj string from
> > > # http://spatialreference.org/ref/epsg/32633
> > > myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
> > > +no_defs")
> > >
> > > lat = 48.2
> > > lon = 16.5
> > >
> > > (x,y) = myProj(lon, lat)
> > >
> > > print "x: %.3f; y: %.3f" % (x,y)
> > >
> > > ---------------------------------------------------
> > >
> > > Can somebody explain me this behavior?
> > >
> > > Regards,
> > > Stefan.
> > >
> > Stefan:
> >
> > When I run this test, I get the same answer with both, and it is the
> > same as the answer basemap.pyproj gave you. I suspect you didn't
> > install the extra datum files with your command-line proj distribution.
> >
> > -Jeff
> >
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 490 bytes
> Desc: This is a digitally signed message part
>
> ------------------------------
>
> Message: 3
> Date: 2011年12月19日 18:33:10 -0700
> From: Jeff Whitaker <js...@fa...>
> Subject: Re: [Matplotlib-users] basemap UTM conversion discrepancy
> To: in...@st..., mat...@li...
> Message-ID: <4EE...@fa...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 12/19/11 4:47 PM, Stefan Mertl wrote:
> > Hi Jeff,
> >
> > I'm not an expert in coordinate transformation and the usage of proj, so
> > I can't exactly tell you if I have all the datum files installed. If you
> > could tell me what files could be missing I could search for them.
> >
> > What makes me wonder, is that you get the results that my
> > mpl_toolkits.basemap.pyproj.Proj usage produced. When using some
> > conversion tools on the internet like
> > http://home.hiwaay.net/~taylorc/toolbox/geodesy/datumtrans/ or
> > http://www.uwgb.edu/dutchs/UsefulData/ConvertUTMNoOZ.HTM
> > I get the results that my commandline proj produces.
> > So I think that something with my pyproj installation is not working.
> >
> > Regards,
> > Stefan.
>
> Stefan: I mis-spoke in my earlier email - the answer I get with pyproj
> is the same as you get with command line proj. What version of basemap
> do you have installed?
>
> -Jeff
> >
> > Am Montag, den 19.12.2011, 15:51 -0700 schrieb Jeff Whitaker:
> >> On 12/19/11 2:23 PM, Stefan Mertl wrote:
> >>> Hello,
> >>>
> >>> I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
> >>> lon/lat to UTM coordinate conversion.
> >>> I did some tests and noticed that there is a discrepancy between the
> >>> mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
> >>> output.
> >>>
> >>> e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
> >>> coordinates UTM zone 33 with WGS84 ellipse.
> >>> I'm using the following proj4 string for the conversion:
> >>> +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> >>>
> >>> The output using mpl_toolkits.basemap.pyproj.Proj is:
> >>> x: 611458.865; y: 5339596.032
> >>>
> >>> The proj commandline tool using the same proj4 string gives:
> >>> x: 611458.69 y: 5339617.54
> >>>
> >>> As you can see, the y coordinate differs significantly.
> >>>
> >>> Here's the code used with the basemap pyproy classes:
> >>>
> >>> --------------------------------------------------
> >>>
> >>> from mpl_toolkits.basemap.pyproj import Proj
> >>>
> >>> # I got the proj string from
> >>> # http://spatialreference.org/ref/epsg/32633
> >>> myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
> >>> +no_defs")
> >>>
> >>> lat = 48.2
> >>> lon = 16.5
> >>>
> >>> (x,y) = myProj(lon, lat)
> >>>
> >>> print "x: %.3f; y: %.3f" % (x,y)
> >>>
> >>> ---------------------------------------------------
> >>>
> >>> Can somebody explain me this behavior?
> >>>
> >>> Regards,
> >>> Stefan.
> >>>
> >> Stefan:
> >>
> >> When I run this test, I get the same answer with both, and it is the
> >> same as the answer basemap.pyproj gave you. I suspect you didn't
> >> install the extra datum files with your command-line proj distribution.
> >>
> >> -Jeff
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Write once. Port to many.
> >> Get the SDK and tools to simplify cross-platform app development. Create
> >> new or port existing apps to sell to consumers worldwide. Explore the
> >> Intel AppUpSM program developer opportunity.
> appdeveloper.intel.com/join
> >> http://p.sf.net/sfu/intel-appdev
> >>
> >>
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: 2011年12月19日 19:06:26 -0800
> From: Brad Malone <bra...@gm...>
> Subject: [Matplotlib-users] constant spacing with griddata
> To: mat...@li...
> Message-ID:
> <CAG...@ma...
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi, I am trying to use griddata to interpolate some irregularly spaced data
> onto a linspace-created mesh in order to get a temperature plot.
>
> I've been able to follow this example and it's worked perfectly for me:
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/griddata_demo.html
>
> However, when I do my own data I get an error message that says:
>
> >
> > Traceback (most recent call last):
> > File "make_colormap.py", line 248, in <module>
> > zi=griddata(x,y,z,xi,yi,interp='linear')
> > File "/usr/lib/pymodules/python2.6/matplotlib/mlab.py", line 2579, in
> > griddata
> > raise ValueError("output grid must have constant spacing"
> > ValueError: output grid must have constant spacing when using
> > interp='linear'
>
>
> Looking into the documentation it seems that this is just suggesting that
> the xi,yi grids to be interpolated on have constant spacing. I don't know
> if this is supposed to be the SAME constant spacing in xi and yi, but it
> appears not to be, since the example above uses the line:
>
> xi = np.linspace(-2.1,2.1,100)
> > yi = np.linspace(-2.1,2.1,200)
>
>
> so one is twice as fine as the other.
>
> However, my code, when I do something like
>
>
>
> > xi=linspace(-20.1,20.1,100)
> > yi=linspace(-20.1,20.1,200)
> > zi=griddata(x,y,z,xi,yi,interp='linear')
> > CS=plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
>
>
> it gives me the above error complaining about "constant spacing".
>
> Anyone have an idea what I might be missing here? I can turn interp to 'nn'
> and the code works fine, but I'm just curious what about a "constant
> spaced" output grid I don't understand. Is it even possible to create a
> non-constant spaced output grid with linspace?
>
> Thanks for the help!
>
> Brad
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: 2011年12月19日 21:20:11 -0800
> From: Paul Ivanov <piv...@gm...>
> Subject: Re: [Matplotlib-users] constant spacing with griddata
> To: mat...@li...
> Message-ID: <20111220052011.GA11408@ykcyc>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Brad,
>
> Brad Malone, on 2011年12月19日 19:06, wrote:
> > However, when I do my own data I get an error message that says:
> >
> > > Traceback (most recent call last):
> > > File "make_colormap.py", line 248, in <module>
> > > zi=griddata(x,y,z,xi,yi,interp='linear')
> > > File "/usr/lib/pymodules/python2.6/matplotlib/mlab.py", line 2579, in
> > > griddata
> > > raise ValueError("output grid must have constant spacing"
> > > ValueError: output grid must have constant spacing when using
> > > interp='linear'
> ...
>
> > However, my code, when I do something like
> >
> > > xi=linspace(-20.1,20.1,100)
> > > yi=linspace(-20.1,20.1,200)
> > > zi=griddata(x,y,z,xi,yi,interp='linear')
> > > CS=plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
> >
> >
> > it gives me the above error complaining about "constant spacing".
> >
> > Anyone have an idea what I might be missing here? I can turn interp to
> 'nn'
> > and the code works fine, but I'm just curious what about a "constant
> > spaced" output grid I don't understand. Is it even possible to create a
> > non-constant spaced output grid with linspace?
>
> Looking at the code, it seems to be a floating point issue for
> the way linspace works for the particular values you specified.
> This should work for you, instead:
>
> xi=np.arange(-20.1,20.1+1e-14, 40.2/99)
> yi=np.arange(-20.1,20.1+1e-14,40.2/199)
>
> NOTE: neither xi.max() nor yi.max() are "exactly" 20.1, the way
> they were with linspace, nor is xi.max() exactly yi.max(). I say
> "exactly" (in quotes) because when you type in 20.1, the floating point
> number that you get isn't 20.10000000000000000000000000, it's
> more like 20.10000000+change, in ipython, run '%precision 20' to
> see what I mean.
>
> Either the np.linspace or the mpl code likely needs to change,
> because in mpl, the error gets raised when, effectively:
>
> dx = np.diff(xi)
> dx.max() - dx.min() > np.finfo(xi.dtype).resolution
>
> and same for yi, which is what happens with the values you
> provided to linspace, due to the way linspace works.
>
> best,
> --
> Paul Ivanov
> 314 address only used for lists, off-list direct email at:
> http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
>
> ------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> End of Matplotlib-users Digest, Vol 67, Issue 30
> ************************************************
>

Hi Brad,
Brad Malone, on 2011年12月19日 19:06, wrote:
> However, when I do my own data I get an error message that says:
> 
> > Traceback (most recent call last):
> > File "make_colormap.py", line 248, in <module>
> > zi=griddata(x,y,z,xi,yi,interp='linear')
> > File "/usr/lib/pymodules/python2.6/matplotlib/mlab.py", line 2579, in
> > griddata
> > raise ValueError("output grid must have constant spacing"
> > ValueError: output grid must have constant spacing when using
> > interp='linear'
...
 
> However, my code, when I do something like
> 
> > xi=linspace(-20.1,20.1,100)
> > yi=linspace(-20.1,20.1,200)
> > zi=griddata(x,y,z,xi,yi,interp='linear')
> > CS=plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
> 
> 
> it gives me the above error complaining about "constant spacing".
> 
> Anyone have an idea what I might be missing here? I can turn interp to 'nn'
> and the code works fine, but I'm just curious what about a "constant
> spaced" output grid I don't understand. Is it even possible to create a
> non-constant spaced output grid with linspace?
Looking at the code, it seems to be a floating point issue for
the way linspace works for the particular values you specified.
This should work for you, instead:
 xi=np.arange(-20.1,20.1+1e-14, 40.2/99)
 yi=np.arange(-20.1,20.1+1e-14,40.2/199)
NOTE: neither xi.max() nor yi.max() are "exactly" 20.1, the way
they were with linspace, nor is xi.max() exactly yi.max(). I say
"exactly" (in quotes) because when you type in 20.1, the floating point
number that you get isn't 20.10000000000000000000000000, it's
more like 20.10000000+change, in ipython, run '%precision 20' to
see what I mean.
Either the np.linspace or the mpl code likely needs to change,
because in mpl, the error gets raised when, effectively:
 dx = np.diff(xi)
 dx.max() - dx.min() > np.finfo(xi.dtype).resolution
and same for yi, which is what happens with the values you
provided to linspace, due to the way linspace works.
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

Hi, I am trying to use griddata to interpolate some irregularly spaced data
onto a linspace-created mesh in order to get a temperature plot.
I've been able to follow this example and it's worked perfectly for me:
http://matplotlib.sourceforge.net/examples/pylab_examples/griddata_demo.html
However, when I do my own data I get an error message that says:
>
> Traceback (most recent call last):
> File "make_colormap.py", line 248, in <module>
> zi=griddata(x,y,z,xi,yi,interp='linear')
> File "/usr/lib/pymodules/python2.6/matplotlib/mlab.py", line 2579, in
> griddata
> raise ValueError("output grid must have constant spacing"
> ValueError: output grid must have constant spacing when using
> interp='linear'
Looking into the documentation it seems that this is just suggesting that
the xi,yi grids to be interpolated on have constant spacing. I don't know
if this is supposed to be the SAME constant spacing in xi and yi, but it
appears not to be, since the example above uses the line:
xi = np.linspace(-2.1,2.1,100)
> yi = np.linspace(-2.1,2.1,200)
so one is twice as fine as the other.
However, my code, when I do something like
> xi=linspace(-20.1,20.1,100)
> yi=linspace(-20.1,20.1,200)
> zi=griddata(x,y,z,xi,yi,interp='linear')
> CS=plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
it gives me the above error complaining about "constant spacing".
Anyone have an idea what I might be missing here? I can turn interp to 'nn'
and the code works fine, but I'm just curious what about a "constant
spaced" output grid I don't understand. Is it even possible to create a
non-constant spaced output grid with linspace?
Thanks for the help!
Brad

On 12/19/11 4:47 PM, Stefan Mertl wrote:
> Hi Jeff,
>
> I'm not an expert in coordinate transformation and the usage of proj, so
> I can't exactly tell you if I have all the datum files installed. If you
> could tell me what files could be missing I could search for them.
>
> What makes me wonder, is that you get the results that my
> mpl_toolkits.basemap.pyproj.Proj usage produced. When using some
> conversion tools on the internet like
> http://home.hiwaay.net/~taylorc/toolbox/geodesy/datumtrans/ or
> http://www.uwgb.edu/dutchs/UsefulData/ConvertUTMNoOZ.HTM
> I get the results that my commandline proj produces.
> So I think that something with my pyproj installation is not working.
>
> Regards,
> Stefan.
Stefan: I mis-spoke in my earlier email - the answer I get with pyproj 
is the same as you get with command line proj. What version of basemap 
do you have installed?
-Jeff
>
> Am Montag, den 19.12.2011, 15:51 -0700 schrieb Jeff Whitaker:
>> On 12/19/11 2:23 PM, Stefan Mertl wrote:
>>> Hello,
>>>
>>> I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
>>> lon/lat to UTM coordinate conversion.
>>> I did some tests and noticed that there is a discrepancy between the
>>> mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
>>> output.
>>>
>>> e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
>>> coordinates UTM zone 33 with WGS84 ellipse.
>>> I'm using the following proj4 string for the conversion:
>>> +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
>>>
>>> The output using mpl_toolkits.basemap.pyproj.Proj is:
>>> x: 611458.865; y: 5339596.032
>>>
>>> The proj commandline tool using the same proj4 string gives:
>>> x: 611458.69 y: 5339617.54
>>>
>>> As you can see, the y coordinate differs significantly.
>>>
>>> Here's the code used with the basemap pyproy classes:
>>>
>>> --------------------------------------------------
>>>
>>> from mpl_toolkits.basemap.pyproj import Proj
>>>
>>> # I got the proj string from
>>> # http://spatialreference.org/ref/epsg/32633
>>> myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
>>> +no_defs")
>>>
>>> lat = 48.2
>>> lon = 16.5
>>>
>>> (x,y) = myProj(lon, lat)
>>>
>>> print "x: %.3f; y: %.3f" % (x,y)
>>>
>>> ---------------------------------------------------
>>>
>>> Can somebody explain me this behavior?
>>>
>>> Regards,
>>> Stefan.
>>>
>> Stefan:
>>
>> When I run this test, I get the same answer with both, and it is the
>> same as the answer basemap.pyproj gave you. I suspect you didn't
>> install the extra datum files with your command-line proj distribution.
>>
>> -Jeff
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Write once. Port to many.
>> Get the SDK and tools to simplify cross-platform app development. Create
>> new or port existing apps to sell to consumers worldwide. Explore the
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>> http://p.sf.net/sfu/intel-appdev
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi Jeff,
I'm not an expert in coordinate transformation and the usage of proj, so
I can't exactly tell you if I have all the datum files installed. If you
could tell me what files could be missing I could search for them.
What makes me wonder, is that you get the results that my
mpl_toolkits.basemap.pyproj.Proj usage produced. When using some
conversion tools on the internet like
http://home.hiwaay.net/~taylorc/toolbox/geodesy/datumtrans/ or
http://www.uwgb.edu/dutchs/UsefulData/ConvertUTMNoOZ.HTM
I get the results that my commandline proj produces.
So I think that something with my pyproj installation is not working.
Regards,
 Stefan.
Am Montag, den 19.12.2011, 15:51 -0700 schrieb Jeff Whitaker: 
> On 12/19/11 2:23 PM, Stefan Mertl wrote:
> > Hello,
> >
> > I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
> > lon/lat to UTM coordinate conversion.
> > I did some tests and noticed that there is a discrepancy between the
> > mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
> > output.
> >
> > e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
> > coordinates UTM zone 33 with WGS84 ellipse.
> > I'm using the following proj4 string for the conversion:
> > +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
> >
> > The output using mpl_toolkits.basemap.pyproj.Proj is:
> > x: 611458.865; y: 5339596.032
> >
> > The proj commandline tool using the same proj4 string gives:
> > x: 611458.69 y: 5339617.54
> >
> > As you can see, the y coordinate differs significantly.
> >
> > Here's the code used with the basemap pyproy classes:
> >
> > --------------------------------------------------
> >
> > from mpl_toolkits.basemap.pyproj import Proj
> >
> > # I got the proj string from
> > # http://spatialreference.org/ref/epsg/32633
> > myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
> > +no_defs")
> >
> > lat = 48.2
> > lon = 16.5
> >
> > (x,y) = myProj(lon, lat)
> >
> > print "x: %.3f; y: %.3f" % (x,y)
> >
> > ---------------------------------------------------
> >
> > Can somebody explain me this behavior?
> >
> > Regards,
> > Stefan.
> >
> Stefan:
> 
> When I run this test, I get the same answer with both, and it is the 
> same as the answer basemap.pyproj gave you. I suspect you didn't 
> install the extra datum files with your command-line proj distribution.
> 
> -Jeff
> 

On 12/19/11 2:23 PM, Stefan Mertl wrote:
> Hello,
>
> I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
> lon/lat to UTM coordinate conversion.
> I did some tests and noticed that there is a discrepancy between the
> mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
> output.
>
> e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
> coordinates UTM zone 33 with WGS84 ellipse.
> I'm using the following proj4 string for the conversion:
> +proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
>
> The output using mpl_toolkits.basemap.pyproj.Proj is:
> x: 611458.865; y: 5339596.032
>
> The proj commandline tool using the same proj4 string gives:
> x: 611458.69 y: 5339617.54
>
> As you can see, the y coordinate differs significantly.
>
> Here's the code used with the basemap pyproy classes:
>
> --------------------------------------------------
>
> from mpl_toolkits.basemap.pyproj import Proj
>
> # I got the proj string from
> # http://spatialreference.org/ref/epsg/32633
> myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
> +no_defs")
>
> lat = 48.2
> lon = 16.5
>
> (x,y) = myProj(lon, lat)
>
> print "x: %.3f; y: %.3f" % (x,y)
>
> ---------------------------------------------------
>
> Can somebody explain me this behavior?
>
> Regards,
> Stefan.
>
Stefan:
When I run this test, I get the same answer with both, and it is the 
same as the answer basemap.pyproj gave you. I suspect you didn't 
install the extra datum files with your command-line proj distribution.
-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-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hello,
I'm starting to use the mpl_toolkits.basemap.pyproj.Proj class to do
lon/lat to UTM coordinate conversion.
I did some tests and noticed that there is a discrepancy between the
mpl_toolkits.basemap.pyproj.Proj output and the proj commandline tool
output.
e.g.: I'm converting the coordinates lat=48.2; lon=16.5 to UTM
coordinates UTM zone 33 with WGS84 ellipse.
I'm using the following proj4 string for the conversion:
+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
The output using mpl_toolkits.basemap.pyproj.Proj is:
x: 611458.865; y: 5339596.032
The proj commandline tool using the same proj4 string gives:
x: 611458.69 y: 5339617.54
As you can see, the y coordinate differs significantly.
Here's the code used with the basemap pyproy classes:
--------------------------------------------------
from mpl_toolkits.basemap.pyproj import Proj
# I got the proj string from 
# http://spatialreference.org/ref/epsg/32633
myProj = Proj("+proj=utm +zone=33 +ellps=WGS84 +datum=WGS84 +units=m
+no_defs")
lat = 48.2
lon = 16.5
(x,y) = myProj(lon, lat)
print "x: %.3f; y: %.3f" % (x,y)
---------------------------------------------------
Can somebody explain me this behavior?
Regards,
 Stefan.

Hi,
It seems that patheffects are not supported for Line2D objects currently
- only for Text and Patch objects. Is there any fundamental reason they
couldn't be extended to support Line2D objects? I'm interested in this
because I draw grid lines for some hammer projection plots and those
lines are Line2D objects. For certain images, it'd be nicer to have the
grid lines use patheffects so that any color of the image would still
allow the grid line to show clearly.
Jon
-- 
______________________________________________________________
Jonathan D. Slavin Harvard-Smithsonian CfA
js...@cf... 60 Garden Street, MS 83
phone: (617) 496-7981 Cambridge, MA 02138-1516
 cell: (781) 363-0035 USA
______________________________________________________________

It's definitely possible. Each version of Python installed has its own 
set of Python packages, so it would just be a matter of installing 
matplotlib in both places.
Mike
On 12/19/2011 09:38 AM, Ignas Anikevicius wrote:
> Hello list,
>
> I was wondering, if it was possible to have Py2 *and* Py3 versions of
> MPL working on the same machine at the same time? I am asking because
> I would like to make a switch to Py3 on all my work, but at the same
> time I want to be able to run old scripts, which I might need in the
> future.
>
> Maybe somebody knows, if it is possible to do the same with IPython?
>
> Thanks in advance,
> Ignas A.
>

Hello list,
I was wondering, if it was possible to have Py2 *and* Py3 versions of
MPL working on the same machine at the same time? I am asking because
I would like to make a switch to Py3 on all my work, but at the same
time I want to be able to run old scripts, which I might need in the
future.
Maybe somebody knows, if it is possible to do the same with IPython?
Thanks in advance,
Ignas A.
-- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?

Hi all,
on behalf of the IPython development team, I'm thrilled to announce,
after an intense 4 1/2 months of work, the official release of IPython
0.12.
This is a very important release for IPython, for several reasons.
First and foremost, we have a major new feature, our interactive
web-based notebook, that has been in our sights for a very long time.
We tried to build one years ago (with WX) as a Google SoC project in
2005, had other prototypes later on, but things never quite worked.
Finally the refactoring effort started two years ago, the
communications architecture we built in 2010, and the advances of
modern browsers, gave us all the necessary pieces.
With this foundation in place, while part of the team worked on the
0.11 release, Brian Granger had already started quietly building the
web notebook, which we demoed in early-alpha mode at the SciPy 2011
conference (http://www.archive.org/details/Wednesday-203-6-IpythonANewArchitectureForInteractiveAndParallel).
 By the EuroScipy conference in August we had merged Brian's amazing
effort into our master branch, and after that multiple people (old and
new) jumped in to make all kinds of improvements, leaving us today
with something that is an excellent foundation. It's still the first
release of the notebook, and as such we know it has a number of rough
edges, but several of us have been using it as a daily research tool
for the last few months. Do not hesitate to file issues for any
problems you encounter with it, and we even have an 'open issue' for
general discussion of ideas and features for the notebook at:
https://github.com/ipython/ipython/issues/977.
Furthermore, it is clear that our big refactoring work, combined with
the amazing facilities at Github, are paying off. The 0.11 series was
a major amount of work, with 511 issues closed over almost two years.
But that pales in comparison to this cycle: in only 4 1/2 months we
closed 515 issues, with 50% being Pull Requests. And very importantly,
our list of contributors includes many new faces (see the credits
section in our release notes for full details), which is the best
thing that can happen to an open source project.
We hope you will find the new features (the notebook isn't the only
one! see below) compelling, and that many more will not only use
IPython but will join the project; there's plenty to do and now there
are tasks for many different skill sets (web, javascript, gui work,
low-level networking, parallel machinery, console apps, etc).
*Downloads*
Download links and instructions are at: http://ipython.org/download.html
And IPython is also on PyPI: http://pypi.python.org/pypi/ipython
Those contain a built version of the HTML docs; if you want pure
source downloads with no docs, those are available on github:
Tarball: https://github.com/ipython/ipython/tarball/rel-0.12
Zipball: https://github.com/ipython/ipython/zipball/rel-0.12
* Features *
Here is a quick listing of the major new features:
- An interactive browser-based Notebook with rich media support
- Two-process terminal console
- Tabbed QtConsole
- Full Python 3 compatibility
- Standalone Kernel
- PyPy support
And many more...
We closed over 500 tickets, merged over 200 pull requests, and more
than 45 people contributed commits for the final release.
Please see our release notes for the full details on everything about
this release:
http://ipython.org/ipython-doc/stable/whatsnew/version0.12.html
* IPython tutorial at PyCon 2012 *
Those of you attending (or planning on it) PyCon 2012 in Santa Clara,
CA, may be interested in attending a hands-on tutorial we will be
presenting on the many faces of IPython. See
https://us.pycon.org/2012/schedule/presentation/121/ for full details.
* Errata *
This was caught by Matthias Bussionnier's (one of our great new
contributors) sharp eyes while I was writing these release notes: In
the example notebook called display_protocol, the first cell starts
with:
from IPython.lib.pylabtools import print_figure
which should instead be:
from IPython.core.pylabtools import print_figure
This has already been fixed on master, but since the final 0.12 files
have been uploaded to github and PyPI, we'll let them be.
As usual, if you find any other problem, please file a ticket --or
even better, a pull request fixing it-- on our github issues site
(https://github.com/ipython/ipython/issues/).
Many thanks to all who contributed!
Fernando, on behalf of the IPython development team.
http://ipython.org

Since the upgrade to 1.1 my py2exe distribution needs to include Tkinter, Tkconstants and matplotlib.backends.backend_tkagg (which I don't need, but take a lot of place)
if Tkinter is not included, since 1.1 upgrade, I obtain the messages below when distribution is executed :
Traceback (most recent call last): File "shyreg.py", line 33, in <module> File "matplotlib\pyplot.pyo", line 95, in <module> File "matplotlib\backends\__init__.pyo", line 25, in pylab_setup File "matplotlib\backends\backend_tkagg.pyo", line 8, in <module>ImportError: No module named Tkinter
Traceback (most recent call last): File "shyreg.py", line 33, in <module> File "matplotlib\pyplot.pyo", line 95, in <module> File "matplotlib\backends\__init__.pyo", line 25, in pylab_setup File "matplotlib\backends\backend_tkagg.pyo", line 8, in <module> File "Tkinter.pyo", line 43, in <module>ImportError: No module named Tkconstants
Traceback (most recent call last): File "shyreg.py", line 33, in <module> File "matplotlib\pyplot.pyo", line 95, in <module> File "matplotlib\backends\__init__.pyo", line 25, in pylab_setupImportError: No module named backend_tkagg
Any advise to reduce the needed modules to minimum ?
Loïc
 		 	 		 

On 12/18/2011 01:13 PM, Wes McKinney wrote:
> This is a new one on me and extremely distressing:
>
> If I plot 139 dates versus 139 values, everything is OK
>
> In [40]: stamp = datetime.today()
>
> In [44]: from datetime import timedelta
>
> In [45]: inc = timedelta(1)
>
> In [46]: stamps = [stamp + inc * i for i in xrange(139)]
>
> In [47]: values = np.random.randn(139)
>
> In [48]: plt.plot(stamps, values)
> Out[48]: [<matplotlib.lines.Line2D at 0x6ed0e50>]
>
> See plot 1 attached
>
> However, if I increase it to 140 (!), all hell breaks loose:
>
> In [49]: stamps = [stamp + inc * i for i in xrange(140)]
>
> In [50]: values = np.random.randn(140)
>
> In [51]: plt.plot(stamps, values)
> Out[51]: [<matplotlib.lines.Line2D at 0x73a21d0>]
>
> see plot 2
>
> It seems to get ahold of itself at 153 dates (but not 152!). I tested
> this both with git master and v1.1.0. I don't even know what to say.
Confirmed. The AutoDateLocator is using an RRuleLocator which is 
cranking out a tick for every day. I suspect the problem is in 
AutoDateLocator.get_locator(); it is not finding what it is looking for, 
so it is falling back on a default. I can't look into it any time soon, 
so I hope someone else can; I'm not familiar with this code.
Eric
>
> thanks,
> Wes

This is a new one on me and extremely distressing:
If I plot 139 dates versus 139 values, everything is OK
In [40]: stamp = datetime.today()
In [44]: from datetime import timedelta
In [45]: inc = timedelta(1)
In [46]: stamps = [stamp + inc * i for i in xrange(139)]
In [47]: values = np.random.randn(139)
In [48]: plt.plot(stamps, values)
Out[48]: [<matplotlib.lines.Line2D at 0x6ed0e50>]
See plot 1 attached
However, if I increase it to 140 (!), all hell breaks loose:
In [49]: stamps = [stamp + inc * i for i in xrange(140)]
In [50]: values = np.random.randn(140)
In [51]: plt.plot(stamps, values)
Out[51]: [<matplotlib.lines.Line2D at 0x73a21d0>]
see plot 2
It seems to get ahold of itself at 153 dates (but not 152!). I tested
this both with git master and v1.1.0. I don't even know what to say.
thanks,
Wes