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@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev