Joaquim, > -Note that I'm using "NUL" for the output file name because that was the > only way I found to prevent saving the file in disk (remember, I want to > have it memory).
That's bound to fail. NUL or /dev/null are files that can't be re-read, and as you call GDALRasterIO(), you do intend to re-read them. And even if you don't re-read them, I don't think the GTiff driver will be happy writing such files. This probably sort of works for you because the content is kept in the GDAL block cache, so you re-read from it, rather than the file itself. With a larger dataset or smaller GDAL_CACHEMAX value, that wouldn't work > -The second thing not shown above is that I had to use "-ot GTiff" in the > psOptions. Using "-ot Memory" lead to errors. Should be -of MEM. That's tested in autotest/utilities/test_gdal_grid_lib.py An alternative is to use a /vsimem/temp.tif with the GTiff driver (but you need to VSIUnlink() the file once done to avoid mem leaks). But the MEM driver should do it. > Ok, so my questions are. Is there a better way to do this? Could we, by some > mean, send in a pre-allocated array and owned by the external program to > the API so the duplication step could be avoided? The gdal grid API doesn't support updating an existing dataset. If it had, then you could have created a MEM dataset based on your own array. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
