matplotlib-devel Mailing List for matplotlib

Actually, I just noticed this problem myself after upgrading my system to
Fedora 13. Turns out I still had some *.so files in the lib directory that
were not getting updated by the Make (might be a dependency issue?), and
they weren't getting eliminated by a 'clean' command. Therefore, the old
.so files were still expecting to link to the older versions of the
libraries which didn't exist anymore.
Deleting the *.so files in the lib directory and redoing the entire build
worked like a charm for me.
Ben Root
On Thu, Jun 10, 2010 at 1:21 PM, Jeff Whitaker <js...@fa...> wrote:
> On 6/10/10 11:50 AM, Pierre GM wrote:
> > On Jun 10, 2010, at 1:30 PM, Christoph Gohlke wrote:
> >
> >>
> >> On 6/10/2010 10:14 AM, Pierre GM wrote:
> >>
> >>> On Jun 10, 2010, at 12:51 PM, Jeff Whitaker wrote:
> >>>
> >>>> On 6/10/10 10:40 AM, Pierre GM wrote:
> >>>>
> >>>>> All,
> >>>>> Sorry, it's been a while since I've been using Basemap. I was just
> trying to update my local svn directory to r8403 and reinstall basemap, but
> an import fail w/ the following message:
> >>>>> """
> >>>>> Traceback (most recent call last):
> >>>>> File "<string>", line 1, in<module>
> >>>>> File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line
> 43, in<module>
> >>>>> import _geoslib, netcdftime
> >>>>> File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
> >>>>> ValueError: numpy.ndarray does not appear to be the correct type
> object
> >>>>> """
> >>>>> I'm using numpy 2.0.0r8460 (development version). basemap can be
> successfully imported w/ the latest stable version, though. What am I doing
> wrong ?
> >>>>> Thx in advance.
> >>>>> P.
> >>>>>
> >>>>>
> >>>> Pierre: That should have been fixed with a recompile of the _geoslib
> C extension Are you sure you deleted the build directory before
> reinstalling basemap?
> >>>>
> >>>
> >> Try to regenerate the c files from _geod.pyx, _proj.pyx, and
> >> _geoslib.pyx, using Cython-0.12.1. For example:
> >>
>
> Wonder why I didn't have to do that ...
>
> -Jeff
>
> --
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 6/10/10 11:50 AM, Pierre GM wrote:
> On Jun 10, 2010, at 1:30 PM, Christoph Gohlke wrote:
> 
>>
>> On 6/10/2010 10:14 AM, Pierre GM wrote:
>> 
>>> On Jun 10, 2010, at 12:51 PM, Jeff Whitaker wrote:
>>> 
>>>> On 6/10/10 10:40 AM, Pierre GM wrote:
>>>> 
>>>>> All,
>>>>> Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
>>>>> """
>>>>> Traceback (most recent call last):
>>>>> File "<string>", line 1, in<module>
>>>>> File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in<module>
>>>>> import _geoslib, netcdftime
>>>>> File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
>>>>> ValueError: numpy.ndarray does not appear to be the correct type object
>>>>> """
>>>>> I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
>>>>> Thx in advance.
>>>>> P.
>>>>>
>>>>> 
>>>> Pierre: That should have been fixed with a recompile of the _geoslib C extension Are you sure you deleted the build directory before reinstalling basemap?
>>>> 
>>> 
>> Try to regenerate the c files from _geod.pyx, _proj.pyx, and
>> _geoslib.pyx, using Cython-0.12.1. For example:
>> 
Wonder why I didn't have to do that ...
-Jeff
-- 
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

On Thu, Jun 10, 2010 at 1:13 PM, Benjamin Root <ben...@ou...> wrote:
> Taking out adjustable='box' had the same effect for me as setting
> adjustable='box-forced
Just a quick comment.
As you can verify, the axes created with AxesGrid will have
adjustable="datalim". With AxesGrid, the size of each axes is adjusted
before they call "apply_aspect", hence the value of adjustable
actually does not matter from the AxesGrid point of view.
My recollection is that "bbox-forced" option was originally meant to
be used with a normal axes.
Regards,
-JJ

