matplotlib-users Mailing List for matplotlib (Page 6)

http://housesforsells.com/wp-admin/makoler.html?tebv=vzbeba

On 8/20/12 10:26 PM, Scott Henderson wrote:
> I'm trying to efficiently get the distances of all points on a map to a
> specified point. If the map is in projected coordinates, what is the
> best way of going about this? Is there is a 'standard' way to get the
> distance between points through internal basemap functions? After some
> scrounging around what I have below works for individual points, but is
> there a way to avoid the big for loop?
>
> Any advice would be appreciated.
> Thanks.

Scott:  The pyproj Geod methods don't take numpy arrays, as you 
discovered. It's very accurate and robust, but slow since you have to 
loop over the points.  Since you are assuming the earth is a perfect 
sphere you could use the less accurate Haversine formula:

# function to compute great circle distance between point lat1 and lon1 
and arrays of points
# given by lons, lats
def get_dist(lon1,lons,lat1,lats):
     # great circle distance.
     arg = 
np.sin(lat1)*np.sin(lats)+np.cos(lat1)*np.cos(lats)*np.cos(lon1-lons)
     arg = np.where(np.fabs(arg) < 1., arg, 0.999999)
     return np.arccos(arg)

-Jeff

>
>
> # --------------------------------------
> from mpl_toolkits.basemap import Basemap
> from mpl_toolkits.basemap import pyproj
> import numpy as np
> import matplotlib.pyplot as plt
>
> fig = plt.figure()
> ax = fig.add_subplot(111)
>
> LL = (-69, -26)
> UR = (-66, -21)
> map = Basemap(projection='merc',
>                  llcrnrlat=LL[1],
>                  urcrnrlat=UR[1],
>                  llcrnrlon=LL[0],
>                  urcrnrlon=UR[0],
>                  resolution='i',
>                  suppress_ticks=False,
>                  ax=ax)
>
> lons, lats, xs, ys = map.makegrid(200, 200, returnxy=True)
> lon1, lat1 = (-67.28, -23.78)
>
> gc = pyproj.Geod(a=map.rmajor, b=map.rminor)
> #azis12, azis21, distances = gc.inv(lon1,lat1,lons,lats) #doesn't work
> with vectors or matrices?
> distances = np.zeros(lons.size)
> for i, (lon, lat) in enumerate(zip(lons.flatten(),lats.flatten())):
>       azi12, azi21, distances[i] = gc.inv(lon1,lat1,lon,lat)
> distances = distances.reshape(200,200) / 1000.0 #in km
>
> # Plot perimeters of equal distance
> levels = [50] #[50,100,150]
> map.drawcountries()
> x1,y1 = map(lon1,lat1)
> map.plot(x1,y1,'m*')
> cs = map.contour(xs, ys, distances, levels)
>

I'm trying to efficiently get the distances of all points on a map to a 
specified point. If the map is in projected coordinates, what is the 
best way of going about this? Is there is a 'standard' way to get the 
distance between points through internal basemap functions? After some 
scrounging around what I have below works for individual points, but is 
there a way to avoid the big for loop?

Any advice would be appreciated.
Thanks.


# --------------------------------------
from mpl_toolkits.basemap import Basemap
from mpl_toolkits.basemap import pyproj
import numpy as np
import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(111)

LL = (-69, -26)
UR = (-66, -21)
map = Basemap(projection='merc',
                llcrnrlat=LL[1],
                urcrnrlat=UR[1],
                llcrnrlon=LL[0],
                urcrnrlon=UR[0],
                resolution='i',
                suppress_ticks=False,
                ax=ax)

lons, lats, xs, ys = map.makegrid(200, 200, returnxy=True)
lon1, lat1 = (-67.28, -23.78)

gc = pyproj.Geod(a=map.rmajor, b=map.rminor)
#azis12, azis21, distances = gc.inv(lon1,lat1,lons,lats) #doesn't work 
with vectors or matrices?
distances = np.zeros(lons.size)
for i, (lon, lat) in enumerate(zip(lons.flatten(),lats.flatten())):
     azi12, azi21, distances[i] = gc.inv(lon1,lat1,lon,lat)
distances = distances.reshape(200,200) / 1000.0 #in km

# Plot perimeters of equal distance
levels = [50] #[50,100,150]
map.drawcountries()
x1,y1 = map(lon1,lat1)
map.plot(x1,y1,'m*')
cs = map.contour(xs, ys, distances, levels)

-- 
---------------
Scott T. Henderson
http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html

