<div dir="ltr"><div><div>Hi Jukka,<br><br></div>I think it is a problem with the hosting service... Sorry...<br><br><a href="https://dl.dropboxusercontent.com/u/5772257/qgis/Testes.zip" target="_blank">https://dl.dropboxusercontent.com/u/5772257/qgis/Testes.zip</a> <br><br><br><br></div>Hi Even,<br><div><div><div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>

This a known behaviour of gdalwarp. See<br>
<a href="https://trac.osgeo.org/gdal/ticket/4344" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/4344</a><br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, it is exactly this problem!<br><br>-crop_to_cutline (Crop the extent of the target dataset to the extent of the cutline) adjusts the output raster to the cutting polygon limit, which maybe why gdalwarp is using that 50% of the pixel to establish the limit. So, seen from this perspective, I do not know if this is actually a GDAL bug, because in reality it does what the parameter says, right?<br><br>gdalwarp tool used in QGIS is adding -crop_to_cutline parameter by default, and it leads to the problem.<br><br></div><div>Thanks!<br><br></div><div>Best regards,<br></div><div>Pedro<br></div><div><br></div></div><br></div></div></div></div></div>