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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev