Maciej Sieczka wrote: > Markus Metz pisze: > >> Nodata value handling >> >> If a nodata value was supplied, this value is tested whether it is >> within the range of the selected data type and adjusted if necessary. >> Specifying e.g. a nodata value of -9999 and using Byte as data type >> (range 0 - 255) is no longer accepted, it will be adjusted to 0. >> Similarly, a nodata value of 9999 would be adjusted to 255 for Byte >> type. > > IMHO r.out.gdal should abort with an error rather than silently adjust > user-specified values. Aborting with an error is definitively an option, but then the original behaviour of r.out.gdal should be changed too. The original r.out.gdal chooses a nodata value according to the selected output data type if none was specified, without message or warning. Later on (original nodata value handling), a warning message is issued if there are NULLs in the raster to be exported, irrespective of whether a nodata value was specified by the user or not. With my version, the nodata value is not silently adjusted, a warning message is issued. I wanted to keep the behaviour similar to the original version, and if everything is all right, there is no difference apart from the additional -c flag and a warning if colortable export takes place. r.out.gdal nodata handling could be changed so that the user has to provide a nodata value if there are NULLs in the raster, otherwise r.out.gdal aborts with an error. Further on, r.out.gdal can also abort with an error if the specified nodata value is not covered by the range of the selected data type, instead of adjusting the nodata value and issuing a warning message. IMHO, either a warning or an error message should be issued and the type of message - warning or error - should be consistent for nodata handling in the whole module. If the general policy is not to adjust user-specified values, even with a warning message, but to abort with an error and provide information on what's wrong and how to fix it, then it should be changed to aborting with an error. In any case, this is easy to change.
Markus _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