On 8/20/12 8:21 PM, Scott Henderson wrote:
> On Mon 20 Aug 2012 06:29:01 PM EDT, Jeff Whitaker wrote:
>> On 8/20/12 4:41 PM, Scott Henderson wrote:
>>> I'm having trouble with transform_scalar() and imshow() with basemap.
>>> Essential I have data from satellite tracks that are either smaller
>>> or larger than the map extent, so I don't want to use
>>> Basemap.imshow() which sets the 'extent' keyword automatically.
>>>
>>> I tried following the following suggestion, but I can't get things to
>>> line up..
>>> http://comments.gmane.org/gmane.comp.python.matplotlib.general/25085
>>>
>>> I suspect I've done something wrong in the code below?:
>>
>> Scott:  If you use the pcolormesh or contourf Basemap methods (instead
>> of imshow), you can specify the map projection coordinates of your
>> data and it will be plotted correctly (whether or not it covers the
>> whole map projection region).
>>
>> -Jeff
>>>
>>>
>>> # -------------------------------
>>> from mpl_toolkits.basemap import Basemap
>>> import matplotlib.pyplot as plt
>>>
>>> LL = (-68, -26)
>>> UR = (-66, -21)
>>> bmap = Basemap(projection='merc',
>>>                llcrnrlat=LL[1],
>>>                urcrnrlat=UR[1],
>>>                llcrnrlon=LL[0],
>>>                urcrnrlon=UR[0],
>>>                resolution='i',
>>>                suppress_ticks=False,
>>>                ax=ax)
>>> bmap.drawcountries(linewidth=1)
>>>
>>> # Overlay image with extents that don't match map boundaries
>>> nLon, nLat = image.shape
>>> LL = (-69.915, -31.161)
>>> UR = (-65.075, -17.334)
>>> dy = -0.006666664
>>> lats = UR[1] + dy * np.arange(nLat)
>>> extent = (LL[0], UR[0], LL[1], UR[1])
>>> nx = nLon; ny = nLat
>>> image_xy = bmap.transform_scalar(image, lons, lats[::-1], nx, ny)
>>> x, y = bmap(extent[:2],extent[2:])
>>> extent_xy = (x[0], x[1], y[0], y[1])
>>> im = plt.imshow(image_xy, extent=extent_xy)
>>>
>>>
>>>
>>> -- 
>>> ---------------
>>> Scott T. Henderson
>>> http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html
>>>
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. 
>>> Discussions
>>> will include endpoint security, mobile security and the latest in 
>>> malware
>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>> -- 
>> 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
>
> Thanks Jeff,
>
> pcolormesh seems to get the georeferencing correct. Why is it that 
> imshow doesn't work? The trouble with pcolormesh is that it's much 
> slower, the file sizes get bigger and when zooming into detailed 
> regions the pixels edges show up even when I set edgecolors='None'. 
> I've attached a few screenshots for comparison.

Scott: That's weird - I don't know why the edges show.  The only thing 
you're getting with imshow is interpolation.  To use imshow, you need to 
have a grid that exactly fits the map projection region.  You could do 
this with transform_scalar using the keyword masked=True, which will 
assign missing values to grid points outside the range of the input 
grid.  When you plot with imshow, these areas should just show up as 
transparent.

-Jeff
>
> # New version:
> # -------------------
> data_xy, x, y = bmap.transform_scalar(data[::-1], lons, lats[::-1], 
> nx, ny, returnxy=True)
> data_xym =  np.ma.array(data_xy, mask=np.isnan(data_xy))
> im = bmap.pcolormesh(x,y,data_xym,
>                     shading='flat', #'gouraud'
>                     edgecolors='None',
>                     alpha=alpha,
>                     vmin=cmin,
>                     vmax=cmax)
> plt.colorbar(im)
>
>
> # Different figures attached
>
>
>
> -- 
> ---------------
> Scott T. Henderson
> http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html
>

Hmm, I just found out that if I change path.Path.contains_point to use
"point_on_path" instead of "point_in_path", the containment tests work
properly.  I'm not that familiar with the path code...is the difference
that one is testing for polygonal insideness, and one is testing for
literally being on the "stroke"?  If so, do we have to make sure that the
proper one is called if there are no polygons involved in the path?

On Mon, Aug 20, 2012 at 9:28 PM, Daniel Hyams <dh...@gm...> wrote:

> I've run into a strange problem with contains() on an arrow; there is a
> large area to the left of the arrow that insists that it is contained
> within the arrow.  Small runnable sample attached.
>
> I've looked at the path for the arrow, and it looks fine to me.  I even
> went so far as to hack a STOP onto the end of the path, but that resulted
> in the same behavior.
>
> Can anyone else confirm this behavior?  matplotlib 1.1.1 is what I'm
> using.  Seen on both Windows, Linux, and OSX.
>
> --
> Daniel Hyams
> dh...@gm...
>



