On 2/10/2019 7:11 PM, Nyall Dawson wrote: > Hey all, > > I'm seeking some feedback on whether our current handling of nodata > pixels in the raster calculator is correct, or (my suspicion) annoying > and limiting. > > Currently, we treat nodata pixels the same as a "NULL" value in SQL -- > so ANY function or operation with nodata as an input results in a > nodata output. > > This means: > > - nodata + 1 = nodata > - nodata * 1 = nodata > - nodata AND 1 = nodata > - nodata OR 1 = nodata
As much as I understand the desire to manipulate nodata pixels, I'm not sure what I would expect for the first two cases you list. I would hope the result would be the same regardless of the internal representation of nodata, so that rules out just adding 1 to the value. My natural inclination I would be to expect the AND case to return nodata, esp if the OR case is supposed to return 1, but others may have different expectations/intuition. I would encourage the use of explicit conditionals to deal with nodata cases and extend the raster calculator to accept "nodata" as a literal in conditionals so that the user doesn't have to know what the nodata value actually is. For example if you want nodata + 1 to be 1 in your first example above (raster@1 == 'nodata') * 1 + (raster@1 != 'nodata') * (raster@1 + 1) For what I would expect to be the rare case where you want to manipulate the actual value of nodata, I suppose we'll need either a function that returns the nodata value - eval(nodata) or another literal, eg, nodata_value. I find that idea of operating on the nodata value itself to be rather dangerous as your result changes with a change in the representation of nodata, which seems semantically meaningless. David Strip _______________________________________________ Qgis-user mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
