[gdal-dev] Non-zero FIRST_COL, FIRST_ROW for PNeo ImagetoGround_Validity_Domain

[Ferdinand]

Hi All,

We're seeing some major geolocation offsets in PNeo images (order of 1000m,
depending on specific image).

I think I have tracked it down to having something to do with the validity
domain.
In the cases where I see the offset, I often have metadata that looks like:

<ImagetoGround_Validity_Domain>
>   <FIRST_COL>-531</FIRST_COL>
>   <FIRST_ROW>-3182</FIRST_ROW>
>   <LAST_COL>33374</LAST_COL>
>   <LAST_ROW>27699</LAST_ROW>
> </ImagetoGround_Validity_Domain>
>


>From what I can grok from the code, it's an assumption that FIRST_COL and
FIRST_ROW be 0 for PNeo, as discussed here:
https://github.com/OSGeo/gdal/issues/5716

In an earlier version (than 3.7.1), FIRST_COL was manually subtracted from
the line offset shift (https://github.com/OSGeo/gdal/pull/5725/files), but
that was reverted later, with the topLeftOffset manually set to 1 for PNeo:
https://github.com/OSGeo/gdal/pull/7653/files

Can it be that this shift is not accounted for?

Basically, we create tifs by running gdal_translate on the DIM XML file,
resulting in a tif with the RPC info inside.

Doing so on the same image for gdal 3.7.0 and 3.7.1 results in a diff of:

> 89c88
> <   LINE_OFF=12836
> ---
> >   LINE_OFF=12305
> 95c94
> <   SAMP_OFF=16819.5
> ---
> >   SAMP_OFF=16288.5
> 104,105d102
>

in the header.

The LINE_OFF gets shifted by 531 pixels, which is to be expected, but the
SAMP_OFF also gets shifted by 531 pixels, which should not happen, right?

Validating  in QGIS, the distance between Google Satellite and the one
tower is 777m, at 30cm = 2590 pixels.
2590 + 531 = 3121, so within a misclick of 3182


Doing something a bit atrocious I subtracted FIRST_ROW from the LINE_OFF (
https://github.com/fnands/rpcm/blob/1d4205d967985cfcc2426c3fd881352ce5b5ac46/rpcm/rpc_file_readers.py#L235),
as well as adding FIRST COL to both, and then overwriting the RPC info.
 This gets me pretty close, as least by visual inspection.

The diff between the manual one and the raster created with 3.7.1 is:

> 88c89
> <   LINE_OFF=12305
> ---
> >   LINE_OFF=14955
> 94c95
> <   SAMP_OFF=16288.5
> ---
> >   SAMP_OFF=15756.5
> 102c103
>


I feel like I am missing something here, and I am just throwing things at
the wall and seeing what sticks.
If someone can help me get a more fundamental understanding of what is
going wrong here I would greatly appreciate it.
Is this offset taken into account somewhere else?

Importantly, this is DIMAP v3, so not sure if that breaks anything. Waiting
on our provider to send me some docs, as the latest ones I have for the RPC
reference v2.


Cheers,

Ferdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230724/fc516006/attachment.htm>