ASCII to Raster causing projection and scale issues

Question

I'm trying to convert PRISM ASCII files into an Imagine (.img) Raster file format in ArcMap 10.3.1, and for some reason, the resulting raster is not projecting correctly (i.e. it's about 3,755 km south of where all my other vector and raster files are, even though the original ASCII raster will on-the-fly project to the correct location). In addition, the scale is off; the resulting ASCII file is at a large spatial scale (1:250) versus my other raster and vector layers are at a small spatial scale (1:2,000,000) for the same extent.

I'm currently using ASCII to Raster (Data Management) to perform this conversion, and I've tried the following to ameliorate the problem:

1. Environments > Output Coordinates: I've changed the output coordinate system to a PCS (UTM NAD83 13N, which is the projection my other Rasters have and my data frame).

2. Environments > Processing Extent: I've changed the extent to match a DEM that I have, along with making my DEM the Snap Raster.

3. Environments > Raster Analysis: I also tried making my DEM the Mask Raster (along with changing the cell size to 30 x 30).

I've done a combination of the above three steps, along with doing all three at the same time. Nothing has worked. Is there a step that I'm missing that is causing the projection/scale issues?

EDIT: The original ASCII file's spatial reference is NAD83, and the datum is D_North_American_1983

EDIT 2: As requested, the first lines of one of my ASCII files are the following:

ncols        1405
nrows        621
xllcorner    -125.020833333333
yllcorner    24.062499999795
cellsize     0.041666666667
NODATA_value  -9999
 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999.00 -9999

I did verify that, in my ASCII file, there are cells with values (I got a wee bit intimidated seeing the first few hundred lines with no data values, so I had to check).

Answer 1

Expanding on my previous comment...

ASCII files are a valid (supported) raster format by ArcGIS and QGIS, GDAL etc. you should be able to consume the raster directly or import using a tool like Copy Raster or in arcpy (python window):

Inp = arcpy.Raster(r'c:\your\path\to\Raster.asc')
Inp.save(r'c:\export\path\File.tif')

The Raster.save() method works out from the extension what driver to use so any ArcGIS writable raster format that supports the pixel depth is fine.

Before you do anything with the file check that it's actually an Esri ASCII and not some other ASCII file format, open one of your files in your favorite text editor and view the top few lines; an Esri ASCII file has the header:

NCOLS xxx
NROWS xxx
XLLCORNER xxx
YLLCORNER xxx
CELLSIZE xxx
NODATA_VALUE xxx
row 1

I have also encountered XYZ data being called ASCII (well, they are ASCII too, that term just means 'text').. even GDAL is fussy about XYZ, the records must be gridded (regular); LiDAR XYZ (irregular) cannot be converted directly by GDAL or ArcGIS.

Which makes you wonder why there even is a 'ASCII to Raster' tool; it's a throwback to a time when Esri ASCII wasn't supported directly by Esri but rather an interchange format (yes, the 90's) - when Esri GRID was the main spatial raster format but GRIDs couldn't be written to tape unless you copied the whole workspace so to send a raster dataset on 8mm Exabyte Mammoth-2 tape for example it needed to be exported to a non-workspace raster that supported georeference and the only viable format that supported 32bit float was ASCII text format.

Since then GeoTIFF (and CD drives) have been invented so IMHO Esri ASCII raster format should be retired with extreme prejudice as a seriously bloated interchange format that has no real benefits over GeoTIFF, except for zipping very well, and yet I find myself exporting them to meet client requirements still...