[matplotlib-devel] Basemap.resolution

[Stephane Raynaud]

Hi,

how about adding the possibility to give a Basemap instance to the
resolution parameter when creating a new Basemap object, and to
directly set some of its attributes (like coastsegs, cntrysegs, etc)
thus preventing from computing them?
It may be interesting when plotting several equavalent maps with fine
resolution.

It's easy to do it manually once you now all needed attributes, but it
would be better to have it natively integrated.


-- 
Stephane Raynaud

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] plotting a series of 3D points and, picker=True and 3D

[Ondrej Certik]

On Jan 31, 2008 11:35 PM, Johann Cohen-Tanugi <[EMAIL PROTECTED]> wrote:
> Actually, it seems that the following thread is also relevant to this
> issue : [matplotlib-devel] merging sympy plotting stuff with matplotlib
> 

Yes, but the conclusion is that someone needs to sit down and
implement the 3D stuff, but we seem quite busy, certainly I am.

I am also very interested in extracting the latex rendering engine
into a separate (pure python) package, but also don't have time for
this anytime soon.

Ondrej

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Basemap.resolution

[Jeff Whitaker]

Stephane Raynaud wrote:
> Hi,
>
> how about adding the possibility to give a Basemap instance to the
> resolution parameter when creating a new Basemap object, and to
> directly set some of its attributes (like coastsegs, cntrysegs, etc)
> thus preventing from computing them?
> It may be interesting when plotting several equavalent maps with fine
> resolution.
>
> It's easy to do it manually once you now all needed attributes, but it
> would be better to have it natively integrated.
>
>
>   
Stephane:  The boundary datasets associated with one Basemap instance 
cannot be used with another (at least not in general).  The coordinates 
of the boundaries are transformed to map projection coordinates, and 
clipped to the map projection region.  So, if you have been doing this 
successfully, you've been lucky. 

However, you can and should reuse Basemap instances, to make multiple 
plots on the same map projection region.  You can even pickle them, to 
reuse in other scripts.

-Jeff

-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC  R/PSD1FAX   : (303)497-6449
325 BroadwayBoulder, CO, USA 80305-3328


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[John Hunter]

On Feb 2, 2008 8:48 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:

> Here is the new patch. I added visual feedback when accumulating points.
> I hope the docstrings are clear.

Great -- thanks again.  I applied this patch and created a new example
ginput_demo.py

Tested on GTKAgg and TkAgg on my system, and looks good so far.

JDH

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[John Hunter]

On Feb 5, 2008 3:58 PM, John Hunter <[EMAIL PROTECTED]> wrote:
> On Feb 2, 2008 8:48 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
>
> > Here is the new patch. I added visual feedback when accumulating points.
> > I hope the docstrings are clear.
>
> Great -- thanks again.  I applied this patch and created a new example
> ginput_demo.py

Jack replied to me offlist so I am going to paste in his post below.
Perhaps you and Gael can consult on the ideal functionality of ginput
vis-a-vis optional line segment drawing, etc...



FromJack Sankey <[EMAIL PROTECTED]>
to  John Hunter <[EMAIL PROTECTED]>,
dateFeb 5, 2008 4:02 PM
subject Re: [matplotlib-devel] ginput: blocking call for mouse input
mailed-by   gmail.com



Woa, it's working on GTKAgg using wx.Yield()? You must have added some voodoo :)

Also, my version of GaelInput has seemed to stop evolving. This
version has the option to draw lines between clicks, which I use a
lot. Also, the default timeout is 0 now, since you can always
right-click to abort.

-Jack



class GaelInput(object):
   """
   Class that create a callable object to retrieve mouse click in a
   blocking way, a la MatLab. Based on Gael Varoquaux's almost-working
   object. Thanks Gael! I've wanted to get this working for years!

   -Jack
   """

   debug  = False
   cid= None   # event connection object
   clicks = [] # list of click coordinates
   n  = 1  # number of clicks we're waiting for
   lines  = False   # if we should draw the lines

   def on_click(self, event):
   """
   Event handler that will be passed to the current figure to
   retrieve clicks.
   """

   # write the debug information if we're supposed to
   if self.debug: print "button "+str(event.button)+":
