wish: dataset output (side-effect) of warp()

[mdsumner]

just a thought bubble I've been thinking about, I would quite like warp(src, <dst>, t_srs, cl_arg) to be able to return a live dataset as it does in osgeo.gdal, for now I'm using constructs like

warp(src, "/vsimem/out.tif", t_srs, cl_arg = ) ## or out.vrt

Could we have the destination dataset passed in as an empty object?

dst <- new(GDALRaster)
warp(src, dst, t_srs, cl_arg = ) ## or out.vrt

I guess this could also have the added bonus of setting up a destination with all the properties, and potentially taking multiple writes to it from multiple warp() calls?

I will explore the prospects for this, and outline examples in osgeo.gdal just wanted to share the thought.

[ctoney]

This seems like a worthwhile improvement that could be useful in general, but I haven't thought through all the details yet.

Could we have the destination dataset passed in as an empty object?

Possibly relevant....

#310 adds GDALRaster::setFilename(). Currently undocumented, but exposed in R. Comments in the PR describe implications.

#309 adds GDALRaster::_getGDALDatasetH(), internal method for use on the C++ side. Gets the GDALDatasetH in use by an object of class GDALRaster (or nullptr if the dataset is not open).

[mdsumner]

awesome thanks, I'm keeping notes and will continue exploring and feedback

[ctoney]

GDALAutoCreateWarpedVRT() might be useful for this, https://gdal.org/api/gdalwarp_cpp.html#_CPPv423GDALAutoCreateWarpedVRT12GDALDatasetHPKcPKc15GDALResampleAlgdPK15GDALWarpOptions

Earlier I added the exported method GDALRaster::setFilename() as mentioned above, but it has

    if (fname_in == "" && filename != "" && hDataset == nullptr)

so would not work if we needed to set the filename but the hDataset is not nullptr. That doesn't matter though b/c setFilename() is currently undocumented / for internal use. We can change it, but we can also make the private member variables hDataset etc., public on the C++ side but not exported to R. Then a GDALRaster object can be constructed from a hDataset and returned to R, potentially without a filename associated. setFilename() can be modified and documented to support saving the dataset object to file from R.

That would at least work for the VRT from GDALAutoCreateWarpedVRT(). Maybe there are possibilities for more general uses by constructing a VRT in that way and returning it as GDALRaster object. Something similar should be possible with MEM.

Could we have the destination dataset passed in as an empty object?

Yes but if using the above, the destination dataset would become a VRT pointing to the source dataset, with or without a VRT filename associated. Or destination could also be MEM.

I still have not thought through details in terms of use cases and capabilities. VRT and MEM support AddBand() which could be implemented as a class method for drivers that support it. Any of the existing utility/algorithm functions in {gdalraster}, and createCopy(), can be modified to accept an object of class GDALRaster in place of filename. Helper functions can be added for working with memory buffers, e.g., wrappers of VSIFileFromMemBuffer(} and VVSIGetMemFileBuffer().

[ctoney]

This has been implemented for warp() in #469. Please see comments and the code example there.

Possibly related is autoCreateWarpedVRT() which also returns a dataset object (#471). GDALRaster::setFilename() is now documented for potential use in that case, i.e., a virtual dataset that initially has no associated filename.

GDALRaster::addBand() method may be useful with MEM and VRT (#467) .

[mdsumner]

Awesome, works well for cases I tried. Will explore and provide feedback on details as they come up. Thanks!