OSGeo
gdalwarp on a MSG1.5 Native product appears to cause a shift in the position of the pixels throughout the image
Expected behavior and actual behavior.
Using GDAL 3.6.2, the output of gdalwarp command on an input MSG1.5 Native product presents a shit of about one pixel. The shift appears to be independent of resampling method used.
Steps to reproduce the problem.
Using GDAL 3.6.2 run the following command to re-project an input MSG1.5 Native product (e.g MSG4-SEVI-MSG15-0100-NA-20220419091243.184000000Z-NA.nat) in geographic coordinate system:
gdalwarp -t_srs EPSG:4326 MSG4-SEVI-MSG15-0100-NA-20220419091243.184000000Z-NA.nat output.tiff
The following high-scale coastlines were used for comparison: CNTR_BN_01M_2020_4326_COASTL.shp.zip
The following image show the shift of about one pixel eastward for the input product MSG4-SEVI-MSG15-0100-NA-20220419091243.184000000Z-NA.nat (centre image: 24°N -14°E)
The shift occurs on other images I have tested, sometimes to the east sometimes to the south. Given the low resolution of the MSG-SEVIRI products, it is not easy to understand the presence and magnitude of the shift, however it seems to me that it is always present.
Operating system
Tested on both Rocky Linux 8.7 (Green Obsidian) and CentOS Linux 7 (Core)
GDAL version and provenance
GDAL 3.6.2
gdalwarp -t_srs EPSG:4326 MSG4-SEVI-MSG15-0100-NA-20220419091243.184000000Z-NA.nat output.tiff
@mdbmdb74 Could you retry with -r bilinear or -r cubic ? The default nearest neighbour resampling is not good to assess sub-pixel shifts.
@g8sqh I see you touched a bit of this area of georeferencing. Couldn't it be an issue of convention ? Typically GDAL sets the origin as the top-left corner of the top-left pixel. But there are a number of formats where the convention used is the center of the top-left pixel. When this is the case (I don't know if it is for MSGN), GDAL has to apply a shift of a half-pixel towards the north-west. Like geotransform[0] -= geotransform[1] / 2 and geotransform[5] -= geotransform[5] / 2
@rouault as I wrote in the issue description, the shift appears to be independent of resampling method used, I tested also with flag -r bilinear.