I have multiple rasters for various data: LULC, Elevation classes, Slope steepnees classes, Soil types.

All those rasters have the same properties: all have the same number of columns and rows; same resolution (25m); same projection; same extent. I have also check for Null values in the dataset, and I don't have any.

Technically, I clipped all those rasters to the extent of shapefile of a study area.

If I count all the pixels belonging for each class, trying to obtain the area for each class and then the total area, the results are differing.

The correct area is 7103 square kilometers. My results are the following:

Elevation and soil classes: 7103 square kilometers

Slope classes (this was derived from the same DEM as elevation): 7089 square kilometers - this is the biggest error

LULC: 7106 square kilometers

What did I do wrong, or how can I fix this? My guess would be that it could be because of the clipping along the border of the study area, and maybe Null pixels are around the border, but then why Elevation and Soil rasters have the correct values, while the others don't?

EDIT: I think I have found the reason for the difference in area, but I don't know how to fix it. In the attached image, the pixels in red are part of the DEM, which are correct and within the study extent. However, when using the "Slope" tool, the result raster is not covering those pixels. The green pixels are the "Slope" ones and they don't overlap the same extent. Any idea how to fix it? Snap didn't work.

enter image description here

  • @BERA ArcGIS Pro 2.7.0
    – gis1234
    Commented Sep 27, 2023 at 9:54
  • In your list of sameness you didn't include "same origin". If the pixel alignment isn't perfect, this could easily change a few pixels on overlay. What happens if you use one of the rasters as a NODATA mask, then clip?
    – Vince
    Commented Sep 27, 2023 at 10:49
  • @Vince how exactly to do to set the raster as a nodata mask? I have used symbology to show nodata as red color, and I see that a large square extent, outside the study area is set as NoData. But is not within the shapefile limits. Just outside of it. It is technically the same extent as the shapefile, just that outside the borders.
    – gis1234
    Commented Sep 27, 2023 at 11:20
  • You really ought to shift all your rasters to have the same exact origin. "Same extent" only counts as "same" if they are the same; clearly, the red and green pixels have a different origin.
    – Vince
    Commented Sep 27, 2023 at 13:51
  • @Vince can you please tell me how to shift them to have the same exact origin?
    – gis1234
    Commented Sep 27, 2023 at 14:11

2 Answers 2


I also do not believe this is an Origin/Nap issue. I believe that the reason for this is that the SLOPE calculations were performed after the DEM was clipped to the study extent. Because the slope function needs adjacent cells, the result is a gap at the study boundary where no adjacencies are available.

To resolve this (if indeed the SLOPE calc was performed after the DEM clip) you have two options:

  1. Perform the SLOPE calculation on the un-clipped DEM, then clip them both
  2. Buffer the study extent by several raster cells, clip the DEM, then perform the SLOPE calc on the clipped DEM
  • Thank you. It worked. I have used the original DEM, clipped it to an extra buffer, performed the slope on the extra limit raster, then clipped to my study extent. Now it overlays the elevation raster.
    – gis1234
    Commented Sep 28, 2023 at 8:18

I do not believe that this is an origin/snap issue. Although, it is always prudent to set an analysis environment to control for cell size, origin/snap and mask. There are many operators that result in edge pixels being assigned NoData. In ArcGIS Pro, slope/aspect very well may exhibit this behavior. This is because the local window cannot fit the relevant equation, with pixels along the edge having too few observations so, they are simply turned into NoData.

This is why you often seen the advice of defining an extent slightly larger than your study area then masking results back to your explicit study area boundary. Certain software allow for padding edge values to avoid edge effect behavior but, ESRI has never implemented this option in any of their software release(s).

One work around would be to set your mask (that represents the full extent of pixels) and run a focal mean or median to fill in these edge cells. Just make sure that the ignore_nodata argument is set to DATA so that actual values are written and not NoData. If the raster is nominal (categorical) use MAJORITY as the statistics_type.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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