Hi Even,
Am 19.06.2015 um 23:53 schrieb Even Rouault:
Actually keeping the RPC metadata as it is found in the sources (with the
exception of Pleiades and their weird center of pixel (1,1) convention
perhaps, as proposed in
https://trac.osgeo.org/gdal/attachment/ticket/5993/fix_PleiadesRPC.patch
Le lundi 22 juin 2015 08:29:18, Pablo d'Angelo a écrit :
Hi Even,
Am 19.06.2015 um 23:53 schrieb Even Rouault:
Actually keeping the RPC metadata as it is found in the sources (with the
exception of Pleiades and their weird center of pixel (1,1) convention
perhaps, as proposed in
Le vendredi 19 juin 2015 23:00:18, Frank Warmerdam a écrit :
Even,
I feel that the RPC coefficients have well establish meanings from the
NITF spec, and file formats like _rpc.txt. I assume they are
center-of-pixel oriented.
I couldn't find anything explicit about that when skimming
Even,
I feel that the RPC coefficients have well establish meanings from the
NITF spec, and file formats like _rpc.txt. I assume they are
center-of-pixel oriented. I would *not* want the RPC metadata we keep
(ie https://trac.osgeo.org/gdal/wiki/rfc22_rpc) to have a different
meaning for the
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
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
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,
