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 _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
