I have projected a raster with gdal as part of an R workflow:
gdalwarp -s_srs EPSG:4283 -t_srs EPSG:3577 -r bilinear -multi -tr 1000 1000 -dstnodata -9999 in.tif out.tif
When I add out.tif
to ArcMap, the minimum value indicated beside the colour ramp is incorrect (268.048, while the true minimum is 91.2931), and the colour ramp applied to the data is stretched between this incorrect minimum and the (correct) maximum.
I can calculate statistics (data management > raster > raster properties toolbox) to remedy this, but I'm concerned that if I fail to do this for one of the many rasters I'm working with, I (or my colleagues) might misinterpret a map.
The trick of switching to Classified symbology and back to Stretched returns the error: This dataset does not have a valid histogram required for classification method...
. Attempting the same with Unique Values returns the error: The number of unique values exceeds the default limitation (>65536)...
.
Why has ArcMap chosen this seemingly arbitrary minimum of 268.048? Is there anything I can do to prevent it from happening (e.g. to have ArcMap either calculate the correct minimum when the raster is added, or to use default statistics that span the possible range of values given the pixel type and depth)?
NB: I am using a fresh installation of ArcGIS 10.2, and "Calculate statistics" is checked in Geoprocessing > Environments > Raster Storage.
gdalwarp
from R withsystem
, so the result is identical to if I rungdalwarp
from the command line. No aux.xml file is created. Using-of HFA
(ERDAS Imagine) produces aux.xml but ArcMap reads the same incorrect minimum. Same story with-of EHdr
(.bil). Your offer of code is enticing - is it Python, or R-based?gdalinfo -stats
generates the required statistics and the aux.xml file. Once I do this, ArcMap displays the file as expected. A very easy fix - thank you for (maybe inadvertently!) pointing me in this direction. :)