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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
