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?


Here is the first few lines of the file, when opened in a text editor enter image description here

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

  • What do the first few lines of your asc files look like? They should start with lines like "NCOLS 654" and "NROWS 555" and a "NODATA_value -9999" or similar. Followed by the values as numbers. If the string "nan" occurs anywhere then something isn't right. Open in a text editor and check.
    – Spacedman
    Sep 28 '18 at 15:45
  • Thanks @Spacedman, I've added a screenshot of the first few rows. Looks like there is a problem with Nan values in there.
    – EcologyTom
    Sep 30 '18 at 9:12
  • Yikes. If you can do a string-search-and-replace in your text editor and change all those 1.#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
  • Thanks for the suggestion @Spacedman. I changed them to -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

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.

  • Thanks for the really detailed answer. The original files came from a Google Earth Engine download, and the no data value has not been defined. I will try to sort those. Your help is much appreciated!
    – EcologyTom
    Oct 1 '18 at 13:04

You could try the gdal_translate commandline tool:

gdal_translate yournewraster.tif -of AAIGrid existingascraster.asc
  • Thanks for your answer. Please can you give me a bit more direction as to how I should use this? Where is the gdal_translate tool?
    – EcologyTom
    Sep 30 '18 at 9:14
  • I'm guessing you are using windows? gdal_translate commandline app comes with the gdal/ogr suite of tools. trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries will provide some links to download...you can either compile if you are into that or there are binaries(pre-built). Sep 30 '18 at 19:55
  • Thanks, I found the gdal_translate tool in the processing toolbox. (I mainly use QGIS on Mac). I can convert the file, but have the same issue as above, the only difference being the 1#QNAN entries are now nan. @Spacedman's suggestion is a reasonable workaround, but I'm still keen to find out why this is happening.
    – EcologyTom
    Oct 1 '18 at 9:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.