On 06/09/2010 09:58 AM, Benjamin Root wrote: > Has anybody given any further thought to the implication of having > Basemap set adjustable as "box-forced" instead of "box"? So far, it has > been working just fine for me, but I have no clue if there are any > unintended side-effects.
My sense is that box-forced lets you shoot yourself in the foot with shared axes, box doesn't. The reason I prohibited sharing x and y axes with adjustable as box is that it is not clear what should happen, or will happen--fundamental inconsistencies can arise. Suppose you have two axes sharing x and y. You set aspect to 1 for the first and 2 for the second. The first axes is drawn, executing apply_aspect and setting the box dimensions accordingly. Then the second is drawn, also executing apply_aspect. It is inconsistent with the first. There is no solution that satisfies all constraints. The basic point is that when using apply_aspect with adjustable as box, you have to have freedom to change one of the axes, and this is not in general consistent with sharing both axes--though it may be in particular cases. Very likely there is a way of refining the logic, but beware: getting aspect ratio control to work under a wide range of conditions, including all sorts of zooming and resizing, is tricky and laborious. It is much easier to break it than to fix it, and the breakage can be hard to spot. Eric > > Ben Root > > > On Tue, Jun 1, 2010 at 6:00 PM, Benjamin Root <ben.r...@ou.edu > <mailto:ben.r...@ou.edu>> wrote: > > Right, that is sort of what I am asking. My thinking is that > Basemap could use 'box-forced' instead of 'box' for the adjustable > parameter in order to make it and AxesGrid compatible. Usually, if > one wants to use AxesGrid, they all should have the same domain and > aspect ratio. I just have no clue what sort of repricussions that > has for other use cases. > > So far, this has worked just fine for me, but I hardly represent the > normal use cases of Basemap and AxesGrid. > > Ben Root > > > On Tue, Jun 1, 2010 at 5:20 PM, Jae-Joon Lee <lee.j.j...@gmail.com > <mailto:lee.j.j...@gmail.com>> wrote: > > If Basemap explicitly sets aspect=1 and adjustable="box" at the same > time, you cannot use this with any axes that shares its axis with > others (including the axes created by the AxesGrid). > > You need to somehow avoid the set_aspect call with adjustable"box" > (you can set box-forced in stead). > > -JJ > > > On Tue, Jun 1, 2010 at 2:45 PM, Benjamin Root <ben.r...@ou.edu > <mailto:ben.r...@ou.edu>> wrote: > > > > On a related note, I have noticed an incompatibility between > AxesGrid and > > Basemap. It appears that Basemap will explicitly set > adjustable='box' when > > it calls ax.set_aspect(), but AxesGrid will error out, saying > that it has to > > be 'datalim'. What are the implications of using > 'box-forced' instead of > > 'box' in Basemap? > > > > Ben Root > > > > On Thu, May 27, 2010 at 1:59 PM, Jae-Joon Lee > <lee.j.j...@gmail.com <mailto:lee.j.j...@gmail.com>> wrote: > >> > >> ax1 = subplot(121) > >> ax2 = subplot(122, sharex=ax1, sharey=ax1) > >> > >> ax1.set_adjustable("box-forced") > >> ax2.set_adjustable("box-forced") > >> > >> arr1 = np.arange(100).reshape((10, 10)) > >> ax1.imshow(arr1) > >> > >> arr2 = np.arange(100, 0, -1).reshape((10, 10)) > >> ax2.imshow(arr2) > >> > >> Note the use of set_adjustable("box-forced"). > >> sharex and sharey does not get along with axes of aspect=1 & > >> adjustable="box". > >> > >> -JJ > >> > >> > >> > >> On Thu, May 27, 2010 at 2:10 PM, <phob...@geosyntec.com > <mailto:phob...@geosyntec.com>> wrote: > >> > Do the “sharex” and “sharey” kwargs help? > >> > > >> > > >> > > > http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.axes > >> > > >> > > >> > > > http://matplotlib.sourceforge.net/examples/pylab_examples/shared_axis_demo.html > >> > > >> > -paul > >> > > >> > > >> > > >> > From: Adam Fraser [mailto:adam.n.fra...@gmail.com > <mailto:adam.n.fra...@gmail.com>] > >> > Sent: Thursday, May 27, 2010 10:44 AM > >> > To: matplotlib-users > >> > Subject: [Matplotlib-users] Is there a way to link axes of > imshow plots? > >> > > >> > > >> > > >> > Suppose I have a figure canvas with 3 plots... 2 are > images of the same > >> > dimensions plotted with imshow, and the other is a > scatterplot. I'd like > >> > to > >> > be able to link the x and y axes of the imshow plots so > that when I zoom > >> > in > >> > one, the other zooms to the same coordinates, and when I > pan in one, the > >> > other pans as well. > >> > > >> > > >> > > >> > I started hacking my way around this by > >> > subclassing NavigationToolbar2WxAgg > >> > (shown below)... but there are several problems here. > >> > > >> > 1) This will link the axes of all plots in a canvas since > all I've done > >> > is > >> > get rid of the checks for a.in_axes() > >> > > >> > 2) This worked well for panning, but zooming caused all > subplots to zoom > >> > from the same global point, rather than from the same > point in each of > >> > their > >> > respective axes. > >> > > >> > > >> > > >> > Can anyone suggest a workaround? > >> > > >> > > >> > > >> > Much thanks! > >> > > >> > -Adam > >> > > >> > > >> > > >> > from matplotlib.backends.backend_wxagg import > NavigationToolbar2WxAgg as > >> > NavigationToolbar > >> > > >> > class MyNavToolbar(NavigationToolbar): > >> > > >> > def __init__(self, canvas, cpfig): > >> > > >> > NavigationToolbar.__init__(self, canvas) > >> > > >> > > >> > > >> > # override > >> > > >> > def press_pan(self, event): > >> > > >> > 'the press mouse button in pan/zoom mode callback' > >> > > >> > > >> > > >> > if event.button == 1: > >> > > >> > self._button_pressed=1 > >> > > >> > elif event.button == 3: > >> > > >> > self._button_pressed=3 > >> > > >> > else: > >> > > >> > self._button_pressed=None > >> > > >> > return > >> > > >> > > >> > > >> > x, y = event.x, event.y > >> > > >> > > >> > > >> > # push the current view to define home if stack is > empty > >> > > >> > if self._views.empty(): self.push_current() > >> > > >> > > >> > > >> > self._xypress=[] > >> > > >> > for i, a in enumerate(self.canvas.figure.get_axes()): > >> > > >> > # only difference from overridden method is > that this one > >> > doesn't > >> > > >> > # check a.in_axes(event) > >> > > >> > if x is not None and y is not None and > a.get_navigate(): > >> > > >> > a.start_pan(x, y, event.button) > >> > > >> > self._xypress.append((a, i)) > >> > > >> > self.canvas.mpl_disconnect(self._idDrag) > >> > > >> > > >> > self._idDrag=self.canvas.mpl_connect('motion_notify_event', > >> > self.drag_pan) > >> > > >> > > >> > > >> > def press_zoom(self, event): > >> > > >> > 'the press mouse button in zoom to rect mode callback' > >> > > >> > if event.button == 1: > >> > > >> > self._button_pressed=1 > >> > > >> > elif event.button == 3: > >> > > >> > self._button_pressed=3 > >> > > >> > else: > >> > > >> > self._button_pressed=None > >> > > >> > return > >> > > >> > > >> > > >> > x, y = event.x, event.y > >> > > >> > > >> > > >> > # push the current view to define home if stack is > empty > >> > > >> > if self._views.empty(): self.push_current() > >> > > >> > > >> > > >> > self._xypress=[] > >> > > >> > for i, a in enumerate(self.canvas.figure.get_axes()): > >> > > >> > # only difference from overridden method is > that this one > >> > doesn't > >> > > >> > # check a.in_axes(event) > >> > > >> > if x is not None and y is not None and > a.get_navigate() and > >> > a.can_zoom(): > >> > > >> > self._xypress.append(( x, y, a, i, > a.viewLim.frozen(), > >> > a.transData.frozen())) > >> > > >> > > >> > > >> > self.press(event) > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > ------------------------------------------------------------------------------ > >> > > >> > > >> > _______________________________________________ > >> > Matplotlib-users mailing list > >> > matplotlib-us...@lists.sourceforge.net > <mailto:matplotlib-us...@lists.sourceforge.net> > >> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >> > > >> > > >> > >> > >> > > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Matplotlib-users mailing list > >> matplotlib-us...@lists.sourceforge.net > <mailto:matplotlib-us...@lists.sourceforge.net> > >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > > > > > ------------------------------------------------------------------------------ > > > > > > _______________________________________________ > > Matplotlib-devel mailing list > > Matplotlib-devel@lists.sourceforge.net > <mailto:Matplotlib-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > <mailto:Matplotlib-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
