<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Frederico,</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">I've updated the ticket to reflect that I backed away from work on a new implementation.  I would still like to see a reliable geolocation transformer. </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">I am also still interested in the general topic of iterative approximate inverses for transformers which are not inherently invertible. </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:arial,sans-serif">Frank</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 2, 2021 at 1:18 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Frederico,<br>
<br>
Le 01/11/2021 à 23:22, Frederico Liporace a écrit :<br>
> Hello,<br>
><br>
> I'm debugging an artifact that I encountered while using geolocation arrays:<br>
> <a href="https://github.com/OSGeo/gdal/issues/4707" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/issues/4707</a><br>
><br>
> While searching I found this ticket mentioning that the backward map<br>
> implementation is broken and a new implementation is being considered:<br>
> <a href="https://trac.osgeo.org/gdal/ticket/6959" rel="noreferrer" target="_blank">https://trac.osgeo.org/gdal/ticket/6959</a><br>
><br>
> I could help with this implementation. Is there more context available<br>
> on why it is being reconsidered? It seems to me that the general case<br>
> for the backward implementation is very hard - for instance, what kind<br>
> of discontinuities (gaps, overlaps) would be allowed in the<br>
> geolocation array? Would it be expected to be robust enough to correct<br>
> the Landsat 7 ETM+ SLC-off for instance? My guess is not.<br>
<br>
Yes the general case is likely hard and would probably require special <br>
techniques that could possibly be sensor specific. I guess the <br>
requirements for improvements on the existing code would be at least not <br>
degrade what works currently.<br>
<br>
An idea for a new implementation would be to use an iterative process <br>
using the backward map as an initial guess and then iterating with the <br>
bilinear interpolation of the forward path to refine the solution up to <br>
convergence to some threshold of error to decide (could be 15% of a <br>
pixel size like the default setting of the gdalwarp approximate <br>
transformer of coordinate transformations)<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="monospace">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | +1 650-701-7823<br>and watch the world go round - Rush    | Geospatial Software Developer</font></div></div></div></div></div>