[gdal-dev] Experiments with the gdal_grid C API
Even Rouault
even.rouault at spatialys.com
Tue Jan 28 04:43:17 PST 2020
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
More information about the gdal-dev
mailing list