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