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.
Nan
values in there. – EcologyTom Sep 30 '18 at 9:121.#QNAN
to-9999
then it should read in.... How they got in there I do not know... If we could get the original TIF I could investigate... – Spacedman Sep 30 '18 at 16:10-9999
in the text editor, and I can now use them in MaxEnt. It would still be good to know how they were introduced in the first place... – EcologyTom Oct 1 '18 at 8:53