[Gdal-dev] Dealing with RPC offsets and parameters in GDAL

[Ozy Sjahputera]

Thanks for the info, Frank.

I was hoping we can solve this using GDAL.  We are given a bunch of 1B
level images .... they are ortho-ready, but some rectification need to
be done to correctly co-register the Pan and MS before we can create the
pansharpened MS. 

Ozy

Frank Warmerdam wrote:
> Ozy Sjahputera wrote:
>> my colleagues and I were given a set of NITF images.  We found that the
>> pan and multispectral image of the same scene do not always
>> co-registered correctly.  When this happens, we found that some of the
>> RPC parameters in the two images, such as RPC_LONG_OFF, RPC_LONG_SCALE,
>> RPC_LAT_OFF, RPC_LAT_SCALE, RPC_HEIGHT_OFF, and RPC_HEIGHT_SCALE, hold
>> different values.
>> We thought that we can correct the co-registration problem by *somehow*
>> matching the values of these RPC parameters in both pan and MS.
>> Changing these parameters would be done by applying some RPC-based
>> transformation, correct?
>>
>> Do you have any information or examples on how to deal with RPC-based
>> transformation in GDAL?
>>
>> I have found some RPC related functions in GDAL, such as
>> GDALCreateRPCTransformer().  I am still tracing how to get the
>> GDALRPCInfo object needed by GDALCreateRPCTransformer().  I have found a
>> function called GDALExtractRPCInfo() in gdal_misc.cpp that takes a char
>> ** , extracts the RPC parameters from the string array, and saves them
>> in a GDALRPCInfo object.  But I am still unclear how to obtain the
>> string array containing the RPC parameters from the image metadata of an
>> NITF image.
>>
>> Any info on RPC related functions in GDAL you can share with me will be
>> very helpful.
>
> Ozy,
>
> I imagine you are on the right track, but I don't know how practical it
> will be to establish correspondance.
>
> The char ** argument to GDALExtractRPCInfo() is the metadata list
> containing
> the parameters.  That is, the list you would get back from a call to
> GDALGetMetadata() on the dataset.
>
> Note that the GDAL RPC Transformer does *not* use a variable elevation
> model, and should be considered suitable only for gross geolocation, not
> the precision geolocation for which RPCs were intended.
>
> Loosely speaking, GDAL does a good job of reading RPC parameters, but
> it does not offer good tools to exploit them.  They were really
> implemented
> for applications that had their own higher level RPC algorithms.
>
> Best regards,