Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QGIS adds NODATA values when saving rasters with "Save as..." #22212

Closed
qgib opened this issue Feb 1, 2016 · 3 comments
Closed

QGIS adds NODATA values when saving rasters with "Save as..." #22212

qgib opened this issue Feb 1, 2016 · 3 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Crash/Data Corruption High Priority Rasters Related to general raster layer handling (not specific data formats)
Milestone

Comments

@qgib
Copy link
Contributor

qgib commented Feb 1, 2016

Author Name: Alexander Bruy (@alexbruy)
Original Redmine Issue: 14210
Affected QGIS version: master
Redmine category:rasters


To reproduce:

  1. start QGIS and load landcover.img from "Alaska dataset":http://qgis.org/downloads/data/qgis_sample_data.zip
  2. open Layer properties dialog and go to the Transparency tab. Ensure that NODATA values are not set. Close Layer properties
  3. save raster as GeoTiff using "Save as.." from context menu using "Raw" output mode and default settings
  4. load saved raster. Open layer properties and go to the Transparency tab. Now 0 (zero) is NODATA value

Converting same raster in GeoTiff with gdal_translate does not alter NODATA values. QGIS also should not alter NODATA values if user doesn't ask for this, as such silent change lead to the unexpected results.

Maybe related to #19352.

@qgib
Copy link
Contributor Author

qgib commented Feb 3, 2016

Author Name: Radim Blazek (@blazek)


There seems to be more problems.

I tried first with bfad753 (Jan 23 2016) and the raster was written with NoData Value=255 (gdalinfo). It is maybe unnecessary to set nodata value but it should not harm, the value is set to high value and it is checked (IIRC) if raster data do not have that value (in which case wider data type is used). Nodata values handling is quite complex and it should be modified carefully (nodata values are for example required if the raster is reprojected).

Then I tried with fresh b6c714a and the raster is written with NoData Value=nan which is obviously wrong for Type=Byte.

Another problem is, that nodata=nan is displayed in transparency tab as 0, but that is again caused by nan for Byte (there is no integer nan, thus it is converted to 0). If the raster is converted to Float64, the nan value is shown correctly in transparency tab.

I don't think it is directly related to #19352 until it was broken trying to fix that issue.

BTW, the dialog is broken (crs, size, resolution), see my comment in #22211


  • assigned_to_id removed Radim Blazek

@qgib
Copy link
Contributor Author

qgib commented Feb 8, 2016

Author Name: Sandro Santilli (@strk)


  • tag was changed from to raster

@qgib
Copy link
Contributor Author

qgib commented Mar 7, 2017

Author Name: Giovanni Manghi (@gioman)


works fine on 2.18.4 and master.


  • resolution was changed from to fixed/implemented
  • status_id was changed from Open to Closed

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! High Priority Rasters Related to general raster layer handling (not specific data formats) Crash/Data Corruption labels May 25, 2019
@qgib qgib added this to the Version 2.14 milestone May 25, 2019
@qgib qgib closed this as completed May 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Crash/Data Corruption High Priority Rasters Related to general raster layer handling (not specific data formats)
Projects
None yet
Development

No branches or pull requests

1 participant