On lundi 2 octobre 2017 08:04:30 CEST Kurt Schwehr wrote: > +gdal-dev > > Even, > > Looking back at the changes to aaigrid, I think I've messed things up with > nodata. Before I submit anything else, what do you think? > > The trouble is that it is no longer doing a cast to float for in range > values. That means for large values, it's not getting rounded to the > nearest float value any more. I'm seeing this in one on my local tests. I > dump the json out of gdalinfo and compare. For float64.asc.json: > > I was getting: -1.234567880630493164 > Now seeing: -1.234567890123 > > The new value matches the text in the file, but it was a behavior change. > Leave it be or put in an else that does the rounding to nearest float value > by casting? > > What do you think?
That's actually a general issue with GetNoDataValue() returning a double. For a Float32 band, the return only makes sense after being cast to float. In the past, we have had issues in GDAL core regarding that in statistics, min-max or histogram computation functions, but I think that now we compare pixel values to the float- casted nodata value. So whether you pre-cast to float in the driver shouldn't make a difference. You can try putting nodata values as pixel values in the .asc file, and check whether gdalinfo -stats / -mm / -hist ignore them. That said, it wouldn't probably be a bad idea to keep the behaviour we had before your changes (ie double->float->double cast), so as to avoid breaking external code/tests that would depend (erroneously) on the exact value. Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
