[gdal-dev] Experiments with the gdal_grid C API

Even Rouault even.rouault at spatialys.com
Tue Jan 28 04:43:17 PST 2020


> -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.


Spatialys - Geospatial professional services

More information about the gdal-dev mailing list