matplotlib-users Mailing List for matplotlib

Thanks Eric, this did the trick. I did not know such a thing existed. Why
"4"?
Tim
On Tue, Dec 11, 2012 at 4:35 PM, Eric Firing <ef...@ha...> wrote:
> On 2012年12月11日 12:16 PM, Timothy Duly wrote:
> > Hi,
> >
> > I'm running into a problem with overlaying a scatter plot on a polygon
> > that is on a Basemap. The polygon covers up the scatter plot created by
> > the basemap. To show the issue, the simple example below and broken
> > down into three steps: 1) creating the map, 2) adding the red polygon,
> > and 3) adding the "x" markers via a scatter plot. You will see that the
> > "x" markers are not on top of the polygon.
> >
> > Why does the polygon cover up the markers, even though I have the
> > markers added after the polygon? Would there be a better way to do
> > this? I could set the polygon alpha to, say, 0.5, but this feature does
> > not show when I save it as an eps image. Therefore, I would like to
> > keep alpha=1.
>
> Artists have a zorder attribute that controls the drawing order. Try
> adding the kwarg zorder=4 to your scatter call. I think that will take
> care of it. (Alternatively you could lower the zorder of the polygon.)
>
> Eric
>
> >
> > Thanks,
> > Tim
> >
> > from mpl_toolkits.basemap import Basemap
> > import numpy as np
> > from matplotlib.pyplot import *
> > from matplotlib.patches import Polygon
> >
> >
> > # ---------------------
> > # Part 1: Draw the map
> > # ---------------------
> >
> > # Hawaii:
> > lat_0 = 20.71-8.
> > lon_0 = 203.83
> >
> > figure(1); clf();
> > m = Basemap(width=2500e3,height=2500e3,
> > resolution='l',projection='stere', \
> > lat_ts=lat_0,lat_0=lat_0,lon_0=lon_0)
> >
> > m.drawcoastlines()
> > m.fillcontinents(color='coral',lake_color='aqua')
> >
> > # draw parallels and meridians:
> > m.drawmapboundary(fill_color='aqua')
> >
> > lats = np.arange(np.floor(m.latmin),np.ceil(m.latmax),2.)
> > lons = np.arange(190.,211.,5.)
> > m.drawparallels(lats,labels=[True,False,False,False])
> > m.drawmeridians(lons,labels=[False,False,False,True])
> >
> > draw(); show()
> >
> > # ---------------------
> > # Part 2: Add a polygon
> > # ---------------------
> >
> > lon_poly = np.array([-160., -150., -150., -160.,])
> > lat_poly = np.array([10., 10., 14., 14.,])
> > X, Y = m(lon_poly, lat_poly)
> > xy = np.vstack([X,Y]).T
> >
> > poly = Polygon(xy, closed=True, \
> > facecolor='red', \
> > linewidth=1., \
> > )
> >
> > gca().add_patch(poly)
> >
> > # ---------------------
> > # Part 3: add some 'x' markers
> > # ---------------------
> >
> > lon_markers = np.arange(-168.,-144.,2.)
> > lat_markers = np.arange(5.,20.,1.)
> > X, Y = np.meshgrid(lon_markers, lat_markers)
> >
> > x, y = m(X.ravel(), Y.ravel())
> > m.scatter(x,y,marker='x')
> >
> > draw(); show()
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> >
> >
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 2012年12月11日 12:16 PM, Timothy Duly wrote:
> Hi,
>
> I'm running into a problem with overlaying a scatter plot on a polygon
> that is on a Basemap. The polygon covers up the scatter plot created by
> the basemap. To show the issue, the simple example below and broken
> down into three steps: 1) creating the map, 2) adding the red polygon,
> and 3) adding the "x" markers via a scatter plot. You will see that the
> "x" markers are not on top of the polygon.
>
> Why does the polygon cover up the markers, even though I have the
> markers added after the polygon? Would there be a better way to do
> this? I could set the polygon alpha to, say, 0.5, but this feature does
> not show when I save it as an eps image. Therefore, I would like to
> keep alpha=1.
Artists have a zorder attribute that controls the drawing order. Try 
adding the kwarg zorder=4 to your scatter call. I think that will take 
care of it. (Alternatively you could lower the zorder of the polygon.)
Eric
>
> Thanks,
> Tim
>
> from mpl_toolkits.basemap import Basemap
> import numpy as np
> from matplotlib.pyplot import *
> from matplotlib.patches import Polygon
>
>
> # ---------------------
> # Part 1: Draw the map
> # ---------------------
>
> # Hawaii:
> lat_0 = 20.71-8.
> lon_0 = 203.83
>
> figure(1); clf();
> m = Basemap(width=2500e3,height=2500e3,
> resolution='l',projection='stere', \
> lat_ts=lat_0,lat_0=lat_0,lon_0=lon_0)
>
> m.drawcoastlines()
> m.fillcontinents(color='coral',lake_color='aqua')
>
> # draw parallels and meridians:
> m.drawmapboundary(fill_color='aqua')
>
> lats = np.arange(np.floor(m.latmin),np.ceil(m.latmax),2.)
> lons = np.arange(190.,211.,5.)
> m.drawparallels(lats,labels=[True,False,False,False])
> m.drawmeridians(lons,labels=[False,False,False,True])
>
> draw(); show()
>
> # ---------------------
> # Part 2: Add a polygon
> # ---------------------
>
> lon_poly = np.array([-160., -150., -150., -160.,])
> lat_poly = np.array([10., 10., 14., 14.,])
> X, Y = m(lon_poly, lat_poly)
> xy = np.vstack([X,Y]).T
>
> poly = Polygon(xy, closed=True, \
> facecolor='red', \
> linewidth=1., \
> )
>
> gca().add_patch(poly)
>
> # ---------------------
> # Part 3: add some 'x' markers
> # ---------------------
>
> lon_markers = np.arange(-168.,-144.,2.)
> lat_markers = np.arange(5.,20.,1.)
> X, Y = np.meshgrid(lon_markers, lat_markers)
>
> x, y = m(X.ravel(), Y.ravel())
> m.scatter(x,y,marker='x')
>
> draw(); show()
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi,
I'm running into a problem with overlaying a scatter plot on a polygon that
is on a Basemap. The polygon covers up the scatter plot created by the
basemap. To show the issue, the simple example below and broken down into
three steps: 1) creating the map, 2) adding the red polygon, and 3) adding
the "x" markers via a scatter plot. You will see that the "x" markers are
not on top of the polygon.
Why does the polygon cover up the markers, even though I have the markers
added after the polygon? Would there be a better way to do this? I could
set the polygon alpha to, say, 0.5, but this feature does not show when I
save it as an eps image. Therefore, I would like to keep alpha=1.
Thanks,
Tim
from mpl_toolkits.basemap import Basemap
import numpy as np
from matplotlib.pyplot import *
from matplotlib.patches import Polygon
# ---------------------
# Part 1: Draw the map
# ---------------------
# Hawaii:
lat_0 = 20.71-8.
lon_0 = 203.83
figure(1); clf();
m = Basemap(width=2500e3,height=2500e3,
 resolution='l',projection='stere', \
 lat_ts=lat_0,lat_0=lat_0,lon_0=lon_0)
