matplotlib-users Mailing List for matplotlib

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: Mon, 19 Dec 2011 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: Tue, 20 Dec 2011 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: Mon, 19 Dec 2011 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: Mon, 19 Dec 2011 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: Mon, 19 Dec 2011 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