[gdal-dev] gdalwarp -rpc and RPC_DEM results and .TIL files

[Ivan Lucena]

Hi Dmitry,

I am implementing RPC support on a driver, that is why I am interested in see how that thing works using the available sample data from different data providers. Comparing with some software is also part of the game.

>  I orthorectify such products with comparable with Envi results. But,
>  exist TIL driver usually have SRS WGS84 and output raster lost in

That is what I was expecting, EPSG 3427 WGS84 3D, or something similar.

But the sample data I downloaded has in UTM on the Geotiff tags.

The gdalinfo of the .TIL file doesn't show any SRS but shows all the file association and the RPC metadata. 

So it should work better than the VRT solution that would use the UTN SRS for mosaicking with potential overlaps and gaps.

>  resolution on Y Axis. I correct driver and commit it (see ticket #3482
>  for details). Everything should be OK.

That ticket is about overview. 

>  Also you need to add RPC_HEIGHT with some value to correct geoid.
>  http://translate.google.ru/translate?sl=auto&tl=en&js=n&prev=_t&hl=ru&ie=UTF-8&eotf=1&u=http%3A%2F%2Fgis-lab.info%2Fqa%2Forbview3-ortho-gdal.html&act=url
>  

I am using Geoid correction values from NOAA when I run "gfawarp -rpc". Did you noticed a field where you could enter that value when you run the PCI tool? I also checked the accuracy and resolution of my DEM and I used the same one in all the "contenders".

Anyway, thank so very much for all you guys advise.

Regards,

Ivan

>  Best regards,
>       Dmitriy
>  
>  09.02.2013 3:33, Ivan Lucena :
>  > Hi there,
>  >
>  > Does anybody has ever tried to orthorectify an "Ortho Ready Standard"
>  > QuickBird image with .TIL files?
>  >
>  > To whom might be interested, there is a couple of sample data on
>  > digitalglobe.com and you can always find DEM on USGS.COM.
>  >
>  > Contrary to GDAL standards :) in most of those sample dataset the .RPB
>  > file are not directed associated to the Geotiff file. Like in
>  >
>  > some_file_name.tif
>  > some_file_name.rpb
>  >
>  > That is usually the case when the scene covered is too big and the
>  > data provider decided to dived it on tiles.
>  >
>  > The .TIL file describe the offsets in lines/pixel/X/Y of each of the
>  > tiles and the .RPB is related to the .TIL file. Like in:
>  >
>  > some_file_t1.tif
>  > some_file_t2.tif
>  > some_file_t3.tif
>  > some_file_name.til
>  > some_file_name.rpb
>  >
>  > Since GDAL does not support the .TIL file, what one needs to do is to
>  > use gdalbuildvrt to create a VRT to represent the same tilling as the
>  > .TIL file.
>  >
>  > At that point it is still not ready to do orthorectification yet
>  > because gdalwarp doesn't seems to digest the combination .VRT .RPB.
>  >
>  > some_file_name.vrt
>  > some_file_name.rpb
>  >
>  > But that is just a matter of converting the VRT to GTIFF and go ahead
>  > and run:
>  >
>  > gdalwarp some_file_name.tif the_output_name.tif -rpc -to
>  > RPC_DEM=the_dem_file.tif -t_srs EPSG:32610
>  >
>  > But after all that I can't see much more accuracy when overlaying a
>  > vector road map on top of the original non-orthorectified than over
>  > the orthorectified output. It is a little bit better in some places
>  > but worse in some others.
>  >
>  > I found much better results with datasets without tilling. I mean,
>  > without .TIL files. Just one GTIFF and one .RPB
>  >
>  > Has anybody had that same experience?
>  >
>  > Do we have plans to support the .TIL file in GDAL?
>  >
>  > Best regards,
>  >
>  > Ivan
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > _______________________________________________
>  > gdal-dev mailing list
>  > gdal-dev at lists.osgeo.org
>  > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>  >
>  
>  _______________________________________________
>  gdal-dev mailing list
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev