matplotlib-users Mailing List for matplotlib

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