m.drawcoastlines()
m.fillcontinents(color='coral',lake_color='aqua')
# draw parallels and meridians:
m.drawmapboundary(fill_color='aqua')
lats = np.arange(np.floor(m.latmin),np.ceil(m.latmax),2.)
lons = np.arange(190.,211.,5.)
m.drawparallels(lats,labels=[True,False,False,False])
m.drawmeridians(lons,labels=[False,False,False,True])
draw(); show()
# ---------------------
# Part 2: Add a polygon
# ---------------------
lon_poly = np.array([-160., -150., -150., -160.,])
lat_poly = np.array([10., 10., 14., 14.,])
X, Y = m(lon_poly, lat_poly)
xy = np.vstack([X,Y]).T
poly = Polygon(xy, closed=True, \
 facecolor='red', \
 linewidth=1., \
 )
gca().add_patch(poly)
# ---------------------
# Part 3: add some 'x' markers
# ---------------------
lon_markers = np.arange(-168.,-144.,2.)
lat_markers = np.arange(5.,20.,1.)
X, Y = np.meshgrid(lon_markers, lat_markers)
x, y = m(X.ravel(), Y.ravel())
m.scatter(x,y,marker='x')
draw(); show()

Would it be workable for the default to be proportional to the size of the array passed in? (suggested only because I do that myself, when deciding how coarse an investigative plot I can get away with.) 
&C
On Dec 11, 2012, at 9:28 AM, Benjamin Root wrote:
> 
> 
> On Tue, Dec 11, 2012 at 12:17 PM, Ethan Gutmann <eth...@gm...> wrote:
> > This is because the default rstride and cstride arguments is 10, IIRC. Since your array is only 12x12, the surface plotting is barely plotting anything. Try calling:
> >
> > ax.plot_surface(x, y, a, rstride=1, cstride=1)
> 
> 
> You know, this has tripped me up a few times too. I don't use plot_surface often enough to always remember this, and it is not the first parameter I think to check when debugging a program. Is there a reason the default rstride and cstride aren't 1 other than possible memory constraints for large arrays?
> 
> I suppose changing the defaults might break programs that rely on this behavior, but if this API ever gets revamped, consider this a request to make 1 be the default instead. I would think that the default should be that the obvious command "just works" while plots that may require too much memory can be tweaked to work faster (I'm assuming that is the reason for the default of 10).
> 
> 
> I actually don't know the reason for the defaults (I didn't create mplot3d), but that has always been my suspicion. There is an existing PR to change the default behavior to be somewhat "automatic". At the time, I wasn't really in favor of it, but when looked in this light, it does make some more sense.
> 
> I'll have to think about this a bit more.
> Ben Root
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Tue, Dec 11, 2012 at 2:08 PM, Chloe Lewis <ch...@be...> wrote:
> Would it be workable for the default to be proportional to the size of the
> array passed in? (suggested only because I do that myself, when deciding
> how coarse an investigative plot I can get away with.)
>
> &C
>
>
That is pretty much what the PR I was referring to does:
https://github.com/matplotlib/matplotlib/pull/1040
It makes it so that the behavior of both plot_surface and plot_wireframe is
the same in this respect. So, by default, the rstride and cstride would be
1% of the size of your data array. This would make the default for the
recent example be 1, therefore showing every point. I wonder if a
logarithmic default would make sense to better handle large data arrays?
Thoughts?
Ben Root

