Any update on streamline plot

Hi,

I see two related requests on:

http://old.nabble.com/matplotlib-to-draw-streamlines–td28008708.html

http://www.mail-archive.com/matplotlib-devel@…813…ourceforge.net/msg07267.html

a request filed on http://sourceforge.net/tracker/index.php?func=detail&aid=3080981&group_id=80706&atid=560723

Is there any progress on this plot? Or source guides to implement such functionality in mpl?

PS: The feature request @ http://sourceforge.net/tracker/?atid=560723&group_id=80706&func=browse looks spammed? Anyone works on clearing these?

···


Gökhan

Gökhan: Nobody is working on that as far as I know. An interesting alternative to streamlines can be found here:

http://scikits.appspot.com/vectorplot

-Jeff

···

On 2/11/11 9:10 AM, Gökhan Sever wrote:

Hi,
I see two related requests on:
http://old.nabble.com/matplotlib-to-draw-streamlines--td28008708.html
[matplotlib-devel] Streamlines
a request filed on http://sourceforge.net/tracker/index.php?func=detail&aid=3080981&group_id=80706&atid=560723
Is there any progress on this plot? Or source guides to implement such functionality in mpl?
PS: The feature request @ http://sourceforge.net/tracker/?atid=560723&group_id=80706&func=browse looks spammed? Anyone works on clearing these?

--
Gökhan

--
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

Gökhan:

