[gdal-dev] "wrong" overview selected when warping from ortho to webmercator

[thomas bonfort]

Thank you Even for the prompt reply.
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.
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?
Best regards,
Thomas


Le ven. 17 juil. 2020 à 19:01, Even Rouault <even.rouault at spatialys.com> a
écrit :

> Hi Thomas,
>
>
>
> > * I added the -to AREA_OF_INTEREST= options while trying to debug the
> issue
>
> > but it makes no difference with or without it
>
>
>
> 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)
>
>
>
> > Is there an easy way to fix this? Or could there be an initial first step
>
> > that programatically sets the -ovr AUTO-N parameter depending on the size
>
> > of the source window that is going to be used?
>
>
>
> The issue you observe comes from using GDALSuggestedWarpOutput2()
>
> https://github.com/OSGeo/gdal/blob/master/gdal/apps/gdalwarp_lib.cpp#L2308
>
> 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.
>
>
>
> 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.
>
> I'd expect access to overviews of the source file should still work
> through VRT.
>
>
>
> 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/20200717/86b09230/attachment.html>