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