[gdal-dev] current geolocation array implementation status

[Frederico Liporace]

Even, Frank,

Thanks for the feedback. I found that for the case I reported the
artifacts are being generated in the backmap gap filling process, this
is removing the internal gaps as expected but is also incorrectly
extending the backmap outside the valid area, effectively replicating
the pixel values on the input image borders.

I'm working on a possible fix and getting used to the algorithm that
is currently implemented.

I think that the Landsat TM/ETM approach could be an interesting idea
for a new implementation. It defines a regular grid in the input space
and an algorithm to find the corresponding input cell for any pixel in
the output space. The algorithm is detailed in section 3.1.5.3.6.4 of
the Landsat 7 Image Assessment System Geometric ATBD (*), figures
3-25/26/27 gives a gist of the algorithm.

rgds.,

(*) https://www.usgs.gov/media/files/landsat-7-image-assessment-system-geometric-atbd

On Wed, Nov 3, 2021 at 10:14 AM Frank Warmerdam <warmerdam at pobox.com> wrote:
>
> Frederico,
>
> 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.
>
> I am also still interested in the general topic of iterative approximate inverses for transformers which are not inherently invertible.
>
> Best regards,
> Frank
>
>
> On Tue, Nov 2, 2021 at 1:18 PM Even Rouault <even.rouault at spatialys.com> wrote:
>>
>> 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
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | +1 650-701-7823
> and watch the world go round - Rush    | Geospatial Software Developer