[gdal-dev] gdalbuildvrt 2.1.0 and off by 1 pixel display

[Jed Frechette]

Starting with version 2.1.0 I've started to see display errors in both
QGIS and ArcGIS for datasets built with gdalbuildvrt. In both cases, the
vrt data ends up offset by 1 pixel relative to the source files. This
offset is not consistent between applications or within the data set. My
guess is that what I'm seeing are rounding errors as a result of
Changeset 30648 [1] writing source and destination offsets and sizes as
floats rather than integers.

Here is a snippet of a VRT generated by 2.0.0::

<ComplexSource>
   <SourceFilename relativeToVRT="1">slpc/test01.tif</SourceFilename>
   <SourceBand>1</SourceBand>
   <SourceProperties RasterXSize="952" RasterYSize="1189" DataType="Byte"
BlockXSize="952" BlockYSize="8" />
   <SrcRect xOff="0" yOff="0" xSize="952" ySize="1189" />
   <DstRect xOff="0" yOff="0" xSize="952" ySize="1189" />
   <NODATA>0</NODATA>
</ComplexSource>

And the equivalent snippet generated by 2.1.0::

<ComplexSource>
   <SourceFilename relativeToVRT="1">slpc/test01.tif</SourceFilename>
   <SourceBand>1</SourceBand>
   <SourceProperties RasterXSize="952" RasterYSize="1189" DataType="Byte"
BlockXSize="952" BlockYSize="8" />
   <SrcRect xOff="0" yOff="0" xSize="952" ySize="1189" />
   <DstRect xOff="0" yOff="0" xSize="951.999999999534"
ySize="1189.00000000373" />
   <NODATA>0</NODATA>
</ComplexSource>

Both VRT files were generated in the same way::

gdalbuildvrt -tr 0.05 0.05 -tap slpc.vrt slpc/*tif

Note that the results are the same whether or not I use the -tr and -tap 
flags. Looking at other ComplexSources the DstRect offsets and sizes are 
always the values that are inconsistently rounded to integers with any 
of them potentially containing floats in the xml file. The VRT files 
were created on different systems with significantly different 
configurations so it is entirely possible that there is some local issue 
with my setup that is introducing this problem.

So I guess my first question is: Can anyone else confirm this issue? If 
so should it be considered a bug in GDAL or is up to other applications 
to adapt to this behavior?

Thanks,

[1] https://trac.osgeo.org/gdal/changeset/30648
-- 
Jed Frechette