Basemap OO interface

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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

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

Chris.Barker@...259...

There is

   http://hobu.biz/software/pyprojection/

which Howard Butler extracted from Thuban

   http://thuban.intevation.org/

cheers,
Sean

···

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

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

Chris.Barker@...259...

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
rkern@...376...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

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 : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

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 : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

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 : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

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 : Jeffrey.S.Whitaker@...259...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : Jeffrey S. Whitaker: NOAA Physical Sciences Laboratory

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

Chris.Barker@...259...