-- 
Daniel Hyams
dh...@gm...

I've run into a strange problem with contains() on an arrow; there is a
large area to the left of the arrow that insists that it is contained
within the arrow.  Small runnable sample attached.

I've looked at the path for the arrow, and it looks fine to me.  I even
went so far as to hack a STOP onto the end of the path, but that resulted
in the same behavior.

Can anyone else confirm this behavior?  matplotlib 1.1.1 is what I'm using.
 Seen on both Windows, Linux, and OSX.

-- 
Daniel Hyams
dh...@gm...

On 8/20/12 4:41 PM, Scott Henderson wrote:
> I'm having trouble with transform_scalar() and imshow() with basemap. 
> Essential I have data from satellite tracks that are either smaller or 
> larger than the map extent, so I don't want to use Basemap.imshow() 
> which sets the 'extent' keyword automatically.
>
> I tried following the following suggestion, but I can't get things to 
> line up..
> http://comments.gmane.org/gmane.comp.python.matplotlib.general/25085
>
> I suspect I've done something wrong in the code below?:

Scott:  If you use the pcolormesh or contourf Basemap methods (instead 
of imshow), you can specify the map projection coordinates of your data 
and it will be plotted correctly (whether or not it covers the whole map 
projection region).

-Jeff
>
>
> # -------------------------------
> from mpl_toolkits.basemap import Basemap
> import matplotlib.pyplot as plt
>
> LL = (-68, -26)
> UR = (-66, -21)
> bmap = Basemap(projection='merc',
>                llcrnrlat=LL[1],
>                urcrnrlat=UR[1],
>                llcrnrlon=LL[0],
>                urcrnrlon=UR[0],
>                resolution='i',
>                suppress_ticks=False,
>                ax=ax)
> bmap.drawcountries(linewidth=1)
>
> # Overlay image with extents that don't match map boundaries
> nLon, nLat = image.shape
> LL = (-69.915, -31.161)
> UR = (-65.075, -17.334)
> dy = -0.006666664
> lats = UR[1] + dy * np.arange(nLat)
> extent = (LL[0], UR[0], LL[1], UR[1])
> nx = nLon; ny = nLat
> image_xy = bmap.transform_scalar(image, lons, lats[::-1], nx, ny)
> x, y = bmap(extent[:2],extent[2:])
> extent_xy = (x[0], x[1], y[0], y[1])
> im = plt.imshow(image_xy, extent=extent_xy)
>
>
>
> -- 
> ---------------
> Scott T. Henderson
> http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users


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

I have been generating boxplots with matplotlib 1.1.0 and the plots look 
great.

How can I find the median, fliers, etc. that are used for the boxplots? 
In general, where can I find documentation on how to get these data from 
a boxplot?

Best regards!
[Using matplotlib 1.1.0 with Python 2.7.3 on a Windows Vista 32-bit 
platform]

I'm having trouble with transform_scalar() and imshow() with basemap. 
Essential I have data from satellite tracks that are either smaller or 
larger than the map extent, so I don't want to use Basemap.imshow() 
which sets the 'extent' keyword automatically.

I tried following the following suggestion, but I can't get things to 
line up..
http://comments.gmane.org/gmane.comp.python.matplotlib.general/25085

I suspect I've done something wrong in the code below?:


# -------------------------------
from mpl_toolkits.basemap import Basemap
import matplotlib.pyplot as plt

LL = (-68, -26)
UR = (-66, -21)
bmap = Basemap(projection='merc',
                llcrnrlat=LL[1],
                urcrnrlat=UR[1],
                llcrnrlon=LL[0],
                urcrnrlon=UR[0],
                resolution='i',
                suppress_ticks=False,
                ax=ax)
bmap.drawcountries(linewidth=1)

# Overlay image with extents that don't match map boundaries
nLon, nLat = image.shape
LL = (-69.915, -31.161)
UR = (-65.075, -17.334)
dy = -0.006666664
lats = UR[1] + dy * np.arange(nLat)
extent = (LL[0], UR[0], LL[1], UR[1])
nx = nLon; ny = nLat
image_xy = bmap.transform_scalar(image, lons, lats[::-1], nx, ny)
x, y = bmap(extent[:2],extent[2:])
extent_xy = (x[0], x[1], y[0], y[1])
im = plt.imshow(image_xy, extent=extent_xy)



-- 
---------------
Scott T. Henderson
http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html

Thanks for this.  It's been a long-standing bug that text is handled by 
bounding box, but it's been difficult to find a way forward without 
breaking backward compatibility.

I've filed an issue for this here.

https://github.com/matplotlib/matplotlib/issues/1121

