Markus Metz wrote: > >>> 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. > >>> > >> That's reasonable for integer maps, but for FP maps it makes more > >> sense to simply default to NaN as the no-data value (the two are > >> essentially the same concept, so there is no information loss in using > >> NaN). > >> > > > > Do other software packages understand 'Nan' ? > > Do other file formats understand Nan? Reading a bit in GDAL API > documentation lets me suspect that NaN is not allowed, because for > GeoTIFF, you can specify a NoData value as in the current implementation > or you can add an internal mask, no mentioning of writing NaN for > Float32 or Float64 to a GDAL raster band. Did I overlook something?
Any code which deals with floating-point values would have to go out of its way to avoid NaNs, i.e. actively check for them and flag an error. Likewise for infinities. If code just passes floating-point values around without explicitly classifying them, most of the time it will get the correct behaviour without even trying. I suspect that the most likely reason for code to handle NaN incorrectly would be equality checks, i.e. "if (x == null_val)" won't work if null_val is NaN (it will always be false, even if x is NaN). OTOH, floating-point equality checks have plenty of other problems (e.g. x86 using 64 bits for a double stored in memory but 80 bits for a register, meaning that "x = y; if (x == y) ..." won't necessarily work for non-NaN values either). -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