"+str(event.xdata)+", "+str(event.ydata)

   # if this event's a right click we're done
   if event.button == 3:
   self.done = True
   return

   # if it's a valid click (and this isn't an extra event
   # in the queue), append the coordinates to the list
   if event.inaxes and not self.done:
   self.clicks.append([event.xdata, event.ydata])

   # now if we're supposed to draw lines, do so
   if self.lines and len(self.clicks) > 1:
   event.inaxes.plot([self.clicks[-1][0], self.clicks[-2][0]],
 [self.clicks[-1][1], self.clicks[-2][1]],
 color='w', linewidth=2.0,
scalex=False, scaley=False)
   event.inaxes.plot([self.clicks[-1][0], self.clicks[-2][0]],
 [self.clicks[-1][1], self.clicks[-2][1]],
 color='k', linewidth=1.0,
scalex=False, scaley=False)
   _pylab.draw()

   # if we have n data points, we're done
   if len(self.clicks) >= self.n and self.n is not 0:
   self.done = True
   return


   def __call__(self, n=1, timeout=0, debug=False, lines=False):
   """
   Blocking call to retrieve n coordinate pairs through mouse clicks.

   n=1 number of clicks to collect. Set n=0 to keep collecting
   points until you click with the right mouse button.

   timeout=30  maximum number of seconds to wait for clicks
before giving up.
   timeout=0 to disable

   debug=False show each click event coordinates

   lines=False draw lines between clicks
   """

   # just for printing the coordinates
   self.debug = debug

   # for drawing lines
   self.lines = lines

   # connect the click events to the on_click function call
   self.cid = _pylab.connect('button_press_event', self.on_click)

   # initialize the list of click coordinates
   self.clicks = []

   # wait for n clicks
   self.n= n
   self.done = False
   t = 0.0
   while not self.done:
   # key step: yield the processor to other threads
   _wx.Yield();
   _time.sleep(0.1)

   # check for a timeout
   t += 0.1
   if timeout and t > timeout: print "ginput timeout"; break;

   # All done! Disconnect the event and return what we have
   _pylab.disconnect(self.cid)
   self.cid = None
   return _numpy.array(self.clicks)



def ginput(n=1, timeout=0, show=True, lines=False):
   """
   Simple functional call for physicists. This will wait for n clicks
from the user and
   return a list of the coordinates of each click.

   n=1 number of clicks to collect
   timeout=30  maximum number of seconds to wait for clicks
before giving up.
   timeout=0 to disable
   show=True   print the clicks as they are received
   lines=False draw lines between clicks
   """

   x = GaelInput()
   return x(n, timeout, show, lines)

-
This SF.net email is

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Gael Varoquaux]

On Tue, Feb 05, 2008 at 04:11:59PM -0600, John Hunter wrote:
> Also, my version of GaelInput has seemed to stop evolving. This
> version has the option to draw lines between clicks, which I use a
> lot. Also, the default timeout is 0 now, since you can always
> right-click to abort.

You can still use this behavoir, using a timeout of zero, n = 0, and the
middle click to end (I use right_click to cancel points). I am not sure
what the default timeout should be. If you have strong opinions about it
being 0, that's fine with me.

As far as n = 0 being the default, I think this is a bad idea. First of
all, it break matlab-compatibility for no good reasons, second in most
cases, IMHO, the naive programmer only wants one point, and puts some
logics afterwards. He will not read the doc, and wont understand why his
function is not returning after one click (so many people don't even know
how to read docstring, I am not kidding).

As for the lines, having lines implies that there is a connection order
in your points, which is not always the case. I suggest thus adding a
optional (oof by default) keyword argument for this behavior.

I am working late hours currently to try to improve the mayavi2 docs
before we do a major release, I can't work on this patchs. Jack, do you
feel like writing it. It should be pretty trivial by simply extending
what I wrote for displaying points, and cleaning them afterward, which is
the hardest part.

Sorry not to propose to do it myself, but I already put myself behind the
release schedule by hacking on this on saturday, and I am not even
talking about my day work.

Cheers,

Gaël

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] backend_driver results in separate directories

[Paul Kienzle]

Hi,

I have a patch to post the results of examples/backend_driver.py to
a backend specific directory, after first clearing the directory.

Shall I commit?

- Paul

Index: backend_driver.py
===
--- backend_driver.py   (revision 4942)
+++ backend_driver.py   (working copy)
@@ -131,6 +131,16 @@
 _backend = 'cairo'
 else:
 _backend = backend
+
+# Clear the destination directory for the examples
+path = backend
+if os.path.exists(path):
+import glob
+for fname in os.listdir(path):
+os.unlink(os.path.join(path,fname))
+else:
+os.mkdir(backend)
+
 for fname in files:
 if fname in exclude:
 print '\tSkipping %s, known to fail on backend: %s'%backend