It may be, in the long run, that we want to fix the other backends to 
use baselines rather than fixing Cairo to use bounding boxes.

Mike

On 08/20/2012 01:07 PM, Freddie Witherden wrote:
> On 19/08/12 23:48, Freddie Witherden wrote:
>> Hello,
>>
>> Using the Cairo backend with the following snippet:
>>
>> from matplotlib.figure import Figure
>> from matplotlib.artist import setp
>> from matplotlib.backends.backend_agg import FigureCanvasAgg
>> from matplotlib.backends.backend_cairo import FigureCanvasCairo
>> import numpy as np
>>
>> fig = Figure()
>> ax1 = fig.add_axes([0.1, 0.1, 0.8, 0.8])
>> x = np.arange(0, 10, 0.2)
>>
>> ax1.plot(x, np.sin(x))
>> ax1.xaxis.set_ticklabels(['Apr', 'Jul', 'Oct', '\'12', 'Apr', 'Jul'])
>> setp(ax1.yaxis.get_ticklabels(), visible=False)
>>
>> FigureCanvasCairo(fig).print_figure('test.png')
>>
>>
>> Results in the x-axis tick labels being significantly displaced.
>> Specifically, "Oct" and "'12" are positioned far closer to the axis than
>> either "Apr" or "Jul".
>>
>> With the AGG backend all of the labels are roughly aligned to the
>> baseline of the font -- give or take a pixel.
>>
>> I have observed this on a Gentoo and Debian system, both running 1.1.1,
>> albeit with different default fonts.
>>
>> Although I am not completely sure it appears as if a label contains a
>> glyph that extends below the baseline, e.g. 'p' or 'J', that the label
>> is forced away from the axis.
>>
>> Can anyone suggest a workaround for this (or explain where I am going
>> wrong)?
> I have been looking into this issue today and it /appears/ to be because
> the Cairo backend -- or more precisely -- cairo::show_text method takes
> a y-coordinate relative to the baseline.  This makes sense given that
> the descent of a font is a well-defined concept in Cairo (and can be
> extracted via the font_extents method).  However, as far as I can tell,
> matplotlib expects the draw_text method to provide an absolute y-coordinate.
>
> The result is that any text with a descender is pushed downwards
> (assuming a default rotation angle).  This can be visualized by
>
> setp(ax1.xaxis.get_ticklabels(), backgroundcolor='r')
>
> The solution is to have the draw_text method account for any descenders.
>   After a bit of juggling the relevant portion of draw_text becomes:
>
>             ctx = gc.ctx
>             ctx.new_path()
>             #ctx.move_to (x, y)
>             ctx.select_font_face (prop.get_name(),
>                                   self.fontangles [prop.get_style()],
>                                   self.fontweights[prop.get_weight()])
>
>             size = prop.get_size_in_points() * self.dpi / 72.0
>             ctx.set_font_size(size)
>
>             y_bearing, w, h = ctx.text_extents(s.encode("utf-8"))[1:4]
>             ctx.move_to(x, y - (h + y_bearing))
>
>             ctx.save()
>             if angle:
>                ctx.rotate (-angle * np.pi / 180)
>             #ctx.set_font_size (size)
>             ctx.show_text (s.encode("utf-8"))
>             ctx.restore()
>
> where commented lines highlight modifications (specifically, the
> movement of the set_font_size and move_to calls).  In my limited testing
> this fixes the aforementioned issues.  Discrepancies between baselines
> are now limited to +/- 1px (the same as with the AGG backend).
> Eliminating these one pixel misalignments is rather difficult so long as
> text rendering is performed relative to the bounding box as opposed to a
> baseline.
>
> Regards, Freddie.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 19/08/12 23:48, Freddie Witherden wrote:
> Hello,
> 
> Using the Cairo backend with the following snippet:
> 
> from matplotlib.figure import Figure
> from matplotlib.artist import setp
> from matplotlib.backends.backend_agg import FigureCanvasAgg
> from matplotlib.backends.backend_cairo import FigureCanvasCairo
> import numpy as np
> 
> fig = Figure()
> ax1 = fig.add_axes([0.1, 0.1, 0.8, 0.8])
> x = np.arange(0, 10, 0.2)
> 
> ax1.plot(x, np.sin(x))
> ax1.xaxis.set_ticklabels(['Apr', 'Jul', 'Oct', '\'12', 'Apr', 'Jul'])
> setp(ax1.yaxis.get_ticklabels(), visible=False)
> 
> FigureCanvasCairo(fig).print_figure('test.png')
> 
> 
> Results in the x-axis tick labels being significantly displaced.
> Specifically, "Oct" and "'12" are positioned far closer to the axis than
> either "Apr" or "Jul".
> 
> With the AGG backend all of the labels are roughly aligned to the
> baseline of the font -- give or take a pixel.
> 
> I have observed this on a Gentoo and Debian system, both running 1.1.1,
> albeit with different default fonts.
> 
> Although I am not completely sure it appears as if a label contains a
> glyph that extends below the baseline, e.g. 'p' or 'J', that the label
> is forced away from the axis.
> 
> Can anyone suggest a workaround for this (or explain where I am going
> wrong)?

