[gdal-dev] Re: [GDAL] #2023: Add a Python wrapper for GDALGridCreate() function

[Christopher Barker]

GDAL wrote:
> #2023: Add a Python wrapper for GDALGridCreate() function
> Comment:
> 
>  cc'ing Chris in case he can add some insight to what's going on in
>  swig/numpy land, as I've seen some traffic on the swig lists lately...

Finally replying....

Yes, there have been a few changes to the numpy.i typemaps, but I think 
it's been only a couple additions, none of which I can see applying to 
GDAL (though I don't know the GDAL API that well).

Anyway I do encourage you to use the numpy.i typemaps -- I think they 
are pretty well designed, the live in the numpy SVN, and their author, 
Bill Spotz is actively maintaining them and responsive to questions.

Now for the question at hand:

Proposed API:
"""
GridCreate(numpy_array,
            (minx,miny,maxx,maxy),
            nXSize,
            nYSize,
            eType,
            options)

numpy_array is a 2D NumPy? array containing all three pdfX, pdfY and 
pdfZ vectors.
"""

I assume that means that numpy_array is a Nx3 2-d array. That would work 
fine, though I'm not entirely sure what the advantage is over a closer 
mirror of the C API, and keep X,Y, and Z as separate arrays. One thought 
is that if the user has them as separate arrays, s/he'd have to make a 
copy to put them together into one array to make this call. On the other 
hand, if they were all one Nx3 array, the the method required them 
separate, that could easily be done without making copies:

pdfX = numpy_array[:,0]
pdfY = numpy_array[:,1]
pdfZ = numpy_array[:,2]


The output would be a nXSize x nYSize numpy array, yes?

Anyway, either way you do it it would be pretty easy with numpy.i, 
though a touch more code if you want them all together -- you'd need to 
do a %inline% function that split the numpy array up into the three 
separate C arrays -- not a big deal, but code to write. Though as I 
think about it, there will need to be an %inline% anyway, so that the 
three arrays all use a single number for their size -- see the numpy.i 
docs for an example of this. Now I"m leaning toward like the Nx3 array 
idea -- I know it is the data structure I usually use.

I read through your IRC session too. A couple comments:

<hobu>	I would propose that we make numpy *required* to build the 
next-gen bindings.

+1

In theory, the new "array interface" should allow folk to build 
extensions that play well with numpy without requiring the numpy 
headers, etc at build time. In practice, it's still easier to just build 
against numpy. I think that for the kind of data GDAL deals with, numpy 
is a no-brainer. But then I use it for almost everything!

<hobu>	if it is a single array, we can do a check in the typemap to 
ensure that things are in alignment

You could do that with three arrays also.

Any progress on this?

By the way, I like the ideas for cleaning up the structure of the SWIG code.


-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