QGIS » QGIS Application

Setting "No data value" has effect on rendering - pixels are rendered transparent.

It does not have effect on identify tool (and similar) and it cannot be easily fixed. While the no data value is set on layer, QgsRasterLayer::identify() calls QgsRasterDataProvider::identify(), and the provider does not know about the no data value set by user on the raster layer. The reason why raster provider returns textual results (QMap<QString, QString>), which can hardly be modified by layer, is to allow for example WMS provider to represent various strange results, e.g. feature attributes, non just a raster value.

See also #4312 and #4313

Giovanni Manghi wrote:

Just spoke with both Radim and Marco at the developer meeting and they agree that this ticket should be stay open.

Even after all the latest changes in rasters the original issue is still there:

manually choosing a "additional no data value" has the only effect to make that values transparent. Both the identify tools and the raster calculator tools take into account the original pixel value.

This is confusing for users as they expect to be able to turn to NULLs the values defined in "additional no data value", and have those pixels considered as NULLs by all QGIS tools in that particular project.

Also histograms are affected, as the the values defined in "additional no data value" are still computed.

see also #1380

at least the identify seems fixed, histograms and raster calc are still affected.

Giovanni Manghi wrote:

at least the identify seems fixed, histograms and raster calc are still affected.

Statistics and histogram should be fixed for GDAL in 8e7ffd7. AFAIK, the raster calculator has to be changed to read data from QGIS providers (it is using GDAL directly) but it is not planned for 2.0. Marco, can you comment?

If the calculator is the only problem left, I would suggest to close this issue and create a new one for raster calculator.

The new problem is not that additional no data value is ignored but that the original data source no data value (-999.9) is ignored, right?

I would not call it entirely new problem. I feel like these are all related. While true, that original negative fractional NODATA value is not respected, I cannot override it with additional no data value setting either.

If I use identity tool on original data as is, it reports empty areas as having 9999 value (instead of NODATA=-999.9). Histogram tool is also affected. If I set additional value to 9999, identity tool says the value on one of those cells is -999.8999 alike. I suspect there is direct float comparison, (perhaps with different bit width/precision storage, otherwise it got to work if read from GDAL) and mutual exclusion for NODATA setting, so 2 values can't be respected at the same time. I did not look at the code. It is just my guess from observed behavior.

The problem is that the decimal no data value -999.9 cannot be represented with sufficient precision by the raster data type float32. -999.9 converted to float32 results in -999.9000244140625. No data value is stored in the raster as double, i.e. -999.89999999999997726 which cannot be represented by float32. The correct no data value for float32 data type could only be -999.9000244140625.

A solution could be to pass no data doubles given by GDALGetRasterNoDataValue through actual data type to get a representable value.

Until we fix that, you can simply disable (uncheck) original nonrepresentable no data value in transparency tab and everything should work as expected.

Fixed.

The next bug report will be: "Why QGIS gives no data value -999.9000244140625 while GDAL -999.89999999999997726?"