Using the Gdal library RPC correction problem

It's going to be gdal. After the Library update 1.11 version number, write the RPC error correction model before discovering the result is particularly large (the version number before the result of the update and the PCI result is the same). Therefore, the preliminary inference is the Gdal library bug, after the various changes found that the original is the specified DEM sample mode caused.

When the specified Dem is of the nearest neighbor, the correction result is very biased, and when the DEM is taken as a bilinear sample and three cubic convolution, the result is the same as the previous result. 1 of what you see. The red area is the control area, 2 see.

Figure 1 Full map of PCI correction results

Figure 2 the red area in Figure 1 zooms in on the actual pixel to show the result

The following is the result of the correction using the Gdalwarp tool plus an affine correction model. First use the DEM for the nearest neighbor sample, Gdalwarp command line such as the following:

gdalwarp-of gtiff-tr 2.5 2.5-t_srs ESRI:: "D:\WGS_1984_UTM_Zone_50N.prj"-rpc-r cubic-wm 1024-to "rpc_affine=-32.6737 6693 0.99919599 0.00013941 28.71988840 0.00062236 1.00004356 "-to" Rpc_dem=d:\data\ ortho correct basic data \dem data \beijing_all2.img "- To "Rpc_deminterpolation=near" D:\Data\711_214_26sep2006_p5\SrcData\bandf.tif D:\bandf_rpc1.tif--config Gdal_ Filename_is_utf8 NO

the results of the treatment are compared with the PCI results as seen in Figure 3.

Figure 3 Gdal specifying dem interpolation as the nearest neighbor processing result

Next, you specify that the DEM re-sampling mode is bilinear. The code and processing results such as the following:

gdalwarp-of gtiff-tr 2.5 2.5-t_srs ESRI:: "D:\WGS_1984_UTM_Zone_50N.prj"-rpc-r cubic-wm 1024-to "rpc_affine=-32.6737 6693 0.99919599 0.00013941 28.71988840 0.00062236 1.00004356 "-to" Rpc_dem=d:\data\ ortho correct basic data \dem data \beijing_all2.img "- To "Rpc_deminterpolation=bilinear" D:\Data\711_214_26sep2006_p5\SrcData\bandf.tif D:\bandf_rpc2.tif--config Gdal_ Filename_is_utf8 NO

The results of the treatment are compared with the PCI results as seen in Figure 4.

Figure 4 Gdal specifies that the DEM interpolation is a bilinear processing result

Next specify the DEM re-sample mode as three cubic convolution, the code and processing results such as the following:

gdalwarp-of gtiff-tr 2.5 2.5-t_srs ESRI:: "D:\WGS_1984_UTM_Zone_50N.prj"-rpc-r cubic-wm 1024-to "rpc_affine=-32.6737 6693 0.99919599 0.00013941 28.71988840 0.00062236 1.00004356 "-to" Rpc_dem=d:\data\ ortho correct basic data \dem data \beijing_all2.img "- To "Rpc_deminterpolation=cubic" D:\Data\711_214_26sep2006_p5\SrcData\bandf.tif D:\bandf_rpc3.tif--config Gdal_ Filename_is_utf8 NO

the results of the treatment are compared with the PCI results as seen in Figure 5.

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvbgltaw5sdtazmtq=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "width=" 720 "height=" 560 "style=" font-size:12px; "/>

Figure 5 Gdal Specifies that the DEM is interpolated with three cubic convolution results

Change Gdal source code of the file Gdal_rpc.cpp two place, is to change Gdt_int32 to Gdt_float64. The very easy reason is that the variable Dfdmeh is a double type. When reading the data, it is also necessary to read according to the double type, and the original code is read according to the Int32 type, which causes the problem of the DEM elevation value to be read.

The code after the change is shown in Figure 6, together with two. Both coordinate positive and inverse transformations need to be changed.

watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqvbgltaw5sdtazmtq=/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/ Dissolve/70/gravity/southeast "/>

Figure 6 The Gdal code after the change

After the change, you can compile gdal again. Using the modified program, specify that the DEM is interpolated to the nearest post-processing result of 7.

Fig. 7 Comparison of the results of the positive shots after the changeThe issue has been fed back to the Gdal development group. The detailed address is: http://trac.osgeo.org/gdal/ticket/5553. It is expected that the future version number will be corrected.

Copyright notice: This article blog original article. Blogs, without consent, may not be reproduced.

Using the Gdal library RPC correction problem