<div dir="auto"><div>Thank you Even for the prompt reply.<div dir="auto">I'll have a look into the vrt workaround, in my case the deformations aren't enormous so applying a buffer at vrt creation time would probably be sufficient provided the overviews are taken into account.</div><div dir="auto">However for the computesourcewindow proposition which I'd like to look into, I imagine it would be an explicit option passed into gdalwarp_lib that would trigger the behaviour; is that in line with your understanding?</div><div dir="auto">Best regards,</div><div dir="auto">Thomas</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 17 juil. 2020 à 19:01, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div style="font-family:'monospace';font-size:9pt;font-weight:400;font-style:normal">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Hi Thomas,</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> * I added the -to AREA_OF_INTEREST= options while trying to debug the issue</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> but it makes no difference with or without it</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Yes, -to AREA_OF_INTEREST is only taken into account for informing PROJ of the area of interest in its choice of candidate transformations when datum transformations are involved. So completely useless here (and likely in most other cases as well, unless to cut a bit computation time in PROJ when researching candidate coordinate transformation pipelines)</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> Is there an easy way to fix this? Or could there be an initial first step</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> that programatically sets the -ovr AUTO-N parameter depending on the size</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> of the source window that is going to be used?</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">The issue you observe comes from using GDALSuggestedWarpOutput2()</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><a href="https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalwarp_lib.cpp#L2308" target="_blank" rel="noreferrer">https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalwarp_lib.cpp#L2308</a></p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">that looks at reprojecting the whole source dataset, without taking into account the potential restriction of the target extent set by -te. I guess using GDALWarpOperation::ComputeSourceWindow() instead would be more appropriate. You could file a ticket about that.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">A workaround (untested) in the mean time could be that you restrict your input dataset as a VRT that includes "just" the needed source pixels. You could probably try do that automatically with gdal_translate -projwin with bounds in the the target SRS and -projwin_srs being that target SRS. However I'm not sure how well it will guess the source pixels (-projwin_srs effect is quite naive: it just reprojects the upper-left and lower-right corners of -projwin. No fancy sampling along the edges of the bounding box). So you might need to code something smarter to create that source VRT. Or add sufficient margins to coordinates passed to projwin so that the VRT includes the needed source pixels.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">I'd expect access to overviews of the source file should still work through VRT.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Even</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">-- </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Spatialys - Geospatial professional services</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><a href="http://www.spatialys.com" target="_blank" rel="noreferrer">http://www.spatialys.com</a></p></div></blockquote></div></div></div>