Hi Jeff and Basemap users, Here at NASA's Jet Propulsion Laboratory, we're very happy Basemap users. We've been using it to create plots of spacecraft launch trajectory ground tracks. I've just attempted to upgrade from basemap 0.2 to 0.5. I have a problem. The basemap 0.2 interface worked with an Axes object that you supplied explicitly: axes = figure.add_axes( ... ) bMap = Basemap( ... ) bMap.drawcoastlines( axes ) bMap.drawcountries( axes ) bMap.fillcontinents( axes ) The basemap 0.5 interface has changed so that you don't pass in an Axes object to Basemap functions. Instead, functions are called like so: bMap.drawcoastlines() bMap.drawcountries() bMap.fillcontinents() and inside each function there's a call to mpylab.gca(), so that the map gets drawn on the pylab current axes. Our software is written without any dependencies on pylab, so we are unable to upgrade to basemap 0.5. For us, it's important to have a pure OO-interface. Jeff, would it be possible to restore the v0.2 Basemap class interface which doesn't make any pylab calls? What was the intent of the basemap interface change? Was it to present a more "pylab-like" interface? If so, perhaps we could keep the Basemap class pylab-free, and add a "basemap-lab" layer atop it, just as pylab sits atop the Matplotlib classes. Anyway, just wanted to get people's thoughts. My agenda is that I'd very much like to get a Basemap pure-OO interface (with no pylab dependencies) restored. (Another less important question: why did the name of the basemap data directory change from 'basemap' to 'basemap-pyVERSION'? Is there something python-version-specific in there?) Thanks, Michael Brady
Michael Brady wrote: > The basemap 0.2 interface worked with an Axes object that you supplied > explicitly: > > axes = figure.add_axes( ... ) > bMap = Basemap( ... ) > > bMap.drawcoastlines( axes ) > bMap.drawcountries( axes ) > bMap.fillcontinents( axes ) > > The basemap 0.5 interface has changed so that you don't pass in an Axes > object to Basemap functions. Instead, functions are called like so: > > bMap.drawcoastlines() > bMap.drawcountries() > bMap.fillcontinents() > For us, it's important to have a pure OO-interface. I totally agree. But it's not really about OO vs. imperative, the problem is counting on gca() and friends. I just plain find this ugly. Anyway while we're talking about it, it would be much more OO to have: axes = figure.add_axes( ... ) bMap = Basemap( axes ) (having passed in an axes object to the Basemap constructor) bMap.drawcoastlines() bMap.drawcountries() bMap.fillcontinents() Now you don't need to pass in the axes each time, but it's not use gca() either. It makes sense to me to have a given Basemap[ object associated with one and only one axes, but maybe I'm weird. By the way, Jeff. I've taken a quick look at your Proj4 code. I'm hoping to make use of it for another project (the wxPython FloatCanvas). It looks to me like to would make sense to make that a separate library that could be used with other projects. I nice Pythonic projection module would be great. Do you think this makes sense? -Chris Jeff, would it be > possible to restore the v0.2 Basemap class interface which doesn't make > any pylab calls? > > What was the intent of the basemap interface change? Was it to present > a more "pylab-like" interface? If so, perhaps we could keep the Basemap > class pylab-free, and add a "basemap-lab" layer atop it, just as pylab > sits atop the Matplotlib classes. > > Anyway, just wanted to get people's thoughts. My agenda is that I'd > very much like to get a Basemap pure-OO interface (with no pylab > dependencies) restored. > > (Another less important question: why did the name of the basemap data > directory change from 'basemap' to 'basemap-pyVERSION'? Is there > something python-version-specific in there?) > > Thanks, > > Michael Brady > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
On Jun 27, 2005, at 1:45 PM, Chris Barker wrote: > Michael Brady wrote: >> The basemap 0.2 interface worked with an Axes object that you >> supplied explicitly: >> axes = figure.add_axes( ... ) >> bMap = Basemap( ... ) >> bMap.drawcoastlines( axes ) >> bMap.drawcountries( axes ) >> bMap.fillcontinents( axes ) >> The basemap 0.5 interface has changed so that you don't pass in an >> Axes object to Basemap functions. Instead, functions are called like >> so: >> bMap.drawcoastlines() >> bMap.drawcountries() >> bMap.fillcontinents() > >> For us, it's important to have a pure OO-interface. > > I totally agree. But it's not really about OO vs. imperative, the > problem is counting on gca() and friends. I just plain find this ugly. > > Anyway while we're talking about it, it would be much more OO to have: > > axes = figure.add_axes( ... ) > bMap = Basemap( axes ) > > (having passed in an axes object to the Basemap constructor) > > bMap.drawcoastlines() > bMap.drawcountries() > bMap.fillcontinents() > > Now you don't need to pass in the axes each time, but it's not use > gca() either. It makes sense to me to have a given Basemap[ object > associated with one and only one axes, but maybe I'm weird. > > By the way, Jeff. I've taken a quick look at your Proj4 code. I'm > hoping to make use of it for another project (the wxPython > FloatCanvas). It looks to me like to would make sense to make that a > separate library that could be used with other projects. I nice > Pythonic projection module would be great. Do you think this makes > sense? > > -Chris > There is http://hobu.biz/software/pyprojection/ which Howard Butler extracted from Thuban http://thuban.intevation.org/ cheers, Sean -- Sean Gillies sgillies at frii dot com http://zcologia.com
Sean Gillies wrote: > There is > > http://hobu.biz/software/pyprojection/ Thanks! I thought I'd seen that but couldn't find it just now. Does anyone know if it is Numeric/numarray aware? I'd need that to get he performance I'd need. It look like Jeff's code is. Jeff, any particular reason you didn't use this? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
Chris Barker wrote: > > Sean Gillies wrote: > >> There is >> >> http://hobu.biz/software/pyprojection/ > > Thanks! I thought I'd seen that but couldn't find it just now. Does > anyone know if it is Numeric/numarray aware? It isn't. -- Robert Kern rk...@uc... "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter
Chris Barker wrote: > > > Sean Gillies wrote: > >> There is >> >> http://hobu.biz/software/pyprojection/ > > > Thanks! I thought I'd seen that but couldn't find it just now. Does > anyone know if it is Numeric/numarray aware? I'd need that to get he > performance I'd need. It look like Jeff's code is. > > Jeff, any particular reason you didn't use this? Chris: I did use it at first, but decided that a simple pyrex wrapper was simpler and easier to maintain. My module is not really fully optimized to take advantage of numarray - it does the transformation one point at a time in a c-loop and stuffs the result in a list. So, there's a lot of overhead in repeatedly calling the proj4 c-routine. It would be a lot faster to recode the proj4 c-routine to process the whole array at once. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
Jeff Whitaker wrote: > Chris Barker wrote: > >> >> >> Sean Gillies wrote: >> >>> There is >>> >>> http://hobu.biz/software/pyprojection/ >> >> >> >> Thanks! I thought I'd seen that but couldn't find it just now. Does >> anyone know if it is Numeric/numarray aware? I'd need that to get he >> performance I'd need. It look like Jeff's code is. >> >> Jeff, any particular reason you didn't use this? > > > > Chris: > > I did use it at first, but decided that a simple pyrex wrapper was > simpler and easier to maintain. > My module is not really fully optimized to take advantage of numarray > - it does the transformation one point at a time in a c-loop and > stuffs the result in a list. So, there's a lot of overhead in > repeatedly calling the proj4 c-routine. It would be a lot faster to > recode the proj4 c-routine to process the whole array at once. > -Jeff > > > Chris: I should say that the reason I haven't done this is related to the reason I decided to not use the Thuban module - I know very little about C programming and didn't want to mess with C code. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
Chris Barker wrote: >> For us, it's important to have a pure OO-interface. > > > I totally agree. But it's not really about OO vs. imperative, the > problem is counting on gca() and friends. I just plain find this ugly. > > Anyway while we're talking about it, it would be much more OO to have: > > axes = figure.add_axes( ... ) > bMap = Basemap( axes ) > > (having passed in an axes object to the Basemap constructor) > > bMap.drawcoastlines() > bMap.drawcountries() > bMap.fillcontinents() > > Now you don't need to pass in the axes each time, but it's not use > gca() either. It makes sense to me to have a given Basemap[ object > associated with one and only one axes, but maybe I'm weird. Chris: I agree relying on gca is not good in general, and in 0.5.1 I've fixed this (see my reply to Michael Brady). The problem with your solution is that you can't use the same Basemap instance to plot on different axes. > > By the way, Jeff. I've taken a quick look at your Proj4 code. I'm > hoping to make use of it for another project (the wxPython > FloatCanvas). It looks to me like to would make sense to make that a > separate library that could be used with other projects. I nice > Pythonic projection module would be great. Do you think this makes sense? Sure, I could easily do that. Let me know if you think the Thuban module that Sean mentioned would be a better all-purpose solution. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
Michael Brady wrote: > Hi Jeff and Basemap users, > > Here at NASA's Jet Propulsion Laboratory, we're very happy Basemap > users. We've been using it to create plots of spacecraft launch > trajectory ground tracks. > > I've just attempted to upgrade from basemap 0.2 to 0.5. I have a problem. > > The basemap 0.2 interface worked with an Axes object that you supplied > explicitly: > > axes = figure.add_axes( ... ) > bMap = Basemap( ... ) > > bMap.drawcoastlines( axes ) > bMap.drawcountries( axes ) > bMap.fillcontinents( axes ) > > The basemap 0.5 interface has changed so that you don't pass in an > Axes object to Basemap functions. Instead, functions are called like so: > > bMap.drawcoastlines() > bMap.drawcountries() > bMap.fillcontinents() > > and inside each function there's a call to mpylab.gca(), so that the > map gets drawn on the pylab current axes. > > Our software is written without any dependencies on pylab, so we are > unable to upgrade to basemap 0.5. > > For us, it's important to have a pure OO-interface. Jeff, would it be > possible to restore the v0.2 Basemap class interface which doesn't > make any pylab calls? Michael: By popular demand, I put this back in 0.5.1. You can now pass an axes instance to any Basemap method. The default is 'ax=None', in which case pylab.gca is used to get the current one. Does this solve your problem? > > (Another less important question: why did the name of the basemap > data directory change from 'basemap' to 'basemap-pyVERSION'? Is there > something python-version-specific in there?) This is for package managers like apt and rpm which have different packages for different python versions. If the directory name is the same, the packages will collide with each other. The other way to solve this is to have a separate package for the data files, but I thought this was easier. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/CDC R/CDC1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes: Jeff> Michael: By popular demand, I put this back in 0.5.1. You Jeff> can now pass an axes instance to any Basemap method. The Jeff> default is 'ax=None', in which case pylab.gca is used to get Jeff> the current one. Does this solve your problem? You can potentially get into trouble by simply importing the pylab module at all since pylab will try and import the default backend. This usually isn't fatal, but isn't ideal either. I would suggest conditionally importing pylab only if it is needed, eg when ax=None. The use case you would be avoiding is for example when the user hasn't changed the default backend (GTKAgg) from .matplotlibrc. They may be using non-pylab basemap in pure agg mode over a web app server. When you import pylab, the module will try and import pygtk, which will fail if pygtk is not installed or if there is no X11 connection. Of course, the user could change the default backend in the rc file, but one point of the OO interface is to have as little magic as possible. By conditionally importing pylab, you can avoid these kinds of problems. JDH
Jeff Whitaker wrote: > Chris Barker wrote: > It makes sense to me to have a given Basemap[ object >> associated with one and only one axes, but maybe I'm weird. > > No you're not weird. But I've been told that some people building GUI > apps want to use the same Basemap instance to draw in different windows. Fair enough. OO is not always the best way to go. >> I did use it at first, but decided that a simple pyrex wrapper was >> simpler and easier to maintain. You're probably right about that. I still haven't used pyrex, but it looks like a great idea. Maybe I have a reason to now. >> My module is not really fully optimized to take advantage of numarray >> - it does the transformation one point at a time in a c-loop and >> stuffs the result in a list. So, there's a lot of overhead in >> repeatedly calling the proj4 c-routine. Darn, that's exactly the kind of thing I'm hoping to avoid,. >> It would be a lot faster to >> recode the proj4 c-routine to process the whole array at once. I hope I'll get a chance to do this, but I'll probably start by using it like it is, and see how the performance is. If do work on it, I'm going to try to use the new "array interface" in the latest Numeric (at least I think it's there, the Numeric list has been quite lately). > Chris: I should say that the reason I haven't done this is related to > the reason I decided to not use the Thuban module - I know very little > about C programming and didn't want to mess with C code. I can understand that. I'm pretty weak in C myself. Every time I use it, I find it painful, and run back to Python as soon as I can. I hope you won't mind helping me out a bit with PROJ4, I'm still having a hard time wrapping my brain around projections. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
John Hunter wrote: >>>>>>"Jeff" == Jeff Whitaker <js...@fa...> writes: >>>>>> >>>>>> > > Jeff> Michael: By popular demand, I put this back in 0.5.1. You > Jeff> can now pass an axes instance to any Basemap method. The > Jeff> default is 'ax=None', in which case pylab.gca is used to get > Jeff> the current one. Does this solve your problem? > >You can potentially get into trouble by simply importing the pylab >module at all since pylab will try and import the default backend. >This usually isn't fatal, but isn't ideal either. I would suggest >conditionally importing pylab only if it is needed, eg when ax=None. > >The use case you would be avoiding is for example when the user hasn't >changed the default backend (GTKAgg) from .matplotlibrc. They may be >using non-pylab basemap in pure agg mode over a web app server. When >you import pylab, the module will try and import pygtk, which will >fail if pygtk is not installed or if there is no X11 connection. Of >course, the user could change the default backend in the rc file, but >one point of the OO interface is to have as little magic as possible. >By conditionally importing pylab, you can avoid these kinds of >problems. > >JDH > > John: OK, I've fixed it so pylab is not imported at all if either (1) the 'ax' keyword is used in Basemap.__init__ (in which case only one axes instance is used by that Basemap instance), or (2) the 'ax' keyword is used in all Basemap method calls that do drawing (in which case different axes may be used by the same Basemap instance). If you don't use the 'ax' keyword, basemap methods behave like their pylab counterparts (i.e. pylab.gca is used to get the current axis). -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 NOAA/OAR/CDC R/CDC1 FAX : (303)497-6449 325 Broadway Web : http://www.cdc.noaa.gov/~jsw Boulder, CO, USA 80305-3328 Office: Skaggs Research Cntr 1D-124
Jeff Whitaker wrote: > John: OK, I've fixed it so pylab is not imported at all if either (1) > the 'ax' keyword is used in Basemap.__init__ (in which case only one > axes instance is used by that Basemap instance), or (2) the 'ax' keyword > is used in all Basemap method calls that do drawing (in which case > different axes may be used by the same Basemap instance). If you don't > use the 'ax' keyword, basemap methods behave like their pylab > counterparts (i.e. pylab.gca is used to get the current axis). Nice job Jeff. You've come up with a solution that satisfies a wide variety of uses. Hurray for keyword arguments! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no...
On 2005年6月28日, Jeff Whitaker wrote: > John: OK, I've fixed it so pylab is not imported at all if either (1) the > 'ax' keyword is used in Basemap.__init__ (in which case only one axes > instance is used by that Basemap instance), or (2) the 'ax' keyword is used > in all Basemap method calls that do drawing (in which case different axes may > be used by the same Basemap instance). If you don't use the 'ax' keyword, > basemap methods behave like their pylab counterparts (i.e. pylab.gca is used > to get the current axis). Great! That's perfect for us. Thanks for the quick response. We have exactly the setup that John was describing. We use Basemap in cron jobs that don't have any X windows support. Our default backend is Qt, and Qt itself aborts and core dumps (!) if you try to use it when there's no X server present. So we wanted to avoid pylab loading a backend. I guess we'll see these changes in the next release, 0.5.2 or 0.6, whichever is next, yes? Thanks again, Michael ======================================================================== Michael Brady Jet Propulsion Laboratory (M/S 301-140L) 4800 Oak Grove Drive Pasadena, CA 91109 E-mail: Mic...@jp... ========================================================================