Converting .tif to .asc for MaxEnt

Question

I want to convert some .tifs to .asc to use in MaxEnt.

I have tried using both ArcGIS 10.5.1 (the "Raster to ASCII" tool) and QGIS 2.14.3 (Raster > Translate tool). Both give .asc files, but when I try to run MaxEnt I get this;

Error reading "File": java.lang.NumberFormatException: For input string "nan"

This happens even when I only include a single layer in MaxEnt, so I know it is not an issue about all layers having matching extents. I've seen another question with a similar issue, which suggested the files were still GeoTiffs, but I've checked them and they are definitely .asc

Is there an obvious thing I'm missing?

---

Edit

Here is the first few lines of the file, when opened in a text editor

---

Further edit

Link to the original multiband .tif is here. The single band .asc with Nan is here, and the band with the Nan corrected to -9999 is here

Answer 1

The data in your original TIFF is stored as "Float64 - Sixty four bit floating point". This is a standard binary format for decimal numbers. The standard includes special binary numbers for encoding infinity, minus-infinity, and a special set of codes for "Not a Number". For example, if you divide 0 by 0 you get "Not a number" - here's R doing that:

> 0/0
[1] NaN

There's not one single binary pattern that represents "Not a number", there can be many.

Now note that "Not a number" is different to "No data". In raster imagery there's often a need to flag "No data" areas where the image hasn't been taken. The conventional way to do this is to use a "special" numeric value, often way out of the range of the real data, and use that. So you'll see areas with the value -9999 in rasters of temperature.

The GeoTIFF format supports this way of flagging "No data" areas with a special numeric value. and you'll see that in QGIS' properties. When you save such a raster to an ASC format, its in the header:

NCOLS 204 
NROWS 228 
XLLCORNER 96.546435161 
YLLCORNER 16.511034922 
CELLSIZE 0.00449157642156861 
NODATA_value -3.4e+38 

But what you have in your TIFF is "Not a number". Perhaps someone divided a raster with zeroes by another raster with zeroes, resulting in a large area of "Not a numbers". TIFF is fine with that, it happily stores the pixels as "Not a number" codes.

But what to do when you save as an ASCII file? QGIS, via the gdal utilities, does this:

ncols        204
nrows        228
xllcorner    96.546435160746
yllcorner    16.511034922117
cellsize     0.004491576421
 nan nan nan nan nan nan [etc] 791.8 [etc etc]

faithfully spitting out the "not a number" string. But there's no real standard for what the string representation of "not a number" codes looks like (R uses "NaN", for example) so this is now going to have problems. It looks like ArcGIS is using a similar but different code for printing "not a number".

Things you should do: find out how the "not a number" codes got in there - read any metadata and ask anyone who is responsible for the file; check if the "not a number" codes are meaningful - perhaps they are regions where someone has done a divide 0 by 0; check if the "not a number" codes are just a proxy for "No Data" pixels, in which case replace them with true "No Data" values, such as -9999, and set that as the "No Data" pixel value in the raster properties.

Answer 2

You could try the gdal_translate commandline tool:

gdal_translate yournewraster.tif -of AAIGrid existingascraster.asc