Opened 11 years ago
Closed 5 years 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 |
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 (2)
comment:1 by , 11 years ago
Keywords: | gdal_translate NODATA added |
---|
comment:2 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
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.
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.