@@ -138,7 +148,7 @@
 
 print ('\tdriving %-40s' % (fname)),
 basename, ext = os.path.splitext(fname)
-outfile = basename + '_%s'%backend
+outfile = os.path.join(path,basename)
 tmpfile_name = '_tmp_%s.py' % basename
 tmpfile = file(tmpfile_name, 'w')
 


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] backend_driver results in separate directories

[Eric Firing]

Paul Kienzle wrote:
> Hi,
> 
> I have a patch to post the results of examples/backend_driver.py to
> a backend specific directory, after first clearing the directory.

Excellent idea.

> 
> Shall I commit?

Yes.

Eric
> 
>   - Paul
> 
> Index: backend_driver.py
> ===
> --- backend_driver.py   (revision 4942)
> +++ backend_driver.py   (working copy)
> @@ -131,6 +131,16 @@
>  _backend = 'cairo'
>  else:
>  _backend = backend
> +
> +# Clear the destination directory for the examples
> +path = backend
> +if os.path.exists(path):
> +import glob
> +for fname in os.listdir(path):
> +os.unlink(os.path.join(path,fname))
> +else:
> +os.mkdir(backend)
> +
>  for fname in files:
>  if fname in exclude:
>  print '\tSkipping %s, known to fail on backend: %s'%backend
> @@ -138,7 +148,7 @@
>  
>  print ('\tdriving %-40s' % (fname)),
>  basename, ext = os.path.splitext(fname)
> -outfile = basename + '_%s'%backend
> +outfile = os.path.join(path,basename)
>  tmpfile_name = '_tmp_%s.py' % basename
>  tmpfile = file(tmpfile_name, 'w')
>  
> 
> 
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Paul Kienzle]

On Tue, Feb 05, 2008 at 03:58:08PM -0600, John Hunter wrote:
> On Feb 2, 2008 8:48 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> 
> > Here is the new patch. I added visual feedback when accumulating points.
> > I hope the docstrings are clear.
> 
> Great -- thanks again.  I applied this patch and created a new example
> ginput_demo.py
> 
> Tested on GTKAgg and TkAgg on my system, and looks good so far.

This failed for me in wx.

I posted a patch r4943 which moves flush_events from Figure to Canvas,
and removes the Yield in gui_repaint which caused an exception in wx.

The showfig callback in FigureManagerWx had an unreferenced global
variable figwin which I removed.  It wasn't obvious to me why this 
was broken, or how long it has been broken, but the ginput example
works for me now.

Setting the timeout to 0.01s for the busy loop in ginput seems excessive.
Since it is waiting for human interaction, generally 0.1 seconds is good
enough.

- Paul

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] backend_driver results in separate directories

[Paul Kienzle]

On Tue, Feb 05, 2008 at 01:05:55PM -1000, Eric Firing wrote:
> Paul Kienzle wrote:
> > Hi,
> > 
> > I have a patch to post the results of examples/backend_driver.py to
> > a backend specific directory, after first clearing the directory.
> 
> Excellent idea.
> 
> > 
> > Shall I commit?
> 
> Yes.

Done.

- Paul

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Gael Varoquaux]

On Tue, Feb 05, 2008 at 06:30:53PM -0500, Paul Kienzle wrote:
> This failed for me in wx.

> I posted a patch r4943 which moves flush_events from Figure to Canvas,
> and removes the Yield in gui_repaint which caused an exception in wx.

> The showfig callback in FigureManagerWx had an unreferenced global
> variable figwin which I removed.  It wasn't obvious to me why this 
> was broken, or how long it has been broken, but the ginput example
> works for me now.

Yes, I had noticed this problem (did I signal it to the list, or did I
forget ?) I wasn't too sure what to do about it, as I don't really know
the MPL codebase. As a result I tested the principle under Wx in an older
version of MPL, which did not have this problem, but also did not have
Yield in gui_repaint. But you sorted out this problem, thanks a lot!


> Setting the timeout to 0.01s for the busy loop in ginput seems excessive.
> Since it is waiting for human interaction, generally 0.1 seconds is good
> enough.

I had gone for that originally, but it looked quite ugly when moving the
window around. This busy waiting is quite ugly, but I have found a way of
avoid it. IMHO it should be done in the toolkit's event loop, but it
seems that trying to do it this would add gobbles of code for little
gain.

Cheers,

