Opened 5 years ago

Last modified 5 years ago

#5077 new defect

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

Reported by: kempisty Owned by: warmerdam
Priority: normal Milestone:
Component: default Version: 1.10.0
Severity: normal Keywords: PostGISRaster gdal_translate NODATA
Cc:

Description

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?

Change History (1)

comment:1 Changed 5 years ago by kempisty

Keywords: gdal_translate NODATA added

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.

Note: See TracTickets for help on using tickets.