Hi, (sorry to top post, just subscribed to the list)
A few notes w.r.t this thread: - there's no universally "good" nodata value for GDAL. In the GDAL API, it is a double value, but the way it is stored is highly dependant of formats. Might be binary, or text (like in GeoTIFF with the GDAL_NODATA tag : http://www.awaresystems.be/imaging/tiff/tifftags/gdal_nodata.html). In the case of GeoTIFF, here's how it is serialized : void GTiffDataset::WriteNoDataValue( TIFF *hTIFF, double dfNoData ) { char szVal[400]; if (CPLIsNan(dfNoData)) strcpy(szVal, "nan"); else CPLsnprintf(szVal, sizeof(szVal), "%.18g", dfNoData); TIFFSetField( hTIFF, TIFFTAG_GDAL_NODATA, szVal ); } The nan special case was done for cross OS compatibility, since there's no standardized way among OS to serialize NaN. AFAIK, Linux must output "nan", Windows "1#.QNAN" etc... Messy. On the reading side, same thing, "nan" is then converted to the "most common" binary representation of a quiet NaN. GDAL code that compare pixel values to nodata has a special case for nodata. - the nodata value assigned to a GDAL band should theoretically be compatible with the range of values compatible with the raster band datatype (e.g. in [0,255] for byte), but this is not checked universally in the code (gdal_translate -a_nodata checks it for example, drivers not as you can see in the GeoTIFF case for example). - for non-NaN floating point values, GDAL should normally compare the pixel value with the nodata value with an epsilon test (due to potential serialization as text). - I've had a look at https://trac.osgeo.org/grass/changeset/65602 and my understanding is that now a pixel value at NaN will be considered as null, even if null_val is not NaN (but this is perhaps intended, if so, ignore this). - This is just for the sake of my curiosity: do you know how -nan pixel values can be generated by GRASS in practice ? (This was what triggered all this: the GDAL reporter was surprised to see pixels at -nan and nodata at nan, and thought that something was wrong) Anyway, too much time spent discussing about numbers that are not numbers ;-) Let's move on. Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
