[gdal-dev] Commit r19248
ari.jolma at gmail.com
Tue Mar 30 13:25:07 EDT 2010
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.
> For now I have reverted back the problem commit.
> Best regards,
More information about the gdal-dev