[gdal-dev] Commit r19248

[Ari Jolma]

Andrey Kiselev wrote:
> On Mon, Mar 29, 2010 at 11:23:08PM +0300, Ari Jolma wrote:
>   
>> That would mean copying from the initial buffer directly into  
>> Perl arrays within a typemap - I haven't done that because of the  
>> complication of several datatypes. To change that would mean - not to  
>> break existing code - defining a new set of read/write methods.
>>     
> 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?) 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

Regards,

Ari



> For now I have reverted back the problem commit.
>
> Best regards,
> Andrey
>
>