I have been looking into this issue today and it /appears/ to be because
the Cairo backend -- or more precisely -- cairo::show_text method takes
a y-coordinate relative to the baseline.  This makes sense given that
the descent of a font is a well-defined concept in Cairo (and can be
extracted via the font_extents method).  However, as far as I can tell,
matplotlib expects the draw_text method to provide an absolute y-coordinate.

The result is that any text with a descender is pushed downwards
(assuming a default rotation angle).  This can be visualized by

setp(ax1.xaxis.get_ticklabels(), backgroundcolor='r')

The solution is to have the draw_text method account for any descenders.
 After a bit of juggling the relevant portion of draw_text becomes:

           ctx = gc.ctx
           ctx.new_path()
           #ctx.move_to (x, y)
           ctx.select_font_face (prop.get_name(),
                                 self.fontangles [prop.get_style()],
                                 self.fontweights[prop.get_weight()])

           size = prop.get_size_in_points() * self.dpi / 72.0
           ctx.set_font_size(size)

           y_bearing, w, h = ctx.text_extents(s.encode("utf-8"))[1:4]
           ctx.move_to(x, y - (h + y_bearing))

           ctx.save()
           if angle:
              ctx.rotate (-angle * np.pi / 180)
           #ctx.set_font_size (size)
           ctx.show_text (s.encode("utf-8"))
           ctx.restore()

where commented lines highlight modifications (specifically, the
movement of the set_font_size and move_to calls).  In my limited testing
this fixes the aforementioned issues.  Discrepancies between baselines
are now limited to +/- 1px (the same as with the AGG backend).
Eliminating these one pixel misalignments is rather difficult so long as
text rendering is performed relative to the bounding box as opposed to a
baseline.

Regards, Freddie.

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
    text="#000000">
    <pre wrap="">Hello

