matplotlib

On Sep 29, 2010, at 1:06 PM, Jeremy Lounds wrote:

> Hello again,
> 
> I am not sure if this is a matplotlib question, or a basemap one. The
> sample code I found on Google for this either broke my script or
> didn't change the end result.
> 
> I am attempting to turn the border (frame?) off altogether. Here is
> the script, with some sections kept out for brevity:


I'm assuming you're talking about turning off the frame around each axes (but maybe you're talking about something else?). The "frameon" attribute in your example code alters the background of the figure canvas, not the borders surrounding each axes. 

There's probably a shorter way, but I have a small function that I use to turn off the frame or border around an axes.

def clear_frame(ax=None):
    if ax is None:
        ax = plt.gca()
    ax.xaxis.set_visible(False)
    ax.yaxis.set_visible(False)
    for spine in ax.spines.itervalues():
        spine.set_visible(False)

Best,
-T

On Wed, Sep 29, 2010 at 1:21 PM, Tony S Yu <tsyu80@...> wrote:
>
> On Sep 29, 2010, at 1:06 PM, Jeremy Lounds wrote:
>
>> I am attempting to turn the border (frame?) off altogether. Here is
>> the script, with some sections kept out for brevity:
>
>
> I'm assuming you're talking about turning off the frame around each axes (but maybe you're talking about something else?). The "frameon" attribute in your example code alters the background of the figure canvas, not the borders surrounding each axes.
>
> There's probably a shorter way, but I have a small function that I use to turn off the frame or border around an axes.
>
> def clear_frame(ax=None):
>    if ax is None:
>        ax = plt.gca()
>    ax.xaxis.set_visible(False)
>    ax.yaxis.set_visible(False)
>    for spine in ax.spines.itervalues():
>        spine.set_visible(False)
>
> Best,
> -T

Hi Tony,

Thanks, that works pretty good!

However... it seems that "drawcoastlines" creates a border if I am not
"zoomed out" far enough. (i.e., the coastline is out of bounds).

Do you know how I could turn that off?

Thanks again!

~ Jeremy

On Sep 29, 2010, at 2:00 PM, Jeremy Lounds wrote:

> On Wed, Sep 29, 2010 at 1:21 PM, Tony S Yu <tsyu80@...> wrote:
>> 
>> On Sep 29, 2010, at 1:06 PM, Jeremy Lounds wrote:
>> 
>>> I am attempting to turn the border (frame?) off altogether. Here is
>>> the script, with some sections kept out for brevity:
>> 
>> 
>> I'm assuming you're talking about turning off the frame around each axes (but maybe you're talking about something else?). The "frameon" attribute in your example code alters the background of the figure canvas, not the borders surrounding each axes.
>> 
>> There's probably a shorter way, but I have a small function that I use to turn off the frame or border around an axes.
>> 
>> def clear_frame(ax=None):
>>    if ax is None:
>>        ax = plt.gca()
>>    ax.xaxis.set_visible(False)
>>    ax.yaxis.set_visible(False)
>>    for spine in ax.spines.itervalues():
>>        spine.set_visible(False)
>> 
>> Best,
>> -T
> 
> Hi Tony,
> 
> Thanks, that works pretty good!
> 
> However... it seems that "drawcoastlines" creates a border if I am not
> "zoomed out" far enough. (i.e., the coastline is out of bounds).
> 
> Do you know how I could turn that off?
> 
> Thanks again!
> 
> ~ Jeremy

I'm glad that worked for you. Unfortunately, I don't use basemap, so I can't really help with this additional complication. I'm sure someone else on the list will be able to help you out, though.

Best,
-Tony

On 09/27/2010 03:46 AM, Dieter Weber wrote:
> Hi,
> I'm using matplotlib embedded in my wxpython application and needed to
> give users a quick way to relimit a figure, for example after removing a
> line from a plot. Therefore I added a button to the toolbar. Do you
> think it would make sense to include this in matplotlib by default?

I don't think it would.  The standard toolbar is for typical interactive 
use, where I don't think the relimit functionality is needed often 
enough to justify having its own button--if at all. Better to keep that 
toolbar simple.

Eric

> Appended you find modifications of backend_bases.py and
> backends/backend_wx.py as well as a draft for a symbol.
>
> Greetings,
> Dieter
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Mon, Sep 27, 2010 at 1:27 PM, Eric Firing <efiring@...> wrote:

> On 09/27/2010 03:46 AM, Dieter Weber wrote:
> > Hi,
> > I'm using matplotlib embedded in my wxpython application and needed to
> > give users a quick way to relimit a figure, for example after removing a
> > line from a plot. Therefore I added a button to the toolbar. Do you
> > think it would make sense to include this in matplotlib by default?
>
> I don't think it would.  The standard toolbar is for typical interactive
> use, where I don't think the relimit functionality is needed often
> enough to justify having its own button--if at all. Better to keep that
> toolbar simple.
>
> Eric
>
>
Just playing devil's advocate here...

Considering how we can now have multiple show() calls and with the upcoming
ipython looking more and more spiffy, could there be a future use case for
this toolbar button?

On the other hand, how would the inclusion of this button impact users of
other interactive scripts that have added their own buttons?  I mean,
planning for the future, can it be definitively said that matplotlib will
never add anymore toolbar buttons?  Could developers rely on that real
estate not being taken over by rule of "eminent domain", if you will?

Ben Root

On 09/27/2010 08:35 AM, Benjamin Root wrote:
> On Mon, Sep 27, 2010 at 1:27 PM, Eric Firing <efiring@...
> <mailto:efiring@...>> wrote:
>
>     On 09/27/2010 03:46 AM, Dieter Weber wrote:
>      > Hi,
>      > I'm using matplotlib embedded in my wxpython application and
>     needed to
>      > give users a quick way to relimit a figure, for example after
>     removing a
>      > line from a plot. Therefore I added a button to the toolbar. Do you
>      > think it would make sense to include this in matplotlib by default?
>
>     I don't think it would.  The standard toolbar is for typical interactive
>     use, where I don't think the relimit functionality is needed often
>     enough to justify having its own button--if at all. Better to keep that
>     toolbar simple.
>
>     Eric
>
>
> Just playing devil's advocate here...
>
> Considering how we can now have multiple show() calls and with the
> upcoming ipython looking more and more spiffy, could there be a future
> use case for this toolbar button?
>
> On the other hand, how would the inclusion of this button impact users
> of other interactive scripts that have added their own buttons?  I mean,
> planning for the future, can it be definitively said that matplotlib
> will never add anymore toolbar buttons?  Could developers rely on that
> real estate not being taken over by rule of "eminent domain", if you will?
>
> Ben Root
>

Ben,

I don't understand either of your questions.  What's the point?

Eric

On Mon, Sep 27, 2010 at 1:47 PM, Eric Firing <efiring@...> wrote:

> On 09/27/2010 08:35 AM, Benjamin Root wrote:
> > On Mon, Sep 27, 2010 at 1:27 PM, Eric Firing <efiring@...
> > <mailto:efiring@...>> wrote:
> >
> >     On 09/27/2010 03:46 AM, Dieter Weber wrote:
> >      > Hi,
> >      > I'm using matplotlib embedded in my wxpython application and
> >     needed to
> >      > give users a quick way to relimit a figure, for example after
> >     removing a
> >      > line from a plot. Therefore I added a button to the toolbar. Do
> you
> >      > think it would make sense to include this in matplotlib by
> default?
> >
> >     I don't think it would.  The standard toolbar is for typical
> interactive
> >     use, where I don't think the relimit functionality is needed often
> >     enough to justify having its own button--if at all. Better to keep
> that
> >     toolbar simple.
> >
> >     Eric
> >
> >
> > Just playing devil's advocate here...
> >
> > Considering how we can now have multiple show() calls and with the
> > upcoming ipython looking more and more spiffy, could there be a future
> > use case for this toolbar button?
> >
> > On the other hand, how would the inclusion of this button impact users
> > of other interactive scripts that have added their own buttons?  I mean,
> > planning for the future, can it be definitively said that matplotlib
> > will never add anymore toolbar buttons?  Could developers rely on that
> > real estate not being taken over by rule of "eminent domain", if you
> will?
> >
> > Ben Root
> >
>
> Ben,
>
> I don't understand either of your questions.  What's the point?
>
> Eric
>
>
First, I am asking if there are no use-cases for this button in the future
with the advent of an improved ipython environment?  In other words, more
people may use matplotlib+ipython like a regular MATLAB environment.  Could
this button be a useful feature later?

Second, irregardless of whether this button is included or not, there have
been app developers who have added buttons to the toolbar for their own
use.  Can these developers count on that real estate to always be free?  Can
we definitively say that matplotlib will never have more buttons added to
its default toolbar?

Does that make more sense?

Ben Root

On Mon, Sep 27, 2010 at 1:57 PM, Benjamin Root <ben.root@...> wrote:

> Second, irregardless of whether this button is included or not, there have
> been app developers who have added buttons to the toolbar for their own
> use.  Can these developers count on that real estate to always be free?  Can
> we definitively say that matplotlib will never have more buttons added to
> its default toolbar?

On a different but related topic, I think it would definitely be
desirable to support customizable toolbars, so users could easily add
their own buttons, remove buttons, connect them to their own
callbacks, etc...  That would take a bit of work to handle this across
GUIS and platforms with icon specifications, etc, but would certainly
be useful.  Adding one more button for a somewhat specialized use case
is definitely not a good idea, as only a tiny faction of users
actually modify data in objects in place.

A related button to autoscale y after zoom based on current x limits
would be somewhat handy in my own experience, but again, I'd rather
have customizable toolbars with a stock functionality that we could
add or remove as desired.

JDH

On Mon, Sep 27, 2010 at 8:57 PM, Benjamin Root <ben.root@...> wrote:

> On Mon, Sep 27, 2010 at 1:47 PM, Eric Firing <efiring@...> wrote:
>
>> On 09/27/2010 08:35 AM, Benjamin Root wrote:
>> > On Mon, Sep 27, 2010 at 1:27 PM, Eric Firing <efiring@...
>> > <mailto:efiring@...>> wrote:
>> >
>> >     On 09/27/2010 03:46 AM, Dieter Weber wrote:
>> >      > Hi,
>> >      > I'm using matplotlib embedded in my wxpython application and
>> >     needed to
>> >      > give users a quick way to relimit a figure, for example after
>> >     removing a
>> >      > line from a plot. Therefore I added a button to the toolbar. Do
>> you
>> >      > think it would make sense to include this in matplotlib by
>> default?
>> >
>> >     I don't think it would.  The standard toolbar is for typical
>> interactive
>> >     use, where I don't think the relimit functionality is needed often
>> >     enough to justify having its own button--if at all. Better to keep
>> that
>> >     toolbar simple.
>> >
>> >     Eric
>> >
>> >
>> > Just playing devil's advocate here...
>> >
>> > Considering how we can now have multiple show() calls and with the
>> > upcoming ipython looking more and more spiffy, could there be a future
>> > use case for this toolbar button?
>> >
>> > On the other hand, how would the inclusion of this button impact users
>> > of other interactive scripts that have added their own buttons?  I mean,
>> > planning for the future, can it be definitively said that matplotlib
>> > will never add anymore toolbar buttons?  Could developers rely on that
>> > real estate not being taken over by rule of "eminent domain", if you
>> will?
>> >
>> > Ben Root
>> >
>>
>> Ben,
>>
>> I don't understand either of your questions.  What's the point?
>>
>> Eric
>>
>>
> First, I am asking if there are no use-cases for this button in the future
> with the advent of an improved ipython environment?  In other words, more
> people may use matplotlib+ipython like a regular MATLAB environment.  Could
> this button be a useful feature later?
>
> Second, irregardless of whether this button is included or not, there have
> been app developers who have added buttons to the toolbar for their own
> use.  Can these developers count on that real estate to always be free?  Can
> we definitively say that matplotlib will never have more buttons added to
> its default toolbar?
>
> Does that make more sense?
>
>
A feature-set that MATLAB has and is missing from matplotlib is editing the
plot via the GUI. You can actually remove lines from the plot without typing
anything in the interpreter. I think it is via a line properties menu, but
maybe you can also get there by right-clicking the line and choosing delete
(can't recall, I'll have to check).
If/when we add support for such things in mpl, the relimit button would
become much more useful.

Until we have that, I think JDH's idea for cross-GUI configurable toolbars
is a better target to aim for.

  AA

a few comments:

One possible limitation of the proposed relim code is that it doesn't take
into account whether the lines are set visible or not.  But otherwise it is
a useful function for interactive use, which incidentally is the way I use
matplotlib the most. 

Is there any reason why matplotlib doesn't have an optional additional
menubar ? You could fit far more commands than in a toolbar. 

btw as demonstrated by the qt4_editor it is not difficult to implement a
line properties dialog in matplotlib.


A feature-set that MATLAB has and is missing from matplotlib is editing the
plot via the GUI. You can actually remove lines from the plot without typing
anything in the interpreter. I think it is via a line properties menu, but
maybe you can also get there by right-clicking the line and choosing delete
(can't recall, I'll have to check).
If/when we add support for such things in mpl, the relimit button would
become much more useful.

Until we have that, I think JDH's idea for cross-GUI configurable toolbars
is a better target to aim for.

  AA


-- 
View this message in context: http://old.nabble.com/Toolbar-button-for-relimiting-tp29819182p29823872.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Am Montag, den 27.09.2010, 15:42 -0700 schrieb butterw:
> a few comments:
> 
> One possible limitation of the proposed relim code is that it doesn't take
> into account whether the lines are set visible or not.  But otherwise it is
> a useful function for interactive use, which incidentally is the way I use
> matplotlib the most. 
> 
> Is there any reason why matplotlib doesn't have an optional additional
> menubar ? You could fit far more commands than in a toolbar. 
> 
> btw as demonstrated by the qt4_editor it is not difficult to implement a
> line properties dialog in matplotlib.
> 
> 
> A feature-set that MATLAB has and is missing from matplotlib is editing the
> plot via the GUI. You can actually remove lines from the plot without typing
> anything in the interpreter. I think it is via a line properties menu, but
> maybe you can also get there by right-clicking the line and choosing delete
> (can't recall, I'll have to check).
> If/when we add support for such things in mpl, the relimit button would
> become much more useful.
> 
> Until we have that, I think JDH's idea for cross-GUI configurable toolbars
> is a better target to aim for.
> 
>   AA

Here are my reasons to add the button, just to add to the discussion:
I've written two applications so far that embed matplotlib, and in both
I felt that the relimit button was missing: In one, there are always
lines added and removed and I often need to reset the plot limits, and
in the second one I do in fact change the line's data so that I want to
relimit occasionally. For that last application it is also important
that the zoom level remains the same, unless I really want to change it,
therefore the button and no automatic relimiting when lines are removed
or data are changed. In both applications the toolbar is most useful for
navigation in the plots, so please don't forget the people who embed
matplotlib when you design the toolbar... :-)

A menu would be great, it could for example be used in cases where the
toolbar would be out of place. For embedding, it would not be so
important to have a cross-platform interface for customization: After
all, you're stuck with one toolkit anyway... As far as I can tell about
wxpython, it is no problem to add anything to the toolbar afterwards.
Maybe one could implement a "feature bitmap" in the constructor to turn
specific buttons on or off.

I'm just wondering if there are use cases for customization during
interactive use, where it should definitely be cross-platform.

Greetings,
Dieter

> Here are my reasons to add the button, just to add to the discussion:
> I've written two applications so far that embed matplotlib, and in both
> I felt that the relimit button was missing: In one, there are always
> lines added and removed and I often need to reset the plot limits, and
> in the second one I do in fact change the line's data so that I want to
> relimit occasionally. For that last application it is also important
> that the zoom level remains the same, unless I really want to change it,
> therefore the button and no automatic relimiting when lines are removed
> or data are changed. In both applications the toolbar is most useful for
> navigation in the plots, so please don't forget the people who embed
> matplotlib when you design the toolbar... :-)

If you are embedding mpl, it is easy to design a custom toolbar.  Eg, see

http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_wx4.html

JDH

On Fri, Sep 24, 2010 at 4:27 PM, Jeremy Lounds <lounds@...> wrote:

> Hello,
>
> Sorry, its me again! I am not sure where else to ask this, so please
> bear with me.
>
> Does anyone know of a tutorial or source on how I could get county
> boundaries ready to be plotted on my basemap output? I have
> "drawstates" working wonderfully, and need something like
> "drawcounties"
>
> Thanks in advance!
>
> ~ Jeremy
>
>
Jeremy,

If you have access to the shapefile for county boundaries, you can call
basemap's readshapefile() function to draw the counties.  You can specify
line properties just like you would for a call to plotting the state
boundaries.

As a matter of fact, drawstates() is, essentially, a call to
readshapefile(), but it refers to a file that came packaged with basemap for
convenience.

I hope that helps,
Ben Root

Thanks, I was able to find the files I needed from here:

http://www.census.gov/geo/www/cob/co2000.html#shp

~ Jeremy


On Fri, Sep 24, 2010 at 6:13 PM, Benjamin Root <ben.root@...> wrote:
> On Fri, Sep 24, 2010 at 4:27 PM, Jeremy Lounds <lounds@...> wrote:
>>
>> Hello,
>>
>> Sorry, its me again! I am not sure where else to ask this, so please
>> bear with me.
>>
>> Does anyone know of a tutorial or source on how I could get county
>> boundaries ready to be plotted on my basemap output? I have
>> "drawstates" working wonderfully, and need something like
>> "drawcounties"
>>
>> Thanks in advance!
>>
>> ~ Jeremy
>>
>
> Jeremy,
>
> If you have access to the shapefile for county boundaries, you can call
> basemap's readshapefile() function to draw the counties.  You can specify
> line properties just like you would for a call to plotting the state
> boundaries.
>
> As a matter of fact, drawstates() is, essentially, a call to
> readshapefile(), but it refers to a file that came packaged with basemap for
> convenience.
>
> I hope that helps,
> Ben Root
>
>

On Fri, Sep 24, 2010 at 7:51 AM, Jeremy Lounds <lounds@...> wrote:

> Hi Ben,
>
> I am running 0.98.5.2, so it should be good, right? Do you think I should
> try upgrading to 1.0.0?
>
> Thanks so much,
>
> Jeremy
>
>
Jeremy,

Version 0.98.x is relatively old (in terms of code maturity).  I don't know
when .get_autoscalex_on() came about, but there have been plenty of other
improvements since that version that it would definitely be worth your while
to update to version 1.0.0.

Ben Root

On Wed, Sep 22, 2010 at 2:15 PM, Jeremy Lounds <lounds@...> wrote:
> I have another question for the group...
>
> I saw in the archives someone else who was getting the error I am now
> running in to now. He said he solved it by recompiling from sources. I
> was wondering what version of Python is optimal for matplotlib and
> basemap?

What platform are you on -- compiling from source is particularly easy
on linux.  I use the stock python, and then get all the dependencies
for all the packages I want t build from source:

> sudo apt-get build_dep numpy scipy matplotlib mayavi traits cython sympy

Then check out the source from the version control repositories (svn/git/hg) and

> python setup.py install --prefix=~/whatever

This will almost always work, out of the box, and some version of this
is what most of the serious users do.

Then if you encounter a runtime problem or a real bug, report it to
the mailing list, get the bug fixed, svn up and reinstall.

Other platforms (win32, osx) are possible but much harder.

JDH

OK, was able to narrow thinks down:
actually it looks like
figure.canvas.mpl_connect('pick_event', function)
does not connect the "function" if it is a class method (...?)
In attachment you will find two files illustrating this:
buggy_pick.py and buggy_pick2.py
Both work nicely with matplotlib 0.93
With matplotlib 1.0 buggy_pick.py does not work while buggy_pick2.py 
does work.
The only difference is in the PickFig class...

Is it really a bug or I'm doing something wrong ?

Any workaround would be welcome.

Thx,

David

PS. Is it better to discuss this on users or devel list ?

Le 23/09/10 14:20, David Trémouilles a écrit :
> Hello,
>
> My pyqt4 app use the matplotlib pick event.
> Cliking on a point in the graph triggers an event
> but with matplotlib 1.0 it does not work anymore
> while it was working fine with 0.93.
> (Matplotlib version is only what was changed)
>
> Any one who might be aware of a matplotlib change that could have
> induce that issue ?
> Any idea/help on where I should look for and how to fix this?
>
> Thanks in advance,
>
> David