Rasters not having the same total area for classes within the same study area

Question

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.

Answer 1

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

Answer 2

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.