Cutting rasters to precise extent and cell size

12509
11
Jump to solution
12-06-2016 07:27 AM
RobertPace
New Contributor II

I have four raster layers (DEM, Slope, Aspect, Soils) all in the same GCS (WGS_1984) stored in a geodatabase.

I want to clip all four rasters such that the output will have the same # of rows/columns, X&Y cell size, and extent.  I've had great success in clipping DEM, Slope, and Aspect so that everything matches up.  The issue is with the SOILS raster, which regardless of whether I use Extract By Mask, Clip, or Data Extraction the output raster will differ in number of columns/rows, X&Y cell size, or extent.  When Extracting By Mask, I use DEM, Slope, or Aspect as the mask.

It is imperative that all four rasters match precisely in extent, cell size, and columns/rows in order for me to use the data with MaxEnt.

I've attached screencap of an excel showing the rows/columns, cell size (x & y), and extent for the different data layers.

0 Kudos
1 Solution

Accepted Solutions
RobertPace
New Contributor II

I think I finally made some headway in solving this issue.  I am not sure if all these steps are necessary, but this does seem to work in cutting the raster data layers precisely.  I first ensure everything is in the same geographic coordinate system (WGS_1984).  I then cut the source data (which is a larger extent than needed) to a smaller extent that is still larger extent than needed. If needed I resample all these smaller data layers with the appropriate cell size (that of DEM raster).  I next cut the resampled data layers using "extract by mask" using the DEM raster layer as the mask, and under Environment | Processing Extent | Snap to Raster = DEM raster.  This produces raster output that is precisely the same extent and cell size.

View solution in original post

11 Replies
ChrisDonohue__GISP
MVP Alum

One thing to try would be setting a Snap Raster in the Environment Settings when running a raster geoprocessing tool:

Tools that honor the Snap Raster environment will adjust the extent of output rasters so that they match the cell alignment of the specified snap raster.

A Snap Raster is typically used where inputs to tools:

  • Have different cell alignments
  • Have different cell resolutions
  • Have different coordinate systems
  • Are features

Snap Raster (Environment setting)—Help | ArcGIS for Desktop 

Chris Donohue, GISP

RobertPace
New Contributor II

Thanks for the advice Chris,

I just tried using Extract By Mask and using the Snap Raster under Environment Settings.  I used the DEM raster as the Snap Raster and as the Extraction Mask. The output raster is SOILSTEST5 (see last row in image). The cell Size (Y), and extent (Top & Right) differ from the DEM raster even when using Snap Raster set to the DEM raster.

screencap of excel documenting raster details

The values are pretty close between SOILSTEST5 and DEM raster, but not precise.  If the data was destined for a map or ArcGIS related analysis I would be happy with the data as is.  Unfortunately the destiny of this data is to be converted to ASC format, and then utilized with MaxEnt modeling, which absolutely requires the data of every raster to align precisely.

Any other ideas?

0 Kudos
ChrisDonohue__GISP
MVP Alum

I don't know if he is on right now, but I bet Dan_Patterson might have some ideas.

Chris Donohue, GISP

DanPatterson_Retired
MVP Emeritus

Chris's link ... Snap Raster (Environment setting)—Help | ArcGIS for Desktop 

has a very detailed set of rules

The important think to deal with for processing in the first instance is the bottom left hand corner and the cell size must match... they are independent of the general analysis extent.

In this vein, it would be best to get that established first, then trim any extra rows and columns from the top and left after all rasters align to the lower left and all have the same cell size.  What I think is happening is that the erroneous files are trying to be squeezed/stretched (whatever) into an extent at the same time as the lower left corner and cell size is being aligned.   Try skipping the extent... set the snap raster... check the left bottom alignment and cell size and prune everything to the minimum of the inputs... Be careful with this since you are unfortunately working with geographic coordinates and the 8th decimal place in a GCS is sadly not the same precision as the same representation in projected coordinates... but you must have a need to use a GCS, just a warning for others in general

RobertPace
New Contributor II

Thanks for the insight Dan.

I've noticed that most tools that allow you to specify cell size apply the provided cell size to both X and Y, and the X and Y of most of my raster data differ between X and Y.  Could the fact that there is a difference between Cell X and Cell Y size be causing my symptoms?  

I noticed (as you mentioned) that there is limited precision with GCS vs PCS extents because extent values entered tend to be rounded off and not preserved as set. 

Given the data as I have it now, what would be the best steps to adjust SOILS cell size to match the DEM extent & cell size?  Is it necessary for me to project both DEM and SOILS rasters to a PCS, then cut SOILS with snap to raster, followed by project back to GCS (WGS_1984)?  I am afraid the three GIS classes that I've had didn't focus on raster data management.

