matplotlib-devel Mailing List for matplotlib

John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> wrote:
> 
>> The patch isn't done - manually selected labels won't be rotated or
>> inline.  There is also a need for general cleaning up and documentation.
>> I just want to see what people think about the approach before investing
>> more time.  I added this functionality by adding a class
>> ContourLabelerWithManual that inherits from ContourLabeler and
>> BlockingMouseInput (the class used by ginput to interactively select
>> points).  ContourSet then inherits from ContourLabelerWithManual instead
>> of ContourLabeler.  If manual is selected, then it enters interactive
>> mode, if not, then results should be as before.
> 
> Hi David,
> 
> I think this looks good.  I would like to see it finished before
> inclusion (eg rotating the labels inline) but this functionality looks
> very useful.  In general, I think it would be nice to have better
> support for easy interaction with figures, eg for annotations.  My
> main question is whether blocking input is the best choice.
> Admitedly,  most users find it more intuitive to set up blocking input
> rather than using non-blocking input that is terminated by a custom
> button press, key stroke, or command, but I am worried about how
> robust this is across user interfaces and environments, with all the
> attendant problems of GUI threads, mainloops, etc.  Gael has done a
> nice job with ginput across backends, but this code is relatively new
> and lightly tested.  Basically, someone (probably you and Gael) will
> need to be up to the task of supporting blocking input across user
> interfaces, which probably isn't trivial but maybe I'm overly
> cautious.  Anyway, something to think about.
> 
>> I also had to move the classes Blocking*Input from figure.py to a
>> separate file blocking_input.py to avoid circular imports.
> 
> A minor nit here: when you import blocking_input, you should use
> 
>   import matplotlib.blocking_input as blocking_input
> 
> rather than simply
> 
>   import blocking_input
> 
> as discussed in the coding guide:
> http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html
> 
> On the subject of the docs, we are in the midst of a push to get beter
> documentation for mpl, so anything you can add while working in terms
> of tutorial or faq or whatever on the new code would be welcome.  The
> docs are in the doc subdir of the svn trunk.
> 
>> Please let me know what you think.  Also, I am wondering if the powers
>> that be would be willing to give me commit access to my own branch of
>> the matplotlib svn.  I don't want to modify the trunk, but for my own
>> sanity, it would be nice to be able to keep track of my changes
>> somewhere.  If not, I would like to here what other non-commit
>> developers do to best organize changes.
> 
> If you send me your sf id, I will add you to the developer list.  I
> don't mind you committing to the trunk unless you are afraid your
> changes will break code.  I am not a huge fan of having a lot of
> branches.
> 
> Thanks for the submission -- I await more informed commentary from
> those who actually use contouring....

I agree with adding the functionality provided it can be done in a 
robust and maintainable way; I have never looked into the arcane aspects 
of gui interaction across backends.

Unless it got fixed as part of the transforms re-write, there are 
problems even with the existing contour labeling, in that it does not 
(or did not) handle resizes well.  Among the many things I have thought 
of but not gotten to is the idea that there should be a LabeledLine 
class to handle this outside of contour.py.  The idea is that in 
addition to the ordinary line path, it would include a list of labels 
and positions (not sure what the right way to specify the positions is), 
and the class would handle breaking the path and inserting the correctly 
rotated text.

Eric


> 
> JDH
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John Hunter wrote:
> On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> wrote:
>   
>> Please let me know what you think.  Also, I am wondering if the powers
>> that be would be willing to give me commit access to my own branch of
>> the matplotlib svn.  I don't want to modify the trunk, but for my own
>> sanity, it would be nice to be able to keep track of my changes
>> somewhere.  If not, I would like to here what other non-commit
>> developers do to best organize changes.
>>     
>
> If you send me your sf id, I will add you to the developer list.  I
> don't mind you committing to the trunk unless you are afraid your
> changes will break code.  I am not a huge fan of having a lot of
> branches.
>   
I agree with John -- you should just get developer access and be careful 
not to break things (easier said than done, especially for yours truly).

For future reference, though, I've been using git-svn (which lets you 
use git for a local repository that tracks a remote SVN repository) on a 
hobby-time project and have found it pretty useful for keeping my own 
local history without disturbing (or even having write access to) the 
central SVN repository.  Of course, moving from svn to git requires 
retraining the fingers a little bit, but it's not too bad.

