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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
