[gdal-dev] vrt warping precision issues and tile offsets
David Shean
dshean at gmail.com
Wed Dec 5 00:18:17 PST 2018
Hi list,
I am seeing some sub-pixel inter-tile offsets in the output of warped vrt products. I am a big fan of vrt and use regularly, but this is the first time that I’ve noticed this issue. I am hoping that there is a simple workaround.
I’ve isolated a simple test case from a larger project. I’m running GDAL 2.2.4.
Test case includes:
-A single “source” DEM with UTM 43N projection (EPSG:32643), 30 m grid
-A set of 4 adjacent “reference” DEM tiles in a regional Albers equal-area projection ('+proj=aea +lat_1=25 +lat_2=47 +lat_0=36 +lon_0=85 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs ‘), also 30 m grid
I need to compute elevation difference between the source and reference. The source DEM extent spans tile boundaries of the reference DEM.
I build a vrt <https://drive.google.com/file/d/1AsXk5KFF-tQNaFfWZsAQLz0wQW_lsoOA/view?usp=sharing> of the reference tiles:
gdalbuildvrt -r cubic ref.vrt tile1.tif tile2.tif tile3.tif tile4.tif
For comparison, I create a mosaic of the reference tiles using gdalwarp:
gdal_opt='-co COMPRESS=LZW -co TILED=YES -co BIGTIFF=IF_SAFER'
gdalwarp $gdal_opt -r cubic -et 0 tile1.tif tile2.tif tile3.tif tile4.tif ref.tif
I then resample both ref.vrt and ref.tif to match the resolution/extent/srs of the original source DEM and compute an elevation difference. In practice, this is done on-the-fly using https://github.com/dshean/demcoreg/blob/master/demcoreg/compute_diff.py <https://github.com/dshean/demcoreg/blob/master/demcoreg/compute_diff.py>. For the purposes of illustration, and to ensure that these external tools are not the issue, I use gdalwarp for this resampling step:
src_extent='261016.895 3813317.750 335896.895 3885107.750'
gdalwarp $gdal_opt -r cubic -et 0 -tr 30 30 -t_srs EPSG:32643 -te $src_extent ref.tif reftif_warp.tif
gdalwarp $gdal_opt -r cubic -et 0 -tr 30 30 -t_srs EPSG:32643 -te $src_extent ref.vrt refvrt_warp.tif
The (reftif_warp.tif minus source) DEM difference map <https://drive.google.com/file/d/1VoB06LMArRmPKYxVyNkk5AHWhbNf69Kn/view?usp=sharing> looks as expected, and is consistent with the output that I obtain computing difference maps between the source DEM and each individual reference tile.
The (refvrt_warp.tif minus source) DEM difference map <https://drive.google.com/file/d/1PZmSTng8yQdC-1D0EBAVFdsTjMiQWL7C/view?usp=sharing> shows evidence of subtle horizontal shifts in the reference tiles, which introduces spatially variable vertical error in the resulting elevation differences. I ran an image correlator on the outputs, and indeed, I see sub-pixel shifts <https://drive.google.com/file/d/1vzoUfiF9fPKO-AmzmIYOFwVNl8Y8Kom1/view?usp=sharing> between the original tiles with variable direction/magnitude (up to ~0.3 px). The original tile boundaries are easy to identify.
After various tests, I’ve concluded that warping the vrt is the problem. Is this a known issue? Is there something equivalent to -et 0 for gdalbuildvrt? The vrt DstRect offsets are suspicious and the output vrt dimensions don’t match the sum of input tile dimensions. Using -tap during gdalbuildvrt doesn’t help. Maybe an issue related to my aea projection?
Also, does the -r cubic option for gdalbuildvrt matter if I specify a different resampling algorithm during a later warp operation?
Sample data are here: https://drive.google.com/drive/folders/15hNlUoUkCeYbgZCyfMzymmCP1__4wVgO?usp=sharing <https://drive.google.com/drive/folders/15hNlUoUkCeYbgZCyfMzymmCP1__4wVgO?usp=sharing>
Thanks for any suggestions.
-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20181205/928c4dc7/attachment-0001.html>
More information about the gdal-dev
mailing list