Opened 11 years ago

Closed 11 years ago

#3028 closed defect (fixed)

ReadAsArray in python/numpy gdal bindings should take pointer to preallocated memory

Reported by: jaredrubinaz Owned by: hobu
Priority: normal Milestone: 1.7.0
Component: PythonBindings Version: unspecified
Severity: major Keywords: numpy python readasarray


When using the C++ side of gdal with the numpy/python bindings. I would expect that a preallocated array would be generated from numpy and a pointer to the beginning of the memory buffer would be passed to gdal.

Currently the BandReadAsArray? method in is not even using the buf_obj that is passed in. If a buf_obj is passed in it overrides it with a new numpy array. This makes no sense. This method should just use the buf_obj

129 if buf_obj is not None: 130 buf_obj = numpy.zeros( shape, typecode ) 131 132 band_str = band.ReadRaster?( xoff, yoff, win_xsize, win_ysize, 133 buf_xsize, buf_ysize, datatype ) 134 ar = numpy.fromstring(band_str,dtype=typecode) 135 ar = numpy.reshape(ar, [buf_ysize,buf_xsize])

allocates the memory for the

RasterIO call, can one not have numpy allocate the memory and then pass

a pointer to the gdal/swig bindings?

Change History (3)

comment:1 Changed 11 years ago by dhelfman

Note: #3173 describes a crash that can occur as a result of the GDAL Python bindings not taking a buffer to pre-allocated memory.

comment:2 Changed 11 years ago by dhelfman

#2658 is also related and proposes a specific solution.

comment:3 Changed 11 years ago by Even Rouault

Resolution: fixed
Status: newclosed

The fix required quite a few changes in the gdal_array module (I swig'ified it, removed swig/python/extensions/numpydataset.cpp which was unused, etc..). Testing by others appreciated.

Note: See TracTickets for help on using tickets.