[gdal-dev] FW: gdal_merge.py

[Even Rouault]

On mercredi 28 mars 2018 17:58:37 CEST Raphael Das Gupta wrote:
> On 28.03.2018 16:31, Marcos Dione wrote:
> >     in my opinion, gdal_merge should be used only if the merged version
> > 
> > will be used for more things or if you're going to use it with something
> > that doesn't know how to read the .vrt files (i.e., is not using gdal).
> 
> Even then it seems to be faster to first create a (temporary) .vrt file
> and then convert that to something else (thereby materializing the
> content) with e.g. gdaltranslate. (And then throw away the temporary
> .vrt file.)
> 
> In my (and others', see e.g.
> https://stackoverflow.com/a/22602542/674064) experience, the combined
> runtime of gdalbuildvrt and gdaltranslate will be shorter than that of
> gdal_merge.py would be. (And the quality of the result might also be
> better.)
> 
> Though I don't know whether that was just the case for the examples I
> encountered so far or whether that's always the case. Also, I don't know
> whether there are use-cases of gdal_merge.py that gdalbuildvrt +
> gdaltranslate (or + gdalwarp) can't handle.
> 
> If not, maybe gdal_merge.py should be reimplemented as a wrapper of
> gdalbuildvrt + gdaltranslate, so that the obvious (and most convenient)
> choice is also the best one?

My summary of different solutions:

* gdalbuildvrt + gdaltranslate:
   - pros:
      + efficient regarding compression of output dataset
      + work with arbitrarily large input  datasets.
      + several resampling methods
   - cons:
      + does not handle as one would expect overlapping input datasets regarding masking / nodata / alpha.
      + cannot update an output dataset
      + all input datasets must have same projection


* gdalwarp:
   - pros:
        + handles properly nodata / mask / alpha in input datasets (with alpha blending for alpha)
        + several resampling methods.
        + can deal with input datasets in different projections
        + can update an existing output dataset
   - cons:
        + can lead to datasets larger than needed with compression methods (unless -wo OPTIMIZE_SIZE=TRUE).
        + May be slower than other methods.


* gdal_merge.py:
     - pros:
         + handles nodata / mask in input dataset (alpha seen as binary mask)
         + can update an existing output dataset
    - cons:
         + only nearest resampling
         + cannot deal with arbitrarily large input datasets (ingests each input dataset fully in memory)
         + not friendly for compressed output
         + all input datasets must have same projection


So indeed gdal_merge.py could potentially be emulated with gdalbuildvrt+gdal_translate if there's no
overlap between input datasets or if they don't have nodata/mask, and otherwise on gdalwarp.

Exercice left to readers :-)

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com