[gdal-dev] RPC orthorectification accuracy issues.

[Dmitry Baryshnikov]

Hi,
I think the vendor specific shifts should be accepted to RPC while 
reading via mdreader or something same. So the fix_PleiadesRPC.patch 
looks good.
Also about changing alg/gdal_rpc.cpp: мaybe the addition config key, 
i.e. RPC_SHIFT which will be 0.5 as default value?

Best regards,
     Dmitry

19.06.2015 17:35, Even Rouault пишет:
> Le vendredi 19 juin 2015 15:47:54, Pablo d'Angelo a écrit :
>> Dear GDAL Developers,
>>
>> i have recently compared the results of our internal RPC based
>> orthorectification software and have found several difference, which I
>> think are due to various "corner" vs "center" of pixel issues in the RPC
>> transform code. This lead to significant shifts when using lower
>> resolution DEMs, such as SRTM, particularly in hilly and mountainous
>> regions.
>>
>> I have prepared an analysis and patches to fix these issues at:
>> https://trac.osgeo.org/gdal/ticket/5993
> Hi Pablo,
>
> I had seen your well documented ticket and wanted to give feedback. Thanks for
> the reminder.
> To my opinion, adjustments between "vendor"/formats conventions and the GDAL
> convention (0,0=upper-left corner of upper-lef pixel) should be done during
> the reading of the RPC parameters from their source (similarly to what is done
> when reading a geotransform with pixel-is-center convention), so as to make
> the
> https://trac.osgeo.org/gdal/attachment/ticket/5993/fix_RPCTransformPoint.patch
> patch unnecessary.
> Apart .rpb and .rpc_txt, we can also read RPC from GeoTIFF, NITF, ENVI,
> Oracle, PCIDSK... so I'm wondering what our situation is related to them.
> Of course this also leaves the embarassing question of which convention to
> adopt when writing RPC values in .rpb or _rpc.txt files... Probably DG
> convention for .rpb ?
>
> fix_rpc_dem_interpolation.patch looks good to me.
>
> Even
>