[gdal-dev] [gdal-commits] r40282 - trunk/gdal/frmts/aaigrid

[Even Rouault]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171002/d9f1ebfe/attachment-0001.html>