[gdal-dev] Numpy in GDAL (was: basic raster math)

[Howard Butler]

On Feb 15, 2008, at 11:44 AM, Christopher Barker wrote:
>
> This really points out that we need some Recipe pages in the Wiki  
> for Python/GDAL -- anyone want to get that started?
>
> While we're on the topic -- what are the plans for numpy vs.  
> Numeric? It looks like the current utilities and samples all allow  
> either one -- I'd like to see a switch to only-numpy at some point  
> -- the sooner the better. It's what's supported now, and it does  
> have small but subtle and useful differences.
>

This is not completely accurate, but the code isn't very clear  
either.  All of the utilities and samples support both to be able to  
use both the old-gen and next-gen bindings, but it's an either/or  
proposition.  You're either using next-gen with numpy, or old-gen with  
Numeric.  ReadAsArray in the next-gen bindings, for example, is only  
going to return you a numpy array.  The reason for not totally  
switching the examples and utilities to next-gen is FWTools still  
needs old-gen support.


> Also -- are there any Python API docs out there that I haven't  
> found? If not, we could use them -- maybe doc strings and some auto- 
> generation tool, like pydoc or Doxygen. What is being used for the C/ 
> C++?
>
> Robin Dunn (of wxPython) has done some nice work of auto-generating  
> docs strings as part of the SWIG process -- perhaps we could borrow  
> that approach.


I use swig+doxygen to generate the docs for ogr.py from the C API, but  
I haven't gotten to gdal.py yet.  A downside of the approach I've  
taken is that it requires manually mapping C API -> Python API method  
names so that swig can match up what to put where.  For OGR, the  
classes and method calls are pretty consistent, but on the GDAL side,  
what we do in Python is quite different than the C API.

If someone has a patch for manual docstrings for gdal.py etc, please  
file it in Trac and I'll ensure that they get included as part of the  
swig generation process.