I have set rcParams['axes.color_cycle'] = ['r','Blue',&nbsp;&nbsp;&nbsp; 'g', 'm','c','k',&nbsp;&nbsp;&nbsp; 'Tomato... ] to a long list of colors.
Later in the program I have many figure() commands floowed by plot commands.
The color sequence does not repateat itself for each new figure

How do I reset the sequence?

Thanks

Ilan</pre>
  </body>
</html>

Thank you for your help, but I have already read this link.

I am using zoomed_inset_axes, but the default position overlaps the yticks
and the parent axe ticks, so I am trying:
axins = zoomed_inset_axes(ax,
3,bbox_to_anchor(0.5,1),bbox_transform=ax.figure.transFigure, loc=2)

but it doesn't work.
I have also tried:
box = axins.get_position()
axins.set_position([box.x0+0.5, box.y0,box.width, box.height])

and the position is changed (doing a print I check the differences), but
not in the plot.

I guess I am doing something wrong, but I can't tell.

Any help would be really useful.

Cheers!
Illa

2012/8/9 Benjamin Root <ben...@ou...>

>
> On Wed, Aug 8, 2012 at 7:03 AM, darkside <in....@gm...>wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: darkside <in....@gm...>
>> Date: 2012/8/2
>> Subject: Re: [Matplotlib-users] zoomed in detail box
>> To: Jae-Joon Lee <lee...@gm...>
>>
>>
>> Hi everyone!
>>
>> I'm also trying to do a detailed zoomed area of my plot, but I can't
>> manage to put the box in the position I want, bbox_to_anchor didn't work in
>> my case:
>>
>> axins =
>> zoomed_inset_axes(ax,3,loc=2,bbox_to_anchor=(0,0,0.5,0.5),bbox_transform=ax.transAxes)
>>
>> This bbox_to_anchor tuple is just an example. I only want to move the
>> zoomed box a little to the right, since the ticklabels overlap.
>>
>> Any idea?
>>
>> I really appreciate your help!
>>
>>
> Is this what you are looking for?
>
>
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#insetlocator
>
> Cheers!
> Ben Root
>
>

I've filed an issue for this here:

https://github.com/matplotlib/matplotlib/issues/1110

Mike

On 08/19/2012 05:55 PM, Eric Firing wrote:
> On 2012/08/19 10:31 AM, Christopher Graves wrote:
>> Hi
>>
>>
>> I do not think this is the expected behavior. First, run the following:
>>
>>
>> from pylab import *
>>
>> plot([0,3],[0.2,0.7])
>>
>> ax1 = gca()
>>
>> ax1.set_yscale('log')
>>
>> gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$'))
>>
>> #ax2 = ax1.twiny()
>>
>> #ax2.set_xlim(ax1.get_xlim())
>>
>> show()
>>
>>
>> You will see that the y-axis is log10rithmic and axis labels are 0.1 and
>> 1 rather than 10^-1 and 10^0, due to the use of set_major_formatter().
>>
>>
>> Now uncomment the 2 commented lines and run it again. It seems that upon
>> applying a twiny(), the set_major_formatter() action is removed and the
>> y-axis is now displayed as 10^-1 and 10^0. Or more likely, the y-axis is
>> "overwritten" with a new y-axis present in ax2. One can add another
>> gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$')) before the
>> show() and it works as intended. However, it seems like unexpected
>> behavior to "lose" the formatting when twinning the axis to add a
>> secondary x-axis. Any advice or agreement that this could be a bug?
> Yes, I think this is a bug.
>
> Eric
>
>>
>> Best,
>>
>> Chris
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello,

Using the Cairo backend with the following snippet:

from matplotlib.figure import Figure
from matplotlib.artist import setp
from matplotlib.backends.backend_agg import FigureCanvasAgg
from matplotlib.backends.backend_cairo import FigureCanvasCairo
import numpy as np

fig = Figure()
ax1 = fig.add_axes([0.1, 0.1, 0.8, 0.8])
x = np.arange(0, 10, 0.2)

ax1.plot(x, np.sin(x))
ax1.xaxis.set_ticklabels(['Apr', 'Jul', 'Oct', '\'12', 'Apr', 'Jul'])
setp(ax1.yaxis.get_ticklabels(), visible=False)

FigureCanvasCairo(fig).print_figure('test.png')


Results in the x-axis tick labels being significantly displaced.
Specifically, "Oct" and "'12" are positioned far closer to the axis than
either "Apr" or "Jul".

With the AGG backend all of the labels are roughly aligned to the
baseline of the font -- give or take a pixel.

I have observed this on a Gentoo and Debian system, both running 1.1.1,
albeit with different default fonts.

Although I am not completely sure it appears as if a label contains a
glyph that extends below the baseline, e.g. 'p' or 'J', that the label
is forced away from the axis.

Can anyone suggest a workaround for this (or explain where I am going
wrong)?

Regards, Freddie.

I'm not aware of an rc param for this. The relevant github issue:
https://github.com/matplotlib/matplotlib/issues/461

Regards,

Phil



On 19 August 2012 21:27, Christopher Graves <chr...@gm...>wrote:

> Using matplotlib 1.1.1.
> If one runs the following code:
>
> from pylab import *
>
> plot([19.185,19.187],[0.0009,0.0011],'b.')
>
> show()
>
> The x-axis is labelled 0.0005, 0.0010, 0.0015 etc  +1.9184e1
>
> This is unreadable and does not seem like a good default behavior!
>
> One can add
> gca().xaxis.set_major_formatter(FormatStrFormatter('$%g$'))
> before "show()"
> to obtain an x-axis labelled 19.1845, 19.185, 19.1855, etc.
>
> Can one change the default label formatting behavior with a matplotlib rc?
> However, I would not want to e.g. override the 10^-3, 10^-2, etc when using
> log axes.
>
> Best regards,
> Chris
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

On 2012/08/19 10:31 AM, Christopher Graves wrote:
> Hi
>
>
> I do not think this is the expected behavior. First, run the following:
>
>
> from pylab import *
>
> plot([0,3],[0.2,0.7])
>
> ax1 = gca()
>
> ax1.set_yscale('log')
>
> gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$'))
>
> #ax2 = ax1.twiny()
>
> #ax2.set_xlim(ax1.get_xlim())
>
> show()
>
>
> You will see that the y-axis is log10rithmic and axis labels are 0.1 and
> 1 rather than 10^-1 and 10^0, due to the use of set_major_formatter().
>
>
> Now uncomment the 2 commented lines and run it again. It seems that upon
> applying a twiny(), the set_major_formatter() action is removed and the
> y-axis is now displayed as 10^-1 and 10^0. Or more likely, the y-axis is
> "overwritten" with a new y-axis present in ax2. One can add another
> gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$')) before the
> show() and it works as intended. However, it seems like unexpected
> behavior to "lose" the formatting when twinning the axis to add a
> secondary x-axis. Any advice or agreement that this could be a bug?

Yes, I think this is a bug.

Eric

>
>
> Best,
>
> Chris
>

Hi


I do not think this is the expected behavior. First, run the following:


from pylab import *

plot([0,3],[0.2,0.7])

ax1 = gca()

ax1.set_yscale('log')

gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$'))

#ax2 = ax1.twiny()

#ax2.set_xlim(ax1.get_xlim())

show()


You will see that the y-axis is log10rithmic and axis labels are 0.1 and 1
rather than 10^-1 and 10^0, due to the use of set_major_formatter().


Now uncomment the 2 commented lines and run it again. It seems that upon
applying a twiny(), the set_major_formatter() action is removed and the
y-axis is now displayed as 10^-1 and 10^0. Or more likely, the y-axis is
"overwritten" with a new y-axis present in ax2. One can add another
gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$')) before the
show() and it works as intended. However, it seems like unexpected behavior
to "lose" the formatting when twinning the axis to add a secondary x-axis.
Any advice or agreement that this could be a bug?


Best,

Chris

Using matplotlib 1.1.1.
If one runs the following code:

 from pylab import *

plot([19.185,19.187],[0.0009,0.0011],'b.')

show()

The x-axis is labelled 0.0005, 0.0010, 0.0015 etc  +1.9184e1

This is unreadable and does not seem like a good default behavior!

One can add
gca().xaxis.set_major_formatter(FormatStrFormatter('$%g$'))
before "show()"
to obtain an x-axis labelled 19.1845, 19.185, 19.1855, etc.

Can one change the default label formatting behavior with a matplotlib rc?
However, I would not want to e.g. override the 10^-3, 10^-2, etc when using
log axes.

Best regards,
Chris

2012/8/19 Peter Combs <pco...@gm...>:
> Hi all,
> I'm trying to have a Text object with a fancy box, as in this example:
> http://matplotlib.sourceforge.net/mpl_examples/pylab_examples/fancybox_demo2.py
> .  However, the key difference is that I want to have the box (in my case,
> I'm interested in an RArrow) be a specified width (in units of the plot),
> rather than just fitting it to the text I've given (crude ascii art below).
> The following seems not to work:
>
>
> ax = gca()
> txtobj = ax.text(0, -.1 * yrange, 'text',
>                      bbox=dict(boxstyle='rarrow'))
> txtobj.get_bbox_patch().set_
> width(SIZE_IM_INTERESTED_IN)
> draw_if_interactive()
>
> It seems like draw()ing the text object will reset the size of the BBox...
> Any idea how to fix this? At the moment, I'm experimenting with continually
> drawing, polling the get_width() method, and when it's too small, adding in
> spaces around the text field, but that seems both not to work reliably, and
> be an incredibly boneheaded way to go about it.

Not ideal but better:

from pyplot import *
subplot(111)
text(0.1, 0.3, 'XXXXXXXXXXXXXXX', alpha=0, bbox=dict(boxstyle='rarrow'))
text(0.1, 0.3, 'short')
text(0.1, 0.6, 'XXXXXXXXXXXXXXX', alpha=0, bbox=dict(boxstyle='rarrow'))
text(0.1, 0.6, 'looooooooooong')
show()

Goyo

Hello,

With matplotlib 1.1.1 on Gentoo I have been observing some strange
behaviour relating to ax.legend(frameon=False) and
print_figure(bbox_inches='tight'):

from matplotlib.figure import Figure
from matplotlib.artist import setp
from matplotlib.backends.backend_cairo import FigureCanvasCairo
import numpy as np

fig = Figure()
ax1 = fig.add_axes([0.1, 0.5, 0.8, 0.4])
ax2 = fig.add_axes([0.1, 0.1, 0.8, 0.4], sharex=ax1)
x = np.arange(0, 10, 0.2)
for ax, y in zip((ax1, ax2), (np.cos(x), np.sin(x))):
    ax.plot(x, y, label='A line')
    ax.spines['left'].set_visible(False)
    ax.yaxis.tick_right()

ax1.set_xlim((1,9))
ax1.legend(loc='upper left', frameon=False)

setp(ax1.xaxis.get_ticklabels(), visible=False)
FigureCanvasCairo(fig).print_figure('test.png', bbox_inches='tight')


On my system the resulting image has a large left margin.  However, if I
change frameon to True then the left margin is cropped (as expected).
Hence setting frameon=False for a legend appears to break tight bounding
boxes.

A similar situation occurs if legend().draw_frame(False) is used to hide
the legend frame.  My current work around is to use
legend().get_frame().set_visible(False) which results in the correct
bounding box.

I have also reproduced this using the AGG backend.

Regards, Freddie.

P.S. On an unrelated note are there any more performant alternatives to
bbox_inches='tight'?  It almost doubles the rendering time of some more
complex plots.

Another, very hacky but quick way to do this, is to put spaces around your
text until the arrow is the size you desire:

"         your text           "

and if you want the arrow to expand upward and downward, put in return
characters (I told you it was crude ;))

On Sun, Aug 19, 2012 at 2:41 AM, Peter Combs <pco...@gm...> wrote:

> Hi all,
> I'm trying to have a Text object with a fancy box, as in this example:
> http://matplotlib.sourceforge.net/mpl_examples/pylab_examples/fancybox_demo2.py.  However, the key difference is that I want to have the box (in my case,
> I'm interested in an RArrow) be a specified width (in units of the plot),
> rather than just fitting it to the text I've given (crude ascii art
> below).  The following seems not to work:
>
>
> ax = gca()
> txtobj = ax.text(0, -.1 * yrange, 'text',
>                      bbox=dict(boxstyle='rarrow'))
> txtobj.get_bbox_patch().set_
> width(SIZE_IM_INTERESTED_IN)
> draw_if_interactive()
>
> It seems like draw()ing the text object will reset the size of the BBox...
> Any idea how to fix this? At the moment, I'm experimenting with continually
> drawing, polling the get_width() method, and when it's too small, adding in
> spaces around the text field, but that seems both not to work reliably, and
> be an incredibly boneheaded way to go about it.
>
> I'm using matplotlib v. 1.1.0 if that makes a difference.
>
>
> --------------\
> |    text      >
> --------------/
> not
> ------\
> | text >
> ------/
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>