Gaël

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Paul Kienzle]

On Tue, Feb 05, 2008 at 11:23:14PM +0100, Gael Varoquaux wrote:
> On Tue, Feb 05, 2008 at 04:11:59PM -0600, John Hunter wrote:
> > Also, my version of GaelInput has seemed to stop evolving. This
> > version has the option to draw lines between clicks, which I use a
> > lot. Also, the default timeout is 0 now, since you can always
> > right-click to abort.
> 
> You can still use this behavoir, using a timeout of zero, n = 0, and the
> middle click to end (I use right_click to cancel points). I am not sure
> what the default timeout should be. If you have strong opinions about it
> being 0, that's fine with me.
> 
> As far as n = 0 being the default, I think this is a bad idea. First of
> all, it break matlab-compatibility for no good reasons, second in most
> cases, IMHO, the naive programmer only wants one point, and puts some
> logics afterwards. He will not read the doc, and wont understand why his
> function is not returning after one click (so many people don't even know
> how to read docstring, I am not kidding).
> 
> As for the lines, having lines implies that there is a connection order
> in your points, which is not always the case. I suggest thus adding a
> optional (oof by default) keyword argument for this behavior.

In my applications I select multiple points from a particular line,
highlighting the point that will be selected as the mouse cursor moves.  
I put a text message on the plot explaining what to do which disappears 
when the selection is complete.

Some other useful cases are selecting an x-range, a y-range or a box,
with the appropriate shading for the selected region.

This is still in Tcl/Tk+BLT; I haven't moved it over to Python yet.

- Paul


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Gael Varoquaux]

On Tue, Feb 05, 2008 at 06:46:19PM -0500, Paul Kienzle wrote:
> In my applications I select multiple points from a particular line,
> highlighting the point that will be selected as the mouse cursor moves.  
> I put a text message on the plot explaining what to do which disappears 
> when the selection is complete.

The idea of the text message is pretty cool in term of usability.

All in all the features that you describe are relly nice. I am sure that
if you find a way to make them toolkit-agnostic they would be a great
addition to MPL.

> Some other useful cases are selecting an x-range, a y-range or a box,
> with the appropriate shading for the selected region.

Same thing here, this is quite nice too. I think this behavior can now be
created using ginput, but it would be cool to have it out of the box.
Sorry, I can't work on it know.

Gaël

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Paul Kienzle]

On Wed, Feb 06, 2008 at 12:38:32AM +0100, Gael Varoquaux wrote:
> On Tue, Feb 05, 2008 at 06:30:53PM -0500, Paul Kienzle wrote:
> > Setting the timeout to 0.01s for the busy loop in ginput seems excessive.
> > Since it is waiting for human interaction, generally 0.1 seconds is good
> > enough.
> 
> I had gone for that originally, but it looked quite ugly when moving the
> window around. This busy waiting is quite ugly, but I have found a way of
> avoid it. IMHO it should be done in the toolkit's event loop, but it
> seems that trying to do it this would add gobbles of code for little
> gain.

How about giving flush_events() an until=condition and timeout=n keywords 
so that flush_events becomes:

if timeout > 0: set timer event which triggers out_of_time
while get next event:
   process event
   if out_of_time or until(): break

Looking through wx I don't see how to "get next event", my choices being
run all events (MainLoop) or run pending events.  I do see an "exit main
loop" function, so for wx at least one could redirect the event handler 
for the window and run all the events, exiting the main loop when done,
but that seems ugly.  I'll look around some more and see if I can find
the sleep until next event function in wx.

- Paul

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] ginput: blocking call for mouse input

[Gael Varoquaux]

On Tue, Feb 05, 2008 at 07:16:59PM -0500, Paul Kienzle wrote:
> How about giving flush_events() an until=condition and timeout=n keywords 
> so that flush_events becomes:

> if timeout > 0: set timer event which triggers out_of_time
>   while get next event:
>process event
>if out_of_time or until(): break

I'd say this is exactly the way to do it. The problem is that under GTK
is seems fairly easy to do, under Tk it seems feasible, but under Qt and
under Wx I have no clue how to do this. We can always fallback to
busy-waiting for these toolkits.

This indeed seems to be the way to go. Maybe I would empty the event
stack when the "until()" condition is met, before returning to the
caller, and thus blocking again.

> I'll look around some more and see if I can find the sleep until next
> event function in wx.

Yeah, sleep, I need more of that. Or maybe you can find wx.coffee ?

Cheers,

Gaël

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel