[gdal-dev] gdalwarp different results (vrt vs direct)

[Even Rouault]

Le samedi 05 septembre 2015 22:59:00, Stefan Ziegler a écrit :
> Even,
> 
> what suprises me is that the following workaround shows not artefacts:
> 
> 1) gdalwarp a larger part of the desired bouding box (keep SRS)

If no reprojection is involved and no resizing is involved, then gdalwarp 
basically does what gdal_translate does, so it is expected that there's no 
artifacts

> 2) gdalwarp to the target srs

If you don't constraint the result, the automatically selected bounds might 
limit the artifacts, without guarantee...

> 3) gdalwarp for cutting to desired bounding box with -tr and -te option.

Your descripton of 3) looks very much like your not_working.sh, so...

> 
> All gdalwarp commands with nearest neighbor. Sounds this
> comprehensible for you? Or is it just by accident (and/or I did not
> found an existing breaking edge)?

I'd say accident. For high quality result, nearest neighbour isn't advised.

> 
> I'm gonna try the original command with the different resampling
> options as you proposed.
> 
> regards
> Stefan
> 
> On Fri, Sep 4, 2015 at 11:26 PM, Even Rouault
> 
> <even.rouault at spatialys.com> wrote:
> > Le vendredi 04 septembre 2015 21:29:02, vous avez écrit :
> >> Hi
> >> 
> >> On Thu, Sep 3, 2015 at 10:58 AM, Even Rouault
> >> 
> >> <even.rouault at spatialys.com> 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

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