-- 
Daniel Hyams
dh...@gm...

I had to deal with this lately, and there is no current way to do what you
want without patching the MPL source.  I have a patch for it, but it does
not behave well enough to use in the general sense....and you have target
the correct code, the lack of flexibility lies in the Text._draw_bbox
function.

I'm afraid that you will have to create the FancyBboxPatch (the arrow)
directly, size it and place it, and then create some text (with no box) to
go inside.

On Sun, Aug 19, 2012 at 2:41 AM, Peter Combs <pco...@gm...> wrote:

> Hi all,
> I'm trying to have a Text object with a fancy box, as in this example:
> http://matplotlib.sourceforge.net/mpl_examples/pylab_examples/fancybox_demo2.py.  However, the key difference is that I want to have the box (in my case,
> I'm interested in an RArrow) be a specified width (in units of the plot),
> rather than just fitting it to the text I've given (crude ascii art
> below).  The following seems not to work:
>
>
> ax = gca()
> txtobj = ax.text(0, -.1 * yrange, 'text',
>                      bbox=dict(boxstyle='rarrow'))
> txtobj.get_bbox_patch().set_
> width(SIZE_IM_INTERESTED_IN)
> draw_if_interactive()
>
> It seems like draw()ing the text object will reset the size of the BBox...
> Any idea how to fix this? At the moment, I'm experimenting with continually
> drawing, polling the get_width() method, and when it's too small, adding in
> spaces around the text field, but that seems both not to work reliably, and
> be an incredibly boneheaded way to go about it.
>
> I'm using matplotlib v. 1.1.0 if that makes a difference.
>
>
> --------------\
> |    text      >
> --------------/
> not
> ------\
> | text >
> ------/
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>


