Yes, I am sure I entered the -te parameters correctly. When I also use -tr to specify the output pixel size, I get the correct result in this one test case. Is there no other option than this work around? It seems like some sort of systematic issue with RPCs that would be good to address at the source.
I will test some more and let you know if the work around fails in any cases. Thanks, Claire On Mon, Apr 9, 2012 at 1:02 PM, Etienne Tourigny <etourigny....@gmail.com> wrote: > The error you get can usually be avoided when you set the output > bounds correctly. Are you sure the -te options you use are correct? > > ERROR 1: Too many points (441 out of 441) failed to transform, unable > to compute output bounds > > > > On Mon, Apr 9, 2012 at 1:57 PM, Claire Porter <claire.por...@gmail.com> wrote: >> Etienne, >> >> When I set the extents using -te, I get an output of size 0. I think >> the problem is not in the warping itself, but in the transformation >> using the RPCs. >> >> Thanks, >> Claire >> >> >> On Mon, Apr 9, 2012 at 10:04 AM, Etienne Tourigny >> <etourigny....@gmail.com> wrote: >>> Claire, >>> >>> You may have to set the output extents manually with the -te option. >>> >>> This has been the solution to many problems with gdalwarp. >>> >>> Etienne >>> >>> >>> On Mon, Apr 9, 2012 at 11:12 AM, Claire Porter <claire.por...@gmail.com> >>> wrote: >>>> Dmitry (and the list), >>>> >>>> Using the warp options you suggested does not make a difference. Even >>>> SAMPLE_GRID does not significantly change the output. I also tried using >>>> wgs84 as the output coordinate system in case it was an issue of being >>>> projected into Polar Stereographic: no luck. >>>> >>>> I copied the relevant functions from gdal_rpc.cpp into python order to test >>>> the RPC calculations independant of the warping functions and any >>>> projection >>>> system. I used a sampling grid over the whole extent of whatever test >>>> image >>>> and found that the RPCs do not converge for any part of the error-prone >>>> images In fact, with each iteration the offset from the original pixel >>>> gets >>>> further and further from zero (alternating sign each iteration). >>>> >>>> From these tests, I am guessing that the issue is not the sampling or the >>>> projection system. Since other software packages can handle these images, >>>> I >>>> assume then that the issue is in how gdal is managing the RPCs. Any ideas? >>>> >>>> Many thanks, >>>> Claire >>>> >>>> _______________________________________________ >>>> gdal-dev mailing list >>>> gdal-dev@lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
