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

[Stefan Ziegler]

Even,

what suprises me is that the following workaround shows not artefacts:

1) gdalwarp a larger part of the desired bouding box (keep SRS)
2) gdalwarp to the target srs
3) gdalwarp for cutting to desired bounding box with -tr and -te option.

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'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