Cheers,
Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Ryan May wrote:
> Hi,
>
> I've got (what seems to me) a nice clean, self-contained 
> implementation of wind barbs plots.  I'd like to see if I can get this 
> into matplotlib, as it would be very useful to the meteorology 
> community.  I've borrowed heavily from Quiver for rounding out rough 
> edges (like multiple calling signatures) as for templates for 
> documentation.  The base implementation, though, seems much simpler 
> (thanks to Mike's transforms) and is based more on scatter.
>
> Right now it monkey-patches Axes so that it can be a stand-alone file. 
> Just running the file should give a good example of the expected output.
>
> My only concern up front is if a new axes method is appropriate, since 
> this is somewhat domain specific.  But I'd like to at least get the 
> new Collections class included, since otherwise, I have no idea how to 
> get this distributed to the community at large.
>
> I welcome any comments/criticism to help improve this.
>
> Ryan
>
Ryan:  This looks great!  I fixed one typo (the "length" keyword was 
mis-identified as "scale" in the docstring) and replace your example 
with an adaption of the quiver_demo.py basemap example.

I noticed that ticks on the barbs are so close that they are hard to 
discern unless the linewidth is reduced.  I wonder if the spacing of the 
ticks  could be added as a keyword, perhaps as a fraction of the wind 
barb length?

This will be a wonderful addition to matplotlib.  Thanks!

-Jeff

P.S.  eagerly awaiting your Skew-T implementation ....


-- 
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

On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <dm...@uc...> wrote:

> The patch isn't done - manually selected labels won't be rotated or
> inline.  There is also a need for general cleaning up and documentation.
> I just want to see what people think about the approach before investing
> more time.  I added this functionality by adding a class
> ContourLabelerWithManual that inherits from ContourLabeler and
> BlockingMouseInput (the class used by ginput to interactively select
> points).  ContourSet then inherits from ContourLabelerWithManual instead
> of ContourLabeler.  If manual is selected, then it enters interactive
> mode, if not, then results should be as before.

Hi David,

I think this looks good.  I would like to see it finished before
inclusion (eg rotating the labels inline) but this functionality looks
very useful.  In general, I think it would be nice to have better
support for easy interaction with figures, eg for annotations.  My
main question is whether blocking input is the best choice.
Admitedly,  most users find it more intuitive to set up blocking input
rather than using non-blocking input that is terminated by a custom
button press, key stroke, or command, but I am worried about how
robust this is across user interfaces and environments, with all the
attendant problems of GUI threads, mainloops, etc.  Gael has done a
nice job with ginput across backends, but this code is relatively new
and lightly tested.  Basically, someone (probably you and Gael) will
need to be up to the task of supporting blocking input across user
interfaces, which probably isn't trivial but maybe I'm overly
cautious.  Anyway, something to think about.

> I also had to move the classes Blocking*Input from figure.py to a
> separate file blocking_input.py to avoid circular imports.

A minor nit here: when you import blocking_input, you should use

  import matplotlib.blocking_input as blocking_input

rather than simply

  import blocking_input

as discussed in the coding guide:
http://matplotlib.sourceforge.net/doc/html/devel/coding_guide.html

On the subject of the docs, we are in the midst of a push to get beter
documentation for mpl, so anything you can add while working in terms
of tutorial or faq or whatever on the new code would be welcome.  The
docs are in the doc subdir of the svn trunk.

> Please let me know what you think.  Also, I am wondering if the powers
> that be would be willing to give me commit access to my own branch of
> the matplotlib svn.  I don't want to modify the trunk, but for my own
> sanity, it would be nice to be able to keep track of my changes
> somewhere.  If not, I would like to here what other non-commit
> developers do to best organize changes.

If you send me your sf id, I will add you to the developer list.  I
don't mind you committing to the trunk unless you are afraid your
changes will break code.  I am not a huge fan of having a lot of
branches.

Thanks for the submission -- I await more informed commentary from
those who actually use contouring....

JDH

Hi,

Attached is a patch (created by issuing svn diff from the
matplotlib/trunk/matplotlib directory) for adding the capability to
manually select the location of contour labels in clabel.  Though the
existing algorithm for automatically placing contour labels is very
good, for complex figures with multiple elements it is often desirable
to manually place labels.  This functionality is meant to imitate the
matlab functionality of clabel(cs,'manual').  

The attached patch includes a modified version of the changes I
previously made to add a "waitforbuttonpress" command to matplotlib as
these changes are a prerequisite for using the added functionality of
clabel (i.e., you shouldn't apply both patches, just this last one).

The changes work as follows:

cs = contour(x,y,z)
cl = clabel(cs,'manual')

(use the third mouse button to finish placing labels, second button to
erase a previously added label)

The patch isn't done - manually selected labels won't be rotated or
inline.  There is also a need for general cleaning up and documentation.
I just want to see what people think about the approach before investing
more time.  I added this functionality by adding a class
ContourLabelerWithManual that inherits from ContourLabeler and
BlockingMouseInput (the class used by ginput to interactively select
points).  ContourSet then inherits from ContourLabelerWithManual instead
of ContourLabeler.  If manual is selected, then it enters interactive
mode, if not, then results should be as before.  

I also had to move the classes Blocking*Input from figure.py to a
separate file blocking_input.py to avoid circular imports.

Please let me know what you think.  Also, I am wondering if the powers
that be would be willing to give me commit access to my own branch of
the matplotlib svn.  I don't want to modify the trunk, but for my own
sanity, it would be nice to be able to keep track of my changes
somewhere.  If not, I would like to here what other non-commit
developers do to best organize changes.

Thanks,
David

-- 
**********************************
David M. Kaplan
Assistant Researcher
UCSC / Institute of Marine Sciences
Ocean Sciences
1156 High St.
SC, CA 95064

Phone: 831-459-4789
Fax: 831-459-4882
http://pmc.ucsc.edu/~dmk/
**********************************

John Hunter wrote:
> On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <rm...@gm...> wrote:
>
>   
> The 2nd alternative, which I haven't
> explored, is to set the edgecolor equal to the facecolor and support
> colormapping of the edgecolors.
>   
FWIW, pcolor and pcolormesh have also needed this functionality, and 
they do so in a somewhat hackish way.  It would be nice (if barbs goes 
this way) to move that up into the Collections class and reuse it 
everywhere that needs it.

Mike
>
>   

On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <rm...@gm...> wrote:

> I welcome any comments/criticism to help improve this.

Hey Ryan,

I have looked at this code briefly and have a few minor comments.  I
think Eric, who did the bulk of the current quiver implementation, and
as an oceanographer is in a field much closer to yours than mine, will
provide more useful feedback and should ultimately handle the patch
submission.

My first comment is that the code looks very good -- it is well
thought out and commented, and t is definitely suitable for inclusion
in the main line.  Certainly the Barbs class can live in the
collections module.  You note in the driver code that you are worried
about pollution of the axes namespace by including a domain specific
method, and this is a reasonable worry, but the axes namespace is
currently so polluted with plotting methods that it is a small worry.
I think it would be fine for you to rework your code into a patch
which provides the Barbs collection in matplotlib.collections, an Axes
method, and a pyplot interface function (with a pylab module level
docstring entry).  The overloading of the Axes namespace is not ideal,
but it's what we've got.

My second comment has to do with your comment at the end of the example:

     #Showing colormapping with uniform grid. Unfortunately, only the flags
     #on barbs get colormapped this way.

On a cursory read of the code, it looks like you have implemented
everything as a single poly collection, and the reason the flags only
get colored is that the varicolored is black.  It seems like there are
two solutions: write your class as a combination of poly collection
(for the flags) and line collection (for the barbs) and colormap both
(there are some line collection colormapping examples in the examples
subdir courtesy of Eric).  The 2nd alternative, which I haven't
explored, is to set the edgecolor equal to the facecolor and support
colormapping of the edgecolors.

Overall this is very promising, and I wish you the best trying to make
mpl serviceble to the meteorology community.  Jeff Whitaker has done a
phenomenal job with basemap providing extensions for those needing
cartographic projections as a toolkit.  Depending on how far you want
to go with meteorological support, we can include the changes in the
mainline or fold them into a toolkit if they become hyper-specialized.

JDH

Bonjour,

C'est dangeureux dans m'envoyer un email dans ma boite mail particulière.
C'est la meilleur moyen de ne jamais recevoir de réponse: je reçoit 200
email par jour, et je les lis en diagonale. Enfin, j'image que c'était
une erreur, et que l'e-mail aurait dû partir à la mailing list
matplotlib-dev.

On Tue, Jul 15, 2008 at 06:42:01PM +0200, David Kaplan wrote:
> I have a hopefully simple question that perhaps you could help me with.
> I am trying to add the possibility of manual selection of contour label
> locations to clabel (as in matlab), and I want to use the class
> BlockingMouseInput in contour.py, but I can't figure out how to import
> that class correctly into contour.py.  Could you give me a hint?

Hum, I am not too sure what you are trying to do. It has been a while
since I have used Matlab, so I don't think I know what feature you are
refering too. Could you please elaborate both by describing what you are
trying to achieve in terms of end-user experience, and by giving a simple
example of the code you are trying to get to run.

Cheers,

Gaël