-- 
Daniel Hyams
dh...@gm...

2012/8/17 mgurling <mag...@gm...>:
> I've attached 2.py and 3.py which differ only in how many bars are graphed.
> The "nudge" variable was intended to move the left-most bar away from
> the y-axis.

Better use xlim to move the y-axis away from the bar:

a = [20, 35]
nudge = 0.2
ind = np.arange(2) + nudge
width = 0.30
bar(ind, a, width)
xlim(left=0)

Goyo

Hi all,
I'm trying to have a Text object with a fancy box, as in this example:
http://matplotlib.sourceforge.net/mpl_examples/pylab_examples/fancybox_demo2.py.
 However, the key difference is that I want to have the box (in my
case,
I'm interested in an RArrow) be a specified width (in units of the plot),
rather than just fitting it to the text I've given (crude ascii art
below).  The following seems not to work:


ax = gca()
txtobj = ax.text(0, -.1 * yrange, 'text',
                     bbox=dict(boxstyle='rarrow'))
txtobj.get_bbox_patch().set_
width(SIZE_IM_INTERESTED_IN)
draw_if_interactive()

It seems like draw()ing the text object will reset the size of the BBox...
Any idea how to fix this? At the moment, I'm experimenting with continually
drawing, polling the get_width() method, and when it's too small, adding in
spaces around the text field, but that seems both not to work reliably, and
be an incredibly boneheaded way to go about it.

I'm using matplotlib v. 1.1.0 if that makes a difference.


--------------\
|    text      >
--------------/
not
------\
| text >
------/