I just added a lic_demo.py example to basemap SVN that shows how to use the vectorplot scikit with basemap (image as http://jswhit.fastmail.fm/lic_demo.png). Is this the sort of thing you were looking for?

-Jeff

···

On 2/11/11 9:45 AM, Jeff Whitaker wrote:

On 2/11/11 9:10 AM, Gökhan Sever wrote:

Hi,
I see two related requests on:
http://old.nabble.com/matplotlib-to-draw-streamlines--td28008708.html
[matplotlib-devel] Streamlines
a request filed on
http://sourceforge.net/tracker/index.php?func=detail&aid=3080981&group_id=80706&atid=560723
<http://sourceforge.net/tracker/index.php?func=detail&aid=3080981&group_id=80706&atid=560723&gt;
Is there any progress on this plot? Or source guides to implement such
functionality in mpl?
PS: The feature request @
http://sourceforge.net/tracker/?atid=560723&group_id=80706&func=browse
<matplotlib download | SourceForge.net; looks
spammed? Anyone works on clearing these?

--
Gökhan

Gökhan: Nobody is working on that as far as I know. An interesting
alternative to streamlines can be found here:

http://scikits.appspot.com/vectorplot

-Jeff

--
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

Hi,

I wrote a script to generate streamline plots using matplotlib a while
ago, and this post inspired me to finally clean it up a bit. The code is
available at http://web.mit.edu/speth/Public/streamlines.py and you can
see an example of its output at
http://web.mit.edu/speth/Public/streamlines.png

I'd be happy to have it find a home in matplotlib if it would be useful
to other people there.

Ray

···

On 02/11/2011 11:10 AM, Gökhan Sever wrote:

Hi,
I see two related requests on:
http://old.nabble.com/matplotlib-to-draw-streamlines--td28008708.html
[matplotlib-devel] Streamlines
a request filed on
http://sourceforge.net/tracker/index.php?func=detail&aid=3080981&group_id=80706&atid=560723
<http://sourceforge.net/tracker/index.php?func=detail&aid=3080981&group_id=80706&atid=560723&gt;
Is there any progress on this plot? Or source guides to implement such
functionality in mpl?
PS: The feature request @
http://sourceforge.net/tracker/?atid=560723&group_id=80706&func=browse
<matplotlib download | SourceForge.net; looks
spammed? Anyone works on clearing these?

--
Gökhan

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Ray,

That is absolutely beautiful work there.

At the very least, I would like to see this added to the gallery or the cookbook. The code is very nicely commented and documented. Just a few points that come to mind.

First, consider the possibility of using asanyarray() instead of asarray(). The big usecase for asanyarray is the use of masked arrays.

Second, I am personally against call signatures that are just “**kwargs” and then popping off the arguments at the beginning of the method. So long as the default value is not a mutable object, then put those arguments in the call signature with the default values. It is much more IDE and documentation-friendly this way.

Third, I would think that using plt.gca() would be better than plt.axes() just in case the user is using subplots. gca() will create an axes if none exists already.

Lastly, you should do ax.plot() instead of plt.plot() since you have already retrieved the axes object. This way, in case the axes object passed in is not the currently active axes, it would still work.

The difficulty in getting this included into matplotlib proper (and the same goes to the other thread about streamgraphs) is that these plots are done in an object oriented rather than procedural approach. Personally, I would like to see (one day) a refactor of matplotlib where everything plotable is an object that gets placed into the axes object (which, itself is a plotable that gets placed in a figure…). While the current code isn’t too far from that concept, the interface is ultimately procedural.

@everyone else:
The big reason I see for a future refactor to an object-oriented approach is that plots are getting more complicated, and we can’t just keep on adding more methods to the axes object. A more object-oriented approach would allow for complex graphs to be placed into their own modules, and yet still be treated the same as any other plotting method. It would also make it easier for others to extend matplotlib’s plotting features.

Ben Root

···

On Fri, Feb 11, 2011 at 3:06 PM, Ray Speth <speth@…2397…> wrote:

Hi,

I wrote a script to generate streamline plots using matplotlib a while

ago, and this post inspired me to finally clean it up a bit. The code is

available at http://web.mit.edu/speth/Public/streamlines.py and you can

see an example of its output at

http://web.mit.edu/speth/Public/streamlines.png

I’d be happy to have it find a home in matplotlib if it would be useful

to other people there.

Ray

Could you put a license statement on the file you posted? Even if it isn't included in matplotlib, I think we would love to include it in Sage. I've wanted to have streamline plots in Sage for a long time, and your plots look great!

Thanks,

Jason

···

On 2/11/11 3:06 PM, Ray Speth wrote:

Hi,

I wrote a script to generate streamline plots using matplotlib a while
ago, and this post inspired me to finally clean it up a bit. The code is
available at http://web.mit.edu/speth/Public/streamlines.py and you can
see an example of its output at
http://web.mit.edu/speth/Public/streamlines.png

I'd be happy to have it find a home in matplotlib if it would be useful
to other people there.

Ben,

Thanks for the suggestions. I've updated the code accordingly. I tend to use **kwargs because it enforces passing arguments in by keyword, but your point on IDE friendliness is well taken. Someday, we'll move to Python 3 with its support for keyword-only arguments...

I've also added a license block releasing the code under the MIT license. If there's a reason it should be released under a different license as well, let me know.

Ray

···

On 2/12/2011 1:01 PM, Benjamin Root wrote:

On Fri, Feb 11, 2011 at 3:06 PM, Ray Speth <speth@...1166... > <mailto:speth@…1166…>> wrote:

    Hi,

    I wrote a script to generate streamline plots using matplotlib a while
    ago, and this post inspired me to finally clean it up a bit. The code is
    available at http://web.mit.edu/speth/Public/streamlines.py and you can
    see an example of its output at
    http://web.mit.edu/speth/Public/streamlines.png

    I'd be happy to have it find a home in matplotlib if it would be useful
    to other people there.

    Ray

Ray,

That is absolutely beautiful work there.

At the very least, I would like to see this added to the gallery or the
cookbook. The code is very nicely commented and documented. Just a few
points that come to mind.

First, consider the possibility of using asanyarray() instead of
asarray(). The big usecase for asanyarray is the use of masked arrays.

Second, I am personally against call signatures that are just "**kwargs"
and then popping off the arguments at the beginning of the method. So
long as the default value is not a mutable object, then put those
arguments in the call signature with the default values. It is much
more IDE and documentation-friendly this way.

Third, I would think that using plt.gca() would be better than
plt.axes() just in case the user is using subplots. gca() will create
an axes if none exists already.

Lastly, you should do ax.plot() instead of plt.plot() since you have
already retrieved the axes object. This way, in case the axes object
passed in is not the currently active axes, it would still work.

The difficulty in getting this included into matplotlib proper (and the
same goes to the other thread about streamgraphs) is that these plots
are done in an object oriented rather than procedural approach.
Personally, I would like to see (one day) a refactor of matplotlib where
everything plotable is an object that gets placed into the axes object
(which, itself is a plotable that gets placed in a figure...). While
the current code isn't too far from that concept, the interface is
ultimately procedural.

@everyone else:
The big reason I see for a future refactor to an object-oriented
approach is that plots are getting more complicated, and we can't just
keep on adding more methods to the axes object. A more object-oriented
approach would allow for complex graphs to be placed into their own
modules, and yet still be treated the same as any other plotting
method. It would also make it easier for others to extend matplotlib's
plotting features.

Ben Root