[gdal-dev] Commit r19248

[Andrey Kiselev]

On Tue, Mar 30, 2010 at 08:25:07PM +0300, Ari Jolma wrote:
>> I would like to read directly in the final string object. I think it could
>> be done using the buffer API in recent Python branches.
>
> But is the string object useful from Python programmer's point of view  
> then? (maybe NumPy?)

Yep, NumPy is good for that, but it is a separate API. Here I would like to do
just small optimization for ReadRaster call. Certainly we can save one buffer
allocation/copy/deallocation cycle.

> I can let Perl allocate memory for a Perl string  
> and then *possibly* give that buffer to the RasterIO, but the Perl  
> string still needs to be unpacked by the Perl hacker. There are cases  
> when the binary buffer is ok - for example in libral (C), and then in  
> Geo::Raster (Perl) I do just that - but for the average Joe Perl Hacker  
> it would be good to put it into a Perl 2D array - i.e., each number into  
> its own scalar. That I could do in standard typemaps, but as I wrote,  
> the interface is different from Band.ReadRaster, which returns the  
> string. I have defined a ReadTile/WriteTile interface(*), which do just  
> that, but currently the implementation is the read->copy->copy, and the  
> 2nd one in Perl, which makes it even a bit slower.
>
> (*) see  
> http://geoinformatics.tkk.fi/doc/Geo-GDAL/html/class_geo_1_1_g_d_a_l_1_1_band.html

I will take a look at Perl part in more details and come with some suggestion
later. I think we can arrange something useful for both bindings.

-- 
Andrey V. Kiselev