Point To Raster - misaligned cells in output

[CassKalinski]

When I generate a raster with Point To Raster, I am seeing odd shifts in the raster cell locations. I overlayed the original points with the raster. Across the northern and southern regions of the extent, the original points are centered north/south in the raster cells. They become less and less centered as one moves toward the middle of the extent relative to north/south. East/west there is no variation across the extent. They are centered east/west across the extent. There is a one cell wide band across the middle of the raster that has no cells with NoData values. It looks like the cells "drift" out of alignment as you approach the middle band of the extent.

What is also odd that I get the behavior when I start and end my processing (steps below) with a 1km resolution DEM but do not get the behavior with a 30m DEM. Images in the attached PDF for reference. Am I doing something off here? Any idea what is off in my data or work flow?

I have looked at the thread here: point to raster point is not in the center of the created cell

Not sure how to apply the other advice given there as I am seeing a different shift across the extent of this problem raster. This is a regular grid of points, so it seems confusing that the raster cells shift.

Work sequence:

1) Clip DEMs to study area. Roughly 100km east/west by 200km north/south. 

2) Use Raster To Point to create a regular grid of points from the raster. Examining these points show them centered on the cells.

3) Use Add XY Coordinates on point feature. (Need lat/long for climate model processing.)

4) Use Table To Table to generate a CSV file.

5) CSV file is used as input into the ClimateWNA program.

6) ClimateWNA outputs a CSV file with ~23 climate attributes for each point supplied. Output includes the original lat/long/elev. The program does not change these three values.

7) Use XY Table To Point to create a feature layer. Examining these points, they are centered on the cells in the original clipped DEM.

😎 Use Point To Raster to create a raster for each of the needed climate attributes. One raster per attribute. The environment parameters for GCS, snap raster, cell size, and extent were all set to match the original DEM in step 1.

Step 8 is where the odd behavior described shows up. The work sequence using the 30m DEM has no issues with the offset. I have scanned across the same regions in the extent. Everything aligns: extent, cell size, points centered in cell. Even all the features and rasters with the 1km DEM align until the P2R step.

All GIS processing is with ArcGIS Pro 2.2.4 on a HP Windows 10 Pro desktop. ClimateWNA is a desktop program that is the source for the climate data attributes.

All features and rasters verified as being NAD83 GCS. ClimateWNA outputs in WGS84, but points projected to NAD83 show no delta in location. Raster issues appears whether the points are NAD83 or WGS84.

The north/south dynamics make me suspect some kind of projection issue. I tried combinations leaving various environment settings at default (other than cell size) but get the same odd behavior. ClimateWNA output was also suspect, but the points generated from that data align fine with the original DEM.

I am massaging data for eventual export into a MaxEnt environmental niche model. The two DEMs are a USGS 3DEP 1arc-sec (~30m)  acquired from the USGS site and PRISM's 30arc-sec (aka 800m aka 1km) DEM downloaded from their site. The PRISM data source is a USGS NED 3arc-sec DEM interpolated to resolution per their literature.

I need all the rasters generated at each resolution to align exactly in extent and cell size for the MaxEnt processing. They eventually get output as ASCII files and moved into an R workflow. I have done this workflow before with other USGS DEM datasets and had no issues. First time using the PRISM DEM however.

[SteveLynch]

I think that initially the points were equidistant and then got projected and now the spacing varies.

[CassKalinski]

Hi Steve,

Strove to make sure I used the same projection throughout the workflow as it is crucial all the pieces align for the target modeling. (See top of thread for the sequence and tools used.) I referenced the original DEM in the environment settings at every step for consistency. Do the tools listed reproject while processing? 

[DanPatterson_Retired]

I think Steve is on to something if there is a projection involved in the process

[SteveLynch]

say for instance that you start off with points, in geographic coordinates, and they are say 0.25 degrees apart. If you project these points to a projected coordinate system the points are not equidistant anymore.

And this means that PointToRaster will have some empty cells because there is a good chance that some of the points may rather fall into a single cell rather than 1 per cell.

[CassKalinski]

Understood on the projection. That is why I tried to stay with the GCS throughout the workflow. I thought about moving everything to a PCS (Albers) but opted not to as the external tool used to get the climate data (ClimateWNA desktop) expects WGS84. I know some of the tools in Arc Desktop do projections during their processing. Is that what is happening with the Point To Raster/RasterToPoint/XY tools I am using? 

Trying to make sure my processing of the data is correct here, so please do not think I am challenging the tools or commentary. Just trying to understand the dynamics. 

[SteveLynch]

Projection is only done if you specify a different spatial reference via the output coordinates in the environment.

[CassKalinski · Accepted solution]

Got some great guidance and advice from ESRI via email. Updated work flow below avoids the issues with the banding and cell offsets. Changes from original work flow noted in brackets. 

1) Clipped DEM to study area.

2) Raster To Multipoint to generate point feature class of clipped DEM [Instead of the Raster To Point tool]

3) Multipart To Singlepart on point feature class [new step]

4) Add Geometry tool [instead of Add XY Coordinates] to add longitude and latitude attributes to the point features

5) Table To Table to create CSV file

6) Import CSV file into ClimateWNA

7) cWNA generates an updated CSV file with lat, long, elev from original file associated with climate attributes for every point

😎 XY Table To Points to convert CSV output file to a feature class. 

9) Point To Raster to create a raster for each needed climate variable. Used the clipped DEM as set point for extent, snap raster, and cell size in the Environment parameters for the tool. 

10) Success! Points overlayed onto new climate raster align with the cell centers. Raster contains climate attribute. 

Possible points of failure in the original work flow:

* The original polygon used to clip the DEM was found to be projected to Albers PCS. Should not have caused the problems seen subsequently as the clipped DEM, not the polygon, was used for all subsequent processing. Still, it could have introduced something. However, it seems very strange that if it did, why did it not manifest in one of the early steps in the processing instead of the last step? The early points still aligned with the clipped raster as did the latter point features. 

* Raster To Point. Used the two tools listed in 2 & 3 to bypass this tool. 

* Add XY Coordinates. Used Add Geometry instead. 

* When I ran the XY Table to Points (step 😎 I got a warning message about there being no vertical coordinate system for the Z value. Do not recall seeing this in the prior work flow. Either I missed seeing the warning in the prior runs or a default was applied that I did not catch, resulting in no error message. I suspect the latter. 

I would have to do trail-and-error on each of these to narrow it down to the specific cause. Will have to wait until after the holiday at least. Time to kick off the model run then off to bed.

Thank you all for the help and insights. Took a group effort to sort out a solution.