Frederico,
Le 01/11/2021 à 23:22, Frederico Liporace a écrit :
Hello,
I'm debugging an artifact that I encountered while using geolocation arrays:
https://github.com/OSGeo/gdal/issues/4707
While searching I found this ticket mentioning that the backward map
implementation is broken and a new implementation is being considered:
https://trac.osgeo.org/gdal/ticket/6959
I could help with this implementation. Is there more context available
on why it is being reconsidered? It seems to me that the general case
for the backward implementation is very hard - for instance, what kind
of discontinuities (gaps, overlaps) would be allowed in the
geolocation array? Would it be expected to be robust enough to correct
the Landsat 7 ETM+ SLC-off for instance? My guess is not.
Yes the general case is likely hard and would probably require special
techniques that could possibly be sensor specific. I guess the
requirements for improvements on the existing code would be at least not
degrade what works currently.
An idea for a new implementation would be to use an iterative process
using the backward map as an initial guess and then iterating with the
bilinear interpolation of the forward path to refine the solution up to
convergence to some threshold of error to decide (could be 15% of a
pixel size like the default setting of the gdalwarp approximate
transformer of coordinate transformations)
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
