Opened 6 years ago

Closed 4 months ago

#5077 closed defect (wontfix)

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

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


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 (2)

comment:1 Changed 6 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.

comment:2 Changed 4 months ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

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 if it is not already reported there.

Note: See TracTickets for help on using tickets.