0 Kudos
DanPatterson_Retired
MVP Emeritus

A slight complication then.... Cell size and resampling in analysis—ArcGIS Help | ArcGIS for Desktop 

Before you do anything, I would get them squared up.  You are going to have to check what tools support non-square cells to ensure that you use them with caution or attention paid to this fact.  I wouldn't do any projection until they they at least are the same with respect to the bottom left and cell size in the X and Y direction are the same.  You also need to make sure that there are no fundamental changes in the data during this process... such as promotion of data from integer to float or any substantive movement of boundaries between classes.

RobertPace
New Contributor II

I decided to re-cut all my data layers in hopes that some of the issues I was experiencing would vanish.

I started with all my data (DEM, Aspect, Slope, Land Use/Land Cover) in GCS (WGS_1984) at a much larger extent than I will require output at.  I also ensured that the cell size (both X and Y) were square and the same for all the raster layers.  I then cut each raster using the kentucky boundary shapefile (polygon) that also was in GCS  WGS_1984.  Each raster was cut after selecting the Snap Raster option under Environment | Processing Extent.  Eachof the rasters output shared identical extent, rows/columns and cell size which was desirable.

I then converted my USGS/NCRS Soils shape file  (containing ~25,000 polygons) to a raster using the cell size of the other raster files (slope, dem, and aspect).  I then used the Kentucky boundary shape file to cut the previously created Soils raster, using the Snap To Raster under Environment | Processing Extent.  Unfortunately the Soils output raster didn't match the extent from the other rasters. but the cell size was correct.  I tried both having Check in Use input features for clipping geometry and unchecked.  I also tried with having Environment | Processing Extent | Extent set to one of my other good rasters such as Aspect or left to default.

Here is an excel showing the details of each raster.  Ideally I want the SOILS raster to match all the values for either Aspect, DEM, Slope, or LULC.  The green cells are ones that match the desired value, the orange ones are values that are do not match Aspect, DEM, or LULC.

Here are the settings I've been using for my clipping of the rasters:

and

What am I doing wrong?

0 Kudos
DanPatterson_Retired
MVP Emeritus

Bottom is good... left is really close or an artifact of floating point arithmetic or a 1/2 cell shift... I can't tell in geographic coordinates but I think bottom left and cell sizes is good.  You also have one more row. and the right doesn't look right nor how the column is derived.  What I would like to see is the snap raster used... in theory pinning the bottom left with its cell size. let's skip extent for now, let it run, then see if you can 'clip' to the extent of the snap raster.  I can picture it, but I am just not sure the affect of floating point math on the coordinates in geographic... should be negligable but I usually dont trust what I see in summary tables, preferring to extract information using python and/or numpy.  it is the spreadsheet effect... the column width and displayed decimals being controlled by the table and not the user unless they do so directly

RobertPace
New Contributor II

I went back to the larger extent of soils_rectangle2 raster and cut by the extent of the DEM raster to a new raster soils11.

I extracted the extent information from the soils_rectangle2 raster as below:

>>> import arcpy
>>> import os
>>> arcpy.env.workspace = "G:/Robert_Pace/WGS84.gdb"
>>> elevRaster = arcpy.sa.Raster('G:/Robert_Pace/WGS84.gdb/SOILS_RASTER_RECTANGLE2')
>>> myExtent = elevRaster.extent
>>> print myExtent
-90.0005618104551 35.9994523710878 -78.9994506509391 40.0005634998038 NaN NaN NaN NaN
>>>

I extracted the extent information from the soils11 raster using arcpy as below:

>>> import arcpy
>>> import os
>>> arcpy.env.workspace = "G:/Robert_Pace/KY_WGS84.gdb"
>>> elevRaster = arcpy.sa.Raster ('G:/Robert_pace/KY_WGS84.gdb/SOILS11')
>>> myExtent = elevRaster.extent
>>> print myExtent
-89.5716729215644 36.4971375562752 -81.9648210362424 39.1476005309002 NaN NaN NaN NaN
>>>

Here is the DEM raster extent extracted from the raster via arcpy:

>>> import arcpy
>>> import os
>>> arcpy.env.workspace = "G:/Robert_Pace/KY_WGS84.gdb"
>>> elevRaster = arcpy.sa.Raster('G:/Robert_Pace/KY_WGS84.gdb/DEM')
>>> myExtent = elevRaster.extent
>>> print myExtent
-89.5715803289718 36.4971375562752 -81.9649136622716 39.1475079266572 NaN NaN NaN NaN
>>>

Here is a screen cap showng the two polygon shape files (rectangleboundary & kyboundary) which were used to cut the soils_rectangle2 and DEM raster layers from the even larger extent source data.

Does this help?

0 Kudos