Re: [gdal-dev] RPC orthorectification accuracy issues.
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 ?), and doing the adjustment in the computation will be less disruptive for the existing code than modifying the RPC metadata values for a half-pixel shift in all deserializing/serializing .rpb and _rpc.txt code (+ you'd have to make a special case when deserializing/serializing the RPC metadata domain in .aux.xml and VRT !), so on reflection, I'm happy with Pablo's approach. I think this is also nicer for third party applications that use the GDAL RPC metadata. Changing the LINE_OFF and SAMP_OFF would also require changes in third party code. Best regards, Pablo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC orthorectification accuracy issues.
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 https://trac.osgeo.org/gdal/attachment/ticket/5993/fix_PleiadesRPC.patch ?), and doing the adjustment in the computation will be less disruptive for the existing code than modifying the RPC metadata values for a half-pixel shift in all deserializing/serializing .rpb and _rpc.txt code (+ you'd have to make a special case when deserializing/serializing the RPC metadata domain in .aux.xml and VRT !), so on reflection, I'm happy with Pablo's approach. I think this is also nicer for third party applications that use the GDAL RPC metadata. Changing the LINE_OFF and SAMP_OFF would also require changes in third party code. Pablo, I've applied your patches (with very slight modifications) to trunk and 2.0 branch. Best regards, Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC orthorectification accuracy issues.
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 through http://geotiff.maptools.org/STDI-0002_v2.1.pdf but you're likely right, and anyway Pablo's investigations confirm it. (although when looking at nitfimage.c, NITF has a record of being inconsistant w.r.t that convention, at least for GCPs. IGEOLO is center-of-pixel. RPF CoverageSectionSubheader is edge-of-pixel. BLOCKA is center-of-pixel. GEOLOB is edge-of-pixel !) 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 pixel/line locations. So I would suggest we should not need to transform the RPC coefficients when they are imported - instead it is the evaluator which needs to adapt between the RPC pixel/line model and the usual GDAL interpretation. I'll note this opinion in the ticket as well. This is going to be moderately distruptive. :-( 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 ?), and doing the adjustment in the computation will be less disruptive for the existing code than modifying the RPC metadata values for a half-pixel shift in all deserializing/serializing .rpb and _rpc.txt code (+ you'd have to make a special case when deserializing/serializing the RPC metadata domain in .aux.xml and VRT !), so on reflection, I'm happy with Pablo's approach. We would just need to document it that better in https://trac.osgeo.org/gdal/wiki/rfc22_rpc and http://www.gdal.org/gdal_datamodel.html My initial point was mainly for being consistant with what we do for geotransform and GCP (standardizing on edge of pixel), but the structures in which that information is stored are rather GDALish (and the conventions among formats so different that you have to pick up one) whereas RPC metadata is indeed more standardized. Pablo - thank you for bringing this to light! Best regards, Frank On Fri, Jun 19, 2015 at 7:35 AM, Even Rouault even.roua...@spatialys.com wrote: 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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC orthorectification accuracy issues.
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 pixel/line locations. So I would suggest we should not need to transform the RPC coefficients when they are imported - instead it is the evaluator which needs to adapt between the RPC pixel/line model and the usual GDAL interpretation. I'll note this opinion in the ticket as well. This is going to be moderately distruptive. :-( Pablo - thank you for bringing this to light! Best regards, Frank On Fri, Jun 19, 2015 at 7:35 AM, Even Rouault even.roua...@spatialys.com wrote: 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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC orthorectification accuracy issues.
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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] RPC orthorectification accuracy issues.
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 gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