On 6/10/10 11:13 AM, Benjamin Root wrote:
>
>
> On Thu, Jun 10, 2010 at 11:56 AM, Jeff Whitaker <js...@fa... 
> <mailto:js...@fa...>> wrote:
>
> On 6/10/10 10:41 AM, Benjamin Root wrote:
>>
>>
>> On Thu, Jun 10, 2010 at 11:05 AM, Jeff Whitaker
>> <js...@fa... <mailto:js...@fa...>> wrote:
>>
>> On 6/9/10 1:58 PM, 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.
>>>
>>> Ben Root
>>
>> Ben: To summarize the discussion so far, it seems that
>> "box-forced" should not be used, and either Basemap should
>> continue to use adjustable="box" (for the reasons Eric gave
>> in his post yesterday) or adjustable should not be set at all
>> by Basemap and that job should be left to the user (since
>> adjustable='box' is the default anyway, as Jae-Joon pointed
>> out today). Perhaps it would help if you could provide a
>> usage example for AxesGrid axes sharing with Basemap, so we
>> can see what the consequences of changing the current
>> behavior are.
>>
>> -Jeff
>>
>> Maybe it isn't a use-case per se, but I have found that it is
>> much easier to use axes_grid1 instead of subplots to produce
>> multiple radar plots that all use the same colorbar. For
>> example, I have 3 radar plots to show, and I want a single
>> colorbar on the right-hand side. To a newbie, one would add
>> three subplots with a .colorbar() command for the last one. 
>> Unfortunately, the newbie will discover that the third plot will
>> be smaller than the other two because that last axes has to be
>> split between two objects. To someone a little more advanced,
>> you would create 4 subplots, but fool around with the size of the
>> last axes (and also have to discover to use ColorbarBase instead
>> of the regular colorbar call).
>>
>> But, with axes_grid, this is quite trivial and the results look
>> very nice.
>>
>> Attached is a png image of a time series I recent submitted in a
>> publication.
>>
>> Ben Root
>>
>> P.S. - I have found a 'bug' of sorts with using 'box-forced' for
>> Basemap and AxesGrid. For the displayed plot, if one were to
>> zoom in on one of the plots, the other plots will zoom in as well
>> (which I think is neat), but they won't update their bbox to
>> completely match the zoomed-in axes. I guess this would be an
>> argument against using 'box-forced'?
>
> Ben: Could you send the code that produced this plot?
>
> I'm thinking that just removing the adjustable='box' from Basemap
> altogether is the best solution. Can you try editing
> lib/mpl_toolkits/basemap/__init__.py and removing the two
> occurences of adjustable='box' in set_axes_limits works for you?
>
>
> Jeff, here is a very simple script that gets the idea across (the code 
> and the data for producing those plots are rather extensive...). 
> Taking out adjustable='box' had the same effect for me as setting 
> adjustable='box-forced'. You can see the zooming issue I was talking 
> about before as well when you interact with the displayed figure.
>
> Ben Root
Ben: OK, I see the issue with zooming. If you create the subplots 
manually (without AxesGrid) it doesn't happen (only one plot zooms). 
Maybe Jae-Joon can comment on why this is happening?
-Jeff
>
>
> Index: lib/mpl_toolkits/basemap/__init__.py
> ===================================================================
> --- lib/mpl_toolkits/basemap/__init__.py (revision 8406)
> +++ lib/mpl_toolkits/basemap/__init__.py (working copy)
> @@ -2628,9 +2628,9 @@
> # plot is re-centered in bounding rectangle.
> # (anchor instance var determines where plot is placed)
> if self.fix_aspect:
> - 
> ax.set_aspect('equal',adjustable='box',anchor=self.anchor)
> + ax.set_aspect('equal',anchor=self.anchor)
> else:
> - ax.set_aspect('auto',adjustable='box',anchor=self.anchor)
> + ax.set_aspect('auto',anchor=self.anchor)
> # make sure axis ticks are turned off.
> if self.noticks:
> ax.set_xticks([])
>
> We definitely don't want to use 'box-forced', I think that will
> cause many problems.
>
> -Jeff
>
>>
>>>
>>>
>>> On Tue, Jun 1, 2010 at 6:00 PM, Benjamin Root
>>> <ben...@ou... <mailto:ben...@ou...>> 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...@gm... <mailto:lee...@gm...>> 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...@ou... <mailto:ben...@ou...>> 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...@gm... <mailto:lee...@gm...>>
>>> 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,
>>> <PH...@ge...
>>> <mailto:PH...@ge...>> 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:ada...@gm...
>>> <mailto:ada...@gm...>]
>>> >> > 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
>>> >> > Mat...@li...
>>> <mailto:Mat...@li...>
>>> >> >
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> ------------------------------------------------------------------------------
>>> >>
>>> >> _______________________________________________
>>> >> Matplotlib-users mailing list
>>> >> Mat...@li...
>>> <mailto:Mat...@li...>
>>> >>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> >
>>> >
>>> > _______________________________________________
>>> > Matplotlib-devel mailing list
>>> > Mat...@li...
>>> <mailto:Mat...@li...>
>>> >
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> >
>>> >
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>>
>>
>>
>> -- 
>> Jeffrey S. Whitaker Phone : (303)497-6313
>> Meteorologist FAX : (303)497-6449
>> NOAA/OAR/PSD R/PSD1 Email :Jef...@no... <mailto:Jef...@no...>
>> 325 Broadway Office : Skaggs Research Cntr 1D-113
>> Boulder, CO, USA 80303-3328 Web :http://tinyurl.com/5telg
>> 
>>
>>
>
>
> -- 
> Jeffrey S. Whitaker Phone : (303)497-6313
> Meteorologist FAX : (303)497-6449
> NOAA/OAR/PSD R/PSD1 Email :Jef...@no... <mailto:Jef...@no...>
> 325 Broadway Office : Skaggs Research Cntr 1D-113
> Boulder, CO, USA 80303-3328 Web :http://tinyurl.com/5telg
> 
>
>
-- 
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

