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

[Even Rouault]

Le vendredi 01 juillet 2016 20:43:24, Jed Frechette a écrit :
> 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?

Jed,

Yes GDAL 2.1 can produce floating point numbers, which can help to get sub-
pixel precision in some use cases. If read by GDAL < 2.1, those VRT files will 
exhibit possible one-off shift, since those older versions only read values as 
integers. Is it your case ?
Perhaps GDAL could be improved to avoid those issues by rounding to closest 
integer when numbers are very close like in your use case. Could you share a 
way to reproduce the issue ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com