gdal_translate incorrectly transfers very small int32 nodata pixel values during vrt mosaic

[pauldzy]

Hello,

I am pretty sure this a followup to ​https://trac.osgeo.org/gdal/ticket/6151.

Using GDAL 2.1.0:

gdalbuildvrt is working as expected but I assume there is another alteration needed in the mosaic section of gdal_translate.

Attached is a working example of issue:

1) Given two rasters in same coordinate space each with nodata value of -2147483647: fac_22M.tiff and fac_22G.tiff. Rasters obtained from US EPA NHDPlus project at ​https://www.epa.gov/waterdata/nhdplus-national-hydrography-dataset-plus

2) Execute gdallocationinfo -xml -b 1 -wgs84 fac_22M.tif 145.7 15.28 to examine upper corner to verify value

<Report pixel="122" line="105">
  <BandReport band="1">
    <Value>-2147483647</Value>
  </BandReport>
</Report>

3) Execute gdalbuild foo.vrt fac_22M.tif fac_22G.tif and check resulting vrt, everything looks good per 6151. See attached foo.vrt.

4) Execute gdal_translate -of GTiff foo.vrt foo.tif

5) Execute gdalinfo foo.tif and verify nodata remains -2147483647.

6) Execute gdallocationinfo -xml -b 1 -wgs84 foo.tif 144.6 15.28 to check pixel in the padded area of the mosaic - all is good.

<Report pixel="13" line="4">
  <BandReport band="1">
    <Value>-2147483647</Value>
  </BandReport>
</Report>

7) But then execute gdallocationinfo -xml -b 1 -wgs84 foo.tif 145.7 15.28 to check the pixel value of nodata area of original raster.

<Report pixel="11829" line="105">
  <BandReport band="1">
    <Value>-2147483648</Value>
  </BandReport>
</Report>

For unknown reasons the original nodata values have shifted to -2147483648.

If I can clarify this any further just ask.

Thanks,

Paul

[pauldzy]

Hmm, attachment limit of 1 meg... I will put the files on my own domain for pickup when I get home tonight.

[pauldzy]

Okay, here are the example files:

Inputs (all open data from NHDPlus):

• ​http://www.dziemiela.com/water/fac_22M.tif
• ​http://www.dziemiela.com/water/fac_22G.tif

Outputs:

• ​http://www.dziemiela.com/water/foo.vrt.txt
• ​http://www.dziemiela.com/water/foo.tif

[Even Rouault]

In 35349:

VRTComplexSource: do temp computations on double to avoid precision issues when band data type is Int32/CInt32/Float64/CFloat64 (fixes #6642)

[Even Rouault]

In 35350:

VRTComplexSource: do temp computations on double to avoid precision issues when band data type is Int32/CInt32/Float64/CFloat64 (fixes #6642)

[Even Rouault]

In 35368:

VRTComplexSource: do temp computations on double to avoid precision issues when band data type is UInt32 (fixes #6642)

[Even Rouault]

In 35369:

VRTComplexSource: do temp computations on double to avoid precision issues when band data type is UInt32 (fixes #6642)