[gdal-dev] Call for discussion on RFC 51: RasterIO() improvements : resampling and progress callback

[Even Rouault]

Jukka,

> 
> Gdaladdo seems to lose some resampling algorithms.

Ah, the text of the RFC wasn't clear enough. Bilinear, cubicspline and lanczos 
are *additional* algorithms to the existing ones.

> The damage with
> average_mp can't be big by reading the comment from the gdaladdo manual
> page "average_mp is unsuitable for use. Average_magphase averages complex
> data in mag/phase space."
> 
> Gdaladdo now:
> -r {nearest (default),average,gauss,cubic,average_mp,average_magphase,mode}
> Gdaladdo once RFC 51 is implemented:
> -r parameter now accepts bilinear, cubicspline and lanczos as algorithms.
> 
> Otherwise I have not much to say about this RFC. "Blurring" has two r's,

Fixed

> and I think that it is good that gdal_translate will be able to use
> different resampling methods and there will be no need to use gdalwarp if
> warping is really not needed.

Yes, this can be significantly faster with gdal_translate -r since the 
resampling algorithms of overview computation that are used can use more 
optimizations than the general purpose ones of warping.

> 
> If you will touch gdal_translate anyway and it will do good job with
> resampling I would like to see the same -tr option than in gdalwarp for
> setting target resolution simply without a need to play with -outsize plus
> -srcwin or -projwin.

That's not technically correlated with the RFC, but I see your point. I'll see 
to add this. Note that this will not allow changing alignment of the origin as 
you can do with gdalwarp -te/-tap: that would require VRT offsets to be 
specified as floating point values.

Even

> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

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