Just to add to this : If I do pass 2-D x + y arrays (same shape as the u + v) ...

• there is currently no error or warning
• it produces a plot often quite plausibly correct ..
• .. but on closer inspection, generally wrong (!)

That is nasty behaviour IMHO. Certainly, it had me thinking it did work, for a while ... 😊 😳 🤢

There is no reason that streamlines couldn’t be rewritten assuming non equal steps but it’d be a lot more code. Having it be a matrix of x and y points seems a lot harder.

The streamplot example takes in 2D arrays for X,Y,U, and V. So is the example wrong? It looks good to me on first sight. Also, it produces the same output when X and Y are supplied as 1D arrays.

What is the problem with 2D input that you experience? (A code with image and a description of undesired behaviour would be helpful for that.)

Concerning the problem of irregular grids, one can always interpolate onto a regular grid first. Whether this is done by matplotlib internally or by the user externally does not make either way more or less efficient, only more convenient to use.
There are some other functions which only take regular grids. So if such internal solution is desired it might make sense to introduce it for all functions which would benefit from it.
Because matplotlib has a matplotlib.tri.LinearTriInterpolator, there would not be too much work involved. Still, because it is so easy to do the interpolation externally, I would doubt this has high priority.

Theoretically, the integration for making the streamplot need not be done on regularly spaced 1-d x/y grids. You just need to replace dx/dy = constant by a varying function. But the streamplot code is all written assuming dx/dy are constant; I'm not wholly convinced that the streamplot code could not be simplified a fair bit and made to accept vadying dx/dy, but thats not a project I'm going to take on.

We could always make a regular grid for users, but I'd be against us doing that versus making the user do it because gridding data often requires some artistic license, and better to let the user decide what works best for them.

gridding data often requires some artistic license
We could always make a regular grid for users, but I'd be against us doing that versus making the user do it because gridding data often requires some artistic license

I agree. There is no such thing as a general-purpose regrid algorithm.
Though in the specific case of streamplots, there is an argument that precision is not critical, because the relationship between the original data and the plot is much less direct than other types of plot.
Compared to contouring, for example, you can't easily predict or control where it will draw the lines.

From our parochial point of view, we will generally be drawing our plots over maps with Cartopy.
So if we did use regridding, then the Iris code probably has better context for choosing a suitable target grid than matplotlib does.

However, the existing facility still seems a bit clunky to me.
At the least, when it produces a plot that is plausible but wrong, with no warning, that is a nasty gotcha !

I did not have time to read the post very carefully but there may be some implementation ideas here on unevenly gridded data (even though it is likely to be based in a rather old version of streamplot).

One possible mechanism to integrate 1-step from (x0, y0) to (x1, y1):

• Interpolate to find the velocity (u, v) at (x0, y0).
  • Use nearest point or bilinear interpolation for any structured grid.
  • Allow passing in any user-defined interpolator for an unstructured grid.
• Step to (x1, y1) from (x0,y0) using velocity (u,v).
  • Use any standard scheme, for example, the rk12 scheme (that streamplot is using).
• Check the location of (x1, y1) for possible termination.

Additional processings like re-scaling the coordinates and velocities could also be important for getting optimal results.

I'd love for this to be a possible feature, e.g. for streamlines of NEMO ocean data which has 2D lats and lons! Thanks.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!

Commenting in the hopes that this can be revisited (do issues work like that)? The limitation of evenly-spaced data for steamplot() is a pretty significant one, and it is not consistent with the rest of matplotlib. While I understand the sentiment that it's difficult to obtain a general-purpose regridding solution that won't be incompatible with at least some use cases... Matplotlib seems to already have a precedent for this, in that all of the contour functions must be applying some interpolation, no? In any case, this fix linked to by @afvincent seems so straightforward that it should be worth implementing.

Contour does not do any regridding. It just decides where between two consecutive points the contour should pass and doesn't care about how far apart any pair are.

Streamplot could pretty readily do the same thing. But it would need to be rewritten. As noted above, I don't think regridding is necessary or even desirable. However it is likely that a more general code would best done in c rather than Python.