[gdal-dev] RPC orthorectification accuracy issues.

[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

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com