[gdal-dev] RPC orthorectification accuracy issues.

[Even Rouault]

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.rouault at 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 at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com