Le vendredi 04 septembre 2015 21:29:02, vous avez écrit : > Hi > > On Thu, Sep 3, 2015 at 10:58 AM, Even Rouault > > <[email protected]> wrote: > > This occurs in the middle of a source tile, or at the boundary between 2 > > tiles ? > > In the middle of a source file. > > > Just to be sure: you mean you are using the above -s_srs and -t_srs on > > one of the tile that makes the ortho2014.vrt ? > > Yes. > > > And what if you make a VRT with just that source image ? > > I think it has nothing to do with the VRT. Using the gdalwarp command > on a single tif file it has the same breaking edge when using the -te > option. I did try the -et 0 option. Same error but not at the same > place (but only few pixels to the left) and much slower. > > gdalwarp -overwrite -s_srs "+proj=somerc +lat_0=46.952405555555555 > +lon_0=7.439583333333333 +ellps=bessel +x_0=600000 +y_0=200000 > +units=m +k_0=1 +nadgrids=./chenyx06a.gsb" -t_srs "+proj=somerc > +lat_0=46.952405555555555 +lon_0=7.439583333333333 +ellps=bessel > +x_0=2600000 +y_0=1200000 +units=m +k_0=1 +nadgrids=@null" -tr 0.125 > 0.125 -te 2611000 1233000 2612000 1234000 -co 'TILED=YES' > 611233_12_5cm.tif 2611_1233_12_5cm.tif
Stefan, as you work with sub-meter accuracy, forcing the bounds to nearest meter, while using the default resampling (nearest neighbour) is the likely cause. The issue seems to be a pixel shift in the vertical direction, likely due to a pixel coordinate expressed as a floating point value being rounded suddenly from the floor integer to the the ceiling integer. I've quickly tried with cubic resampling (-r cubic) and the result seems to be much better/smoother. Bilinar could probably work as well. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
