Opened 7 months ago

Closed 7 months ago

Last modified 7 months ago

#6642 closed defect (fixed)

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

Reported by: pauldzy Owned by: warmerdam
Priority: normal Milestone: 2.1.2
Component: GDAL_Raster Version: 2.1.0
Severity: normal Keywords: gdal_translate nodata
Cc:

Description

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

Change History (7)

comment:1 Changed 7 months ago by pauldzy

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

comment:3 Changed 7 months ago by Even Rouault

Resolution: fixed
Status: newclosed

In 35349:

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

comment:4 Changed 7 months ago by 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)

comment:5 Changed 7 months ago by Even Rouault

Milestone: 2.1.2

comment:6 Changed 7 months ago by Even Rouault

In 35368:

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

comment:7 Changed 7 months ago by Even Rouault

In 35369:

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

Note: See TracTickets for help on using tickets.