Bug report #806
Odd NODATA selection for rasters
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Low | ||
| Assignee: |  ersts - | ||
| Category: | Rasters | ||
| Affected QGIS version: | Regression?: | No | |
| Operating System: | Linux | Easy fix?: | No |
| Pull Request or Patch supplied: | Resolution: | fixed | |
| Crashes QGIS or corrupts data: | Copied to github as #: | 10865 |
Description
I have build from the raster_transparency_branch as of last week.
I loaded a raster which gdalinfo does not report as having a nodata value.
But the raster layer seems to have defaulted to treating pixel value "0" as nodata, and made it transparent. Is this intentional? Shouldn't the decision to have an initial nodata value depend on what GDAL reports (with the option for the user to override)?
Let me know if more detail is needed.
History
#1
Updated by ersts - almost 17 years ago
- Status changed from Open to In Progress
I believe this was due to not verifying if the NoDataValue being returned by GDAL was valid. There is a check in place now that will set the NoDataValue to -9999 if GDAL reports that there is no NoDataValue. The user can always change the NoDataValue to what every they like on the 'Transparency Tab' (raster_transparency_branch specific)
This has been addressed in . I will leave the ticket open until it is verified that it is an acceptable solution, then the same can be applied to the trunk.
#2
Updated by Frank Warmerdam - almost 17 years ago
- Resolution set to fixed
- Status changed from In Progress to Closed
fix confirmed, thanks!