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
[gdal-dev] Motion: Adopt RFC 26: GDAL Block Cache Improvements
Hi, As no points have been raised on the RFC: Motion : I move to adopt RFC 26: GDAL Block Cache Improvements https://trac.osgeo.org/gdal/wiki/rfc26_blockcache Starting with my +1 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
[gdal-dev] RPC orthorectification accuracy issues.
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 However I'm not very familiar with the GDAL development workflow. Should changes like those be discussed on the list, or just added to a ticket? Best regards, Pablo d'Angelo -- Deutsches Zentrum für Luft- und Raumfahrt (DLR) Earth Observation Center | Institut für Methodik der Fernerkundung | Oberpfaffenhofen | 82234 Weßling Dr.-Ing. Pablo d'Angelo www.DLR.de/eoc ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR support for Interlis 2 - Geometry issue
Hello, I am trying to read the interlis 2 data (.xtf file) into my application using GDAL/OGR library. The application could read feature and field definitions but unable to read the Geometry. e.g. ogr.GeometryTypeToName( featDefn.GetGeomType() ) returning Unknown (any) and Geometry reference as null. It would be really helpful if somebody can share comments on this. P.S. : I tried to visualize the data using QGIS with Interlis 2 plugin, I am able to see the Geometry. Regards,Sameer Sheikh ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Adopt RFC 26: GDAL Block Cache Improvements
Even Rouault even.rouault at spatialys.com writes: Hi, As no points have been raised on the RFC: Motion : I move to adopt RFC 26: GDAL Block Cache Improvements https://trac.osgeo.org/gdal/wiki/rfc26_blockcache Starting with my +1 +0 Unfortunately I Can't say anything about the implementation so 0 but avoiding out of memory errors with large images is for sure worth +. -Jukka Rahkonen- ___ 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
