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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
