Pixels with NODATA value in a PostGISRaster get reset to 0.0 by gdal_translate

[kempisty]

I have some 32BF raster datasets stored in a PostGIS 2.0 database. Their NODATA values are all set to 9999.0

gdalinfo, using the "PG:" format for the source raster, correctly reports NODATA Value=9999.

gdallocationinfo correctly returns 9999.0 when I probe a location that has a NODATA value.

When I attempt to translate the PostGIS rasters to a raw floating point file (gdal_translate -of Ehdr will do the job), the resulting output has zeroes where the NODATA pixels are supposed to be. It does not matter if I use -a_nodata 9999; I still get 0.0 substituted at all NODATA locations.

This also has the side effect of breaking Mapserver. Instead of drawing transparent pixels, NODATA areas are now colored as if they contain a perfectly valid data point with a value of 0.0.

FWIW, I did not experience this problem in in GDAL 1.9. Could this actually be a bug somewhere in VRTRasterBand?

[kempisty]

Doing some more diagnostics... If anything, it looks like PostGISRaster in 1.10 has a more correct handling of NODATA values, which is exposing a problem somewhere else.

In the 1.9 tree, gdalinfo does not recognize the PostGISRaster NODATA value at all. Therefore, gdal_translate thinks 9999 is a normal pixel, and always copies it over. The resulting .hdr file has a wrong NODATA setting. But, in Mapserver, I have to manually set NODATA=9999 anyway. Mapserver ends up giving the result I want.

In 1.10, when gdal_translate is translating a PostGISRaster, it looks like it is initializing the new raster to "0" instead of the existing NODATA value. Then, when it does the converting, it recognizes the PostGIS NODATA pixels and skips them... leaving zeroes in place.

I'm going to go digging in the source code to see if I can verify this.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.