[gdal-dev] gdalwarp - dataset shifted several metres compared to arcgis

Even Rouault even.rouault at spatialys.com
Fri Jan 27 02:46:15 PST 2017


On vendredi 27 janvier 2017 01:59:30 CET jratike80 wrote:
> Nicole Stoffels wrote
> 
> > Hi,
> > 
> > I am trying to reproject the CORINE 2012 dataset from LAEA (EPSG:3035)
> > to UTM 32 (EPSG:32632). I use the following command:
> > 
> > $ gdalwarp -overwrite -s_srs EPSG:3035 -t_srs EPSG:32632 -tr 100 100
> > -tap -dstnodata '-9999' g100_clc12_V18_5.tif corine2012_utm32n_test.tif
> > 
> > In the past years my colleague used ArcGIS for this operation, but since
> > we switched to Linux, I have to find a new solution. When I load the new
> > dataset generated with gdalwarp to QGIS and compare it with the old 2006
> > version built in ArcGIS, I have an offset of approximately 15m south and
> > 3m east for the single raster squares.
> > 
> > Now I am not sure if I simply forgot an important flag in my
> > gdalwarp-command or if the problem simply lies within ArcGIS (my
> > colleague used the standard options that were proposed).
> > 
> > Thank you for any ideas,
> 
> Shift is small, 15 and 3 meters, compared to the pixel size, 100 m. Anyway,
> the reason for the difference is probably in where ArcGIS and GDAL decides
> to place the origin when they warp the extents of the image. Target aligned
> pixels can for sure shift the origin because that's why the option exists.
> ArcGIS and GDAL may still compute the origin into slightly different places
> if they do not use exactly same code for warping.
> 
> I would have a try by defining the output extents exactly with -te. But
> first I would re-think if sub-pixel shifts are meaningful at all.
> 

As nearest neighbour is used here (default resampling), it can easily cause sub-pixel shift. 
Using -r bilinear or -r cubic should improve sub-pixel accuracy.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170127/2839b211/attachment-0001.html>


More information about the gdal-dev mailing list