On 6/10/10 11:14 AM, Pierre GM wrote:
> On Jun 10, 2010, at 12:51 PM, Jeff Whitaker wrote:
> 
>> On 6/10/10 10:40 AM, Pierre GM wrote:
>> 
>>> All,
>>> Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
>>> """
>>> Traceback (most recent call last):
>>> File "<string>", line 1, in<module>
>>> File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in<module>
>>> import _geoslib, netcdftime
>>> File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
>>> ValueError: numpy.ndarray does not appear to be the correct type object
>>> """
>>> I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
>>> Thx in advance.
>>> P.
>>>
>>> 
>> Pierre: That should have been fixed with a recompile of the _geoslib C extension Are you sure you deleted the build directory before reinstalling basemap?
>> 
>
> I did. Do I have to recompile geos ? It should be independent of numpy, right ? So I shouldn't have to touch it ?
> As far as I can tell, the setup picks up the proper versions of numpy and Python...
> 
Pierre: No, you don't need to recompile the geos library. I just 
installed numpy 2.0 svn with python 2.6, and after a recompile of both 
matplotlib from svn and basemap from svn everything worked fine. I 
suspect you are still picking up an old _geoslib.so somehow.
-Jeff
-- 
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

On 6/10/10 10:40 AM, Pierre GM wrote:
> All,
> Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
> """
> Traceback (most recent call last):
> File "<string>", line 1, in<module>
> File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in<module>
> import _geoslib, netcdftime
> File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
> ValueError: numpy.ndarray does not appear to be the correct type object
> """
> I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
> Thx in advance.
> P.
> 
Pierre: That should have been fixed with a recompile of the _geoslib C 
extension Are you sure you deleted the build directory before 
reinstalling basemap?
-Jeff
-- 
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

All,
Sorry, it's been a while since I've been using Basemap. I was just trying to update my local svn directory to r8403 and reinstall basemap, but an import fail w/ the following message:
"""
Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "~/basemap-dev/lib/mpl_toolkits/basemap/__init__.py", line 43, in <module>
 import _geoslib, netcdftime
 File "_geoslib.pyx", line 13, in _geoslib (src/_geoslib.c:4014)
ValueError: numpy.ndarray does not appear to be the correct type object
"""
I'm using numpy 2.0.0r8460 (development version). basemap can be successfully imported w/ the latest stable version, though. What am I doing wrong ?
Thx in advance.
P.

On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud <eri...@gm...> wrote:
> Jae-Joon, your patch looks to be effectively the same except for
> slightly different behavior when more than 3 points are present... but
> that was what was originally intended - the numpoints-> scatterpoints
> was a good catch!
I'm not sure if I put those numbers in the first places (maybe not),
yes, that was what was originally intended. And I'm inclined to leave
it as is.
I'll commit the change soon.
Thanks again.
-JJ

On Wed, Jun 9, 2010 at 6:22 PM, Eric Firing <ef...@ha...> wrote:
> Jeff can correct me if I am wrong, but I think adjustable='box' is
> essential for basemap because the maximum data limits are set when the
> Basemap instance is created. In some cases the characteristics of the
> projection, and in all cases the extraction of coastlines, is set at
> instantiation time. You can zoom in to show smaller regions, but you
> don't want apply_aspect to expand the data limits beyond their initial
> values.
I think that, as axes in matplotlib, by default, has adjustable='box',
it should be okay without explicitly setting adjustable='box' in most
cases.
With explicit adjustable='bbox',
 * you will fix when a user accidentally provided an axes with wrong
