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 > > <[email protected]> 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 > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
