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

[thomas bonfort]

Ferdinand,
(re-adding gdal-dev after having exchanged off-list)
For your image with FIRST_COL set, you MUST use a gdal with
https://github.com/OSGeo/gdal/pull/7653 included. The initial
implementation in 5725 was incorrect in two ways: firstly
ImagetoGround_Validity_Domain.* is informative only, and should never be
used when applying RPCs. Secondly, as you noticed, that implementation only
read FIRST_COL and applied it to both SAMP_OFFSET and LINE_OFFSET.
Concerning your particular product there was an error that occurred during
the image production, and you should reach out to airbus's customer care
for support.

best regards,
Thomas

On Mon, Jul 24, 2023 at 7:00 PM Ferdinand <fwschenck at gmail.com> wrote:

> 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
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230726/b254bbd8/attachment.htm>