adjustable value.
 * On the other hand, you will prohibit any axes sharing when Basemap
is used (there are cases when axes sharing is fine even if the aspect
is set to "equal").
So, I guess my point is that it might be good in this case to let the
user be responsible for what he is doing.
Since I'm not a regular Basemap user, it is just my point of view
(which might be wrong) from the outside.
Regards,
-JJ

On 6/10/10 7:01 AM, Jason Grout wrote:
> In 
> http://www.mail-archive.com/mat...@li.../msg05423.html, 
> I reported a patch that Sage uses for matplotlib on Solaris. Notice 
> below that only one line is changed.
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> ttconv/pprdrv_tt2.cpp: This patch is *only* applied when `uname` =
> "SunOS". The comment is: Copy patched version of pprdrv_tt2.cpp for
> Solaris 10 that builds with gcc 4.3.2.
>
>
> --- src/ttconv/pprdrv_tt2.cpp 2009年08月01日 12:15:15.000000000 -0700
> +++ patches/pprdrv_tt2.cpp 2009年08月08日 23:33:24.000000000 -0700
> @@ -104,7 +104,8 @@
> { /* have a log of points. */
> if(stack_depth == 0)
> {
> - stream.put_char('{');
> + // Note the below is a hack to make it compile on Solaris
> 10 with gcc 4.3.2
> + stream.puts("{");
> stack_depth=1;
> }
> 
>
> In 
> http://www.mail-archive.com/mat...@li.../msg05428.html, 
> John said he'd look at it, but also asked for a platform macro for 
> Solaris. I'm not sure what was done about it since then. I notice 
> that the 0.99.3 release has the original code (i.e., no patch has been 
> applied). John (or anyone), if you have time, could you take a look 
> at this?
>
> I'm CCing Dave Kirkby, who is a person in the Sage community that has 
> been working quite a bit on getting things to work on Solaris. He 
> might have an idea of a good C macro for detecting when we are on Solaris.
I see that 
http://www.mail-archive.com/mat...@li.../msg04947.html 
is a related message which discusses compiling on Solaris and the 
put_char method. In fact, I think the issue may be fixed from the 
discussion in that message, and our patch is unnecessary now. I'm 
preparing a new matplotlib package for Sage without our patch above 
which we will test on Solaris.
Jason
--
Jason Grout

In 
http://www.mail-archive.com/mat...@li.../msg05423.html, 
I reported a patch that Sage uses for matplotlib on Solaris. Notice 
below that only one line is changed.
---------------------------------------------------------------------------------------------------------------------------------------
ttconv/pprdrv_tt2.cpp: This patch is *only* applied when `uname` =
"SunOS". The comment is: Copy patched version of pprdrv_tt2.cpp for
Solaris 10 that builds with gcc 4.3.2.
--- src/ttconv/pprdrv_tt2.cpp 2009年08月01日 12:15:15.000000000 -0700
+++ patches/pprdrv_tt2.cpp 2009年08月08日 23:33:24.000000000 -0700
@@ -104,7 +104,8 @@
 { /* have a log of points. */
 if(stack_depth == 0)
 {
- stream.put_char('{');
+ // Note the below is a hack to make it compile on Solaris
10 with gcc 4.3.2
+ stream.puts("{");
 stack_depth=1;
 }
In 
http://www.mail-archive.com/mat...@li.../msg05428.html, 
John said he'd look at it, but also asked for a platform macro for 
Solaris. I'm not sure what was done about it since then. I notice that 
the 0.99.3 release has the original code (i.e., no patch has been 
applied). John (or anyone), if you have time, could you take a look at 
this?
I'm CCing Dave Kirkby, who is a person in the Sage community that has 
been working quite a bit on getting things to work on Solaris. He might 
have an idea of a good C macro for detecting when we are on Solaris.
Thanks,
Jason
--
Jason Grout

On Wed, Jun 9, 2010 at 8:17 PM, Jason Grout <jas...@cr...> wrote:
> In the "call signature" of savefig found here:
>
> http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.savefig
>
> it doesn't list the bbox_inches and pad_inches options, though they are
> listed in the list below the signature.
Thanks -- fixed in svn 8404
JDH

In the "call signature" of savefig found here:
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.savefig
it doesn't list the bbox_inches and pad_inches options, though they are 
listed in the list below the signature.
Thanks,
Jason