On Tue, Dec 11, 2012 at 12:17 PM, Ethan Gutmann <eth...@gm...>wrote:
> > This is because the default rstride and cstride arguments is 10, IIRC.
> Since your array is only 12x12, the surface plotting is barely plotting
> anything. Try calling:
> >
> > ax.plot_surface(x, y, a, rstride=1, cstride=1)
>
>
> You know, this has tripped me up a few times too. I don't use
> plot_surface often enough to always remember this, and it is not the first
> parameter I think to check when debugging a program. Is there a reason the
> default rstride and cstride aren't 1 other than possible memory constraints
> for large arrays?
>
> I suppose changing the defaults might break programs that rely on this
> behavior, but if this API ever gets revamped, consider this a request to
> make 1 be the default instead. I would think that the default should be
> that the obvious command "just works" while plots that may require too much
> memory can be tweaked to work faster (I'm assuming that is the reason for
> the default of 10).
>
>
I actually don't know the reason for the defaults (I didn't create
mplot3d), but that has always been my suspicion. There is an existing PR
to change the default behavior to be somewhat "automatic". At the time, I
wasn't really in favor of it, but when looked in this light, it does make
some more sense.
I'll have to think about this a bit more.
Ben Root

> This is because the default rstride and cstride arguments is 10, IIRC. Since your array is only 12x12, the surface plotting is barely plotting anything. Try calling:
> 
> ax.plot_surface(x, y, a, rstride=1, cstride=1)
You know, this has tripped me up a few times too. I don't use plot_surface often enough to always remember this, and it is not the first parameter I think to check when debugging a program. Is there a reason the default rstride and cstride aren't 1 other than possible memory constraints for large arrays? 
I suppose changing the defaults might break programs that rely on this behavior, but if this API ever gets revamped, consider this a request to make 1 be the default instead. I would think that the default should be that the obvious command "just works" while plots that may require too much memory can be tweaked to work faster (I'm assuming that is the reason for the default of 10). 
thanks
Ethan

On Tue, Dec 11, 2012 at 8:25 AM, Degang Wu <sam...@gm...> wrote:
> Hi,
>
> My OS is Mac OS X Lion, and the version of matplotlib is 1.2.0 from
> macport.
>
> Now I have an 2d array
>
> a=array([[ 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ],
> [ 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ],
> [ 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ],
> [ 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ],
> [ 0. , 0. , 0. , 0. ,
> 0. , 6.40312424, 19.02629759, 9.8488578 ,
> 12.16552506, 14. , 0. , 37.01351105],
> [ 0. , 0. , 0. , 0. ,
> 6.40312424, 4.24264069, 1.41421356, 8.54400375,
> 4.47213595, 31.25699922, 0. , 25.70992026],
> [ 0. , 0. , 0. , 0. ,
> 19.02629759, 1.41421356, 17.2626765 , 31.32091953,
> 24.18677324, 43.829214 , 0. , 55.14526272],
> [ 0. , 0. , 0. , 0. ,
> 9.8488578 , 8.54400375, 31.32091953, 35.51056181,
> 40.81666326, 57.27128425, 0. , 84.62860037],
> [ 0. , 0. , 0. , 0. ,
> 12.16552506, 4.47213595, 24.18677324, 40.81666326,
> 43.65775991, 74.24957912, 0. , 112.0044642 ],
> [ 0. , 0. , 0. , 0. ,
> 14. , 31.25699922, 43.829214 , 57.27128425,
> 74.24957912, 0. , 0. , 0. ],
> [ 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ,
> 0. , 0. , 0. , 0. ],
> [ 0. , 0. , 0. , 0. ,
> 37.01351105, 25.70992026, 55.14526272, 84.62860037,
> 112.0044642 , 0. , 0. , 0. ]])
>
> first I plot it (in ipython notebook) using:
>
> coord_max=12
> fig = plt.figure()
> ax = fig.gca(projection='3d')
> x,y=np.meshgrid(np.arange(coord_max),np.arange(coord_max))
> ax.plot_wireframe(x,y,a)
>
> and the plot looks fine.
>
> but if I use plot_surface instead, the plot looks very wrong: the plot is
> zero everywhere except on the boundaries.
>
This is because the default rstride and cstride arguments is 10, IIRC.
Since your array is only 12x12, the surface plotting is barely plotting
anything. Try calling:
ax.plot_surface(x, y, a, rstride=1, cstride=1)
I hope that helps!
Ben Root

Hi,
My OS is Mac OS X Lion, and the version of matplotlib is 1.2.0 from macport.
Now I have an 2d array
a=array([[ 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ],
 [ 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ],
 [ 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ],
 [ 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ],
 [ 0. , 0. , 0. , 0. ,
 0. , 6.40312424, 19.02629759, 9.8488578 ,
 12.16552506, 14. , 0. , 37.01351105],
 [ 0. , 0. , 0. , 0. ,
 6.40312424, 4.24264069, 1.41421356, 8.54400375,
 4.47213595, 31.25699922, 0. , 25.70992026],
 [ 0. , 0. , 0. , 0. ,
 19.02629759, 1.41421356, 17.2626765 , 31.32091953,
 24.18677324, 43.829214 , 0. , 55.14526272],
 [ 0. , 0. , 0. , 0. ,
 9.8488578 , 8.54400375, 31.32091953, 35.51056181,
 40.81666326, 57.27128425, 0. , 84.62860037],
 [ 0. , 0. , 0. , 0. ,
 12.16552506, 4.47213595, 24.18677324, 40.81666326,
 43.65775991, 74.24957912, 0. , 112.0044642 ],
 [ 0. , 0. , 0. , 0. ,
 14. , 31.25699922, 43.829214 , 57.27128425,
 74.24957912, 0. , 0. , 0. ],
 [ 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ,
 0. , 0. , 0. , 0. ],
 [ 0. , 0. , 0. , 0. ,
 37.01351105, 25.70992026, 55.14526272, 84.62860037,
 112.0044642 , 0. , 0. , 0. ]])
first I plot it (in ipython notebook) using:
coord_max=12
fig = plt.figure()
ax = fig.gca(projection='3d')
x,y=np.meshgrid(np.arange(coord_max),np.arange(coord_max))
ax.plot_wireframe(x,y,a)
and the plot looks fine.
but if I use plot_surface instead, the plot looks very wrong: the plot is zero everywhere except on the boundaries.

Dear all,
I checked and it seems that we don't have rc Parameters for colorbar? could
it be desirable?
Chao
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

On Mon, Dec 10, 2012 at 2:45 AM, Phil Elson <pel...@gm...> wrote:
> Hi Joe,
>
> Thanks for bringing this up, it is certainly valuable to highlight this on
> the mailinglist. As you say, the change is hard to spot and, I agree, makes
> library code supporting v1.1.1 and v1.2 harder than one would like.
> Typically, anything which is going to break core APIs (even slightly)
> should be documented under the "API Changes" page here
> http://matplotlib.org/api/api_changes.html#changes-in-1-2-x .
Thanks! I wasn't aware of that page! (and it does a very nice job of
documenting the changes!)
> You will find there were quite a few changes made relating to transforms
> which I think is entirely my doing, so at least we know who the guilty
> party is :-)
>
> Thanks for spotting the example failure - I split these changes over many
> separate pull requests and did scan the gallery for any noticeable changes,
> but this one must have slipped the net.
>
> If you're still having problems with using the newer transform API, please
> shout and I'd be happy to have a look for you.
>
Will do, thanks for the offer!
>
> All the best,
>
> Phil
>
>
> On 9 December 2012 22:10, Joe Kington <jof...@gm...> wrote:
>
>> Hi folks,
>>
>> At some point transforms.Transform was slightly refactored.
>> (Particularly, this commit:
>> https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c) This changed what methods need to be overridden when subclassing
>> Transform.
>>
>> All in all, it seems like a very sensible change, but it led to some very
>> hard-to-find bugs in some of my code that subclasses transforms.Transform.
>> I thought I would mention it on the mailing list for anyone else that uses
>> custom projections. Forgive me if it was mentioned earlier and I just
>> didn't notice.
>>
>> With versions 1.1.x and older, one had to directly implement a transformmethod when subclassingtransforms.Transform,
>> otherwise a NotImplemented error would be raised.
>>
>> With versions 1.2.x and newer, the preferred way appears to be to
>> implement things in a separate transform_affine or transform_non_affinemethod and not explicitly implement a
>> transform method.
>>
>> If you implement the non-affine portion directly in the transform method
>> without overriding transform_non_affine, it leads to strange drawing
>> bugs with v1.2 that did not occur with older versions. (For example, this
>> broke one of the examples in the gallery between 1.1. and 1.2:
>> http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html
>> http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html. I just submitted a pull request to update the example, by the way.)
>>
>> On the other hand, for compatibility with versions 1.1 and older, you
>> have to explicitly implement the transform method as well, otherwise
>> you'll get the NotImplemented error.
>>
>> Therefore, now one needs to explicitly implement *_both_* the
>> transform_non_affine and transform methods of a custom non-affine
>> transform for compatibility with 1.1 and older as well as 1.2 and newer.
>>
>> Similarly, one needs to implement* _both_ *the transform_path_non_affineand the
>> transform_path methods for compatibility with newer and older versions
>> of matplotlib.
>>
>> Arguably, it should have always been done this way, but based onexamples/api/custom_projection_example.py,
>> I (and I suspect many other people as well) implemented the transform
>> directly as the transform method when subclassing Transform, instead of
>> separately in a transform_affine or transform_non_affine method.
>>
>> Is this a large enough change to warrant a mention in the changelog? (On
>> the other hand, the mailing list probably gets a lot more eyes on it than
>> the changelog...)
>>
>> Thanks!
>> -Joe
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>