Re: [matplotlib-devel] (Wind) Barbs
John Hunter wrote: > On Tue, Jul 15, 2008 at 5:37 PM, Ryan May <[EMAIL PROTECTED]> 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 > > - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] patch for adding manual label location selection to clabel
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/
**
Index: lib/matplotlib/pyplot.py
===
--- lib/matplotlib/pyplot.py (revision 5770)
+++ lib/matplotlib/pyplot.py (working copy)
@@ -320,7 +320,21 @@
if Figure.ginput.__doc__ is not None:
ginput.__doc__ = dedent(Figure.ginput.__doc__)
+def waitforbuttonpress(*args, **kwargs):
+"""
+Blocking call to interact with the figure.
+This will wait for *n* key or mouse clicks from the user and
+return a list containing True's for keyboard clicks and False's
+for mouse clicks.
+
+If *timeout* is negative, does not timeout.
+"""
+return gcf().waitforbuttonpress(*args, **kwargs)
+if Figure.waitforbuttonpress.__doc__ is not None:
+waitforbuttonpress.__doc__ = dedent(Figure.waitforbuttonpress.__doc__)
+
+
# Putting things in figures
def figtext(*args, **kwargs):
Index: lib/matplotlib/contour.py
===
--- lib/matplotlib/contour.py (revision 5770)
+++ lib/matplotlib/contour.py (working copy)
@@ -17,6 +17,9 @@
import matplotlib.text as text
import matplotlib.cbook as cbook
+# Import needed for adding manual selection capability to clabel
+from blocking_input import BlockingMouseInput
+
# We can't use a single line collection for contour because a line
# collection can have only a single line style, and we want to be able to have
# dashed negative contours, for example, and solid positive contours.
@@ -128,9 +131,6 @@
self.labels(inline)
-for label in self.cl:
-self.ax.add_artist(label)
-
self.label_list = cbook.silent_list('text.Text', self.cl)
return self.label_list
@@ -335,6 +335,25 @@
return x,y, rotation, dind
+def add_label(self,x,y,rotation,lev,fmt,color,cvalue):
+dx,dy = self.ax.transData.inverted().transform_point((x,y))
+t = text.Text(dx, dy, rotation = rotation,
+ horizontalalignment='center',
+ verticalalignment='center')
+_text = self.get_text(lev,fmt)
+self.set_label_props(t, _text, color)
+self.cl.append(t)
+self.cl_cvalues.append(cvalue)
+
+# Add label to plot here - useful for manual mode label selection
+self.ax.add_artist(t)
+
+def remove_label(self,index=-1):
+'''Defaults to removing last label, but any index can be supplied'''
+self.cl_cvalues.pop(index)
+t = self.cl.pop(index)
+t.remove()
+
def labels(self, inline):
levels = self.label_levels
fslist = self.fslist
@@ -362,16 +381,8 @@
slc = trans.transform(linecontour)
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] (Wind) Barbs
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/PSD1Email : [EMAIL PROTECTED] 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg ''' Support for plotting a field of (wind) barbs. This is like quiver in that you have something that points along a vector field giving direction, but the magnitude of the vector is given schematically by the presence of barbs or flags on the barb. This differs from quiver, which uses the size of the arrow to indicate vector magnitude. ''' import numpy as np from numpy import ma from matplotlib import rcParams import matplotlib.collections as mcoll import matplotlib.transforms as mtransforms import matplotlib.artist as martist _barbs_doc = """ Plot a 2-D field of barbs. call signatures:: barb(U, V, **kw) barb(U, V, C, **kw) barb(X, Y, U, V, **kw) barb(X, Y, U, V, C, **kw) Arguments: *X*, *Y*: The x and y coordinates of the barb locations (default is head of barb; see *pivot* kwarg) *U*, *V*: give the *x* and *y* components of the barb shaft *C*: an optional array used to map colors to the barbs All arguments may be 1-D or 2-D arrays or sequences. If *X* and *Y* are absent, they will be generated as a uniform grid. If *U* and *V* are 2-D arrays but *X* and *Y* are 1-D, and if len(*X*) and len(*Y*) match the column and row dimensions of *U*, then *X* and *Y* will be expanded with :func:`numpy.meshgrid`. *U*, *V*, *C* may be masked arrays, but masked *X*, *Y* are not supported at present. Keyword arguments: *length*: Length of the barb in points; the other parts of the barb are scaled against this. Default is 9 *pivot*: [ 'tip' | 'middle' ] The part of the arrow that is at the grid point; the arrow rotates about this point, hence the name *pivot*. *barbcolor*: [ color | color sequence ] Specifies the color all parts of the barb except any flags. This parameter is analagous to the *edgecolor* parameter for polygons, which can be used instead. However this parameter will override facecolor. *flagcolor*: [ color | color sequence ] Specifies the color of any flags on the barb. This parameter is analagous to the *facecolor* parameter for polygons, which can be used instead. However this parameter will override facecolor. If this is not set (and *C* has not either) then *flagcolor* will be set to match *barbcolor* so that the barb has a uniform color. If *C* has been set, *flagcolor* has no effect. *pivot*: [ 'tip' | 'middle' ] The part of the arrow that is at the grid point; the arrow rotates about this point, hence the name *pivot*. Barbs are traditionally used in meteorology as a way to plot the speed and direction of wind observations, but can technically be used to plot any two dimensional vector quantity. As opposed to arrows, which give vector magnitude by the length of the arrow, the barbs give more quantitative information about the vector magnitude by putting slanted lines or a triangle for various increments in magnitude, as show schematically below: /\\ / \\ /\\\ / \\\ -- The largest increment is given by a triangle (or "flag"), which usually represents inrements of 50. After those come full lines, which represent 10. The smallest increment is a ha
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
John Hunter wrote: > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> 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 - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
John Hunter wrote: > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel - 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 Matplotlib-devel@lists.sourceforge.net htt
Re: [matplotlib-devel] patch for adding manual label location selection to clabel
John Hunter wrote: > On Wed, Jul 16, 2008 at 7:20 AM, David M. Kaplan <[EMAIL PROTECTED]> wrote: > > Thanks for the submission -- I await more informed commentary from > those who actually use contouring > Just because the discussion about clabel started, I want to post a short snipplet of code that I found useful. It was some sort of hack to get a nicer float formating for contours: contour lines represented confidence levels of 1, 2.5, 5 and 10 per cent, and I wanted a labeling exactly as I have written it here now. So, fmt='%.1f\%%' would have resulted in 1.0% 2.5% 5.0% ... but I wanted 1% 2.5% 5% ... So this was my solution: # some kind of hack: a nicer floating point formating class nf(float): def __repr__(self): str = '%.1f' % (self.__float__(),) if str[-1]=='0': return '%.0f' % self.__float__() else: return '%.1f' % self.__float__() levels = [nf(val) for val in [1.0, 2.5,5.0,10.0] ] pylab.clabel(cs, inline=True, fmt='%r \%%') As I said, it's sort of a hack but it works! It might not be worth to add this to mpl, but probably as an example ...!? Manuel - 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
