What is the difference between slope, aspect and hillshade?

Slope is the steepness of the surface, a measured value. Aspect is the compass direction the slope faces. Hillshade is a simulated shaded-relief image computed from a light source and is for visualisation, not measurement.

Should slope be in degrees or percent?

Both are valid but not interchangeable. Degrees range 0-90; percent rise is rise over run times 100 and is unbounded (45 degrees equals 100 percent). State the unit explicitly because a '30' in degrees and '30' in percent are very different slopes.

What algorithm does gdaldem use for slope?

By default gdaldem uses Horn's method, a 3x3 weighted moving window that emphasises the four cardinal neighbours. A Zevenbergen-Thorne option (-alg ZevenbergenThorne) is available and tends to suit smoother surfaces.

Why does my slope look wrong when the DEM is in lat/long?

In a geographic CRS, horizontal units are degrees while elevation is metres, so the rise/run ratio is meaningless. Either reproject to a metric CRS or use gdaldem's -s scale factor (about 111120) to convert degrees to metres approximately.

Slope, Aspect and Hillshade From DEM Data

The short answer

Slope, aspect and hillshade are the three first-order derivatives of a digital elevation model, and although they come from the same source they answer different questions. Slope measures steepness and is a true analytical layer; aspect records the compass direction a slope faces and is directional, not magnitude; hillshade is a synthetic shaded-relief image computed from a simulated sun and exists purely for visualisation. The single most important thing to get right before computing any of them is the geometry of the DEM — its horizontal CRS, cell size and vertical units — because a degrees-versus-metres mismatch silently corrupts every slope value.

How each derivative is computed

All three are calculated from a moving 3x3 window of cells. The algorithm estimates the rate of elevation change in the x and y directions (the partial derivatives dz/dx and dz/dy) from the eight neighbours, then combines them. The default in both gdaldem and Esri tools is Horn's algorithm (1981), which weights the cardinal neighbours more heavily than the diagonals; an alternative is Zevenbergen and Thorne (1987), which fits a partial quartic and is often preferred on smooth surfaces.

Slope

Slope is the magnitude of the gradient: slope = atan(sqrt((dz/dx)^2 + (dz/dy)^2)). It can be reported in degrees (0-90) or as percent rise (tan(slope) x 100, unbounded). The two are not interchangeable: 45 degrees equals 100 percent, and 60 degrees equals about 173 percent. Always label the unit. Slope drives slope-stability thresholds, trafficability, erosion models and habitat analysis, so its units have real consequences.

Aspect

Aspect is atan2(dz/dy, -dz/dx), converted to compass degrees: 0/360 = north, 90 = east, 180 = south, 270 = west. Flat cells have no defined aspect and tools return a sentinel value (commonly -1). Because it is circular, you cannot average aspect arithmetically — the mean of 350 and 10 degrees is 0 (north), not 180 (south). Use circular statistics or convert to northness/eastness (cos/sin of aspect) before any averaging or interpolation.

Hillshade

Hillshade simulates illumination from a light source defined by two angles: azimuth (compass direction of the sun, default 315 = northwest) and altitude (height above the horizon, default 45 degrees). Each cell's brightness depends on the angle between its surface normal and the light vector. The northwest default exists because of a perceptual quirk — humans read relief correctly when light comes from the upper left, and lit from the southeast many people see the terrain inverted ("pseudoscopic" illusion). Hillshade is for the eye; never measure from it.

Why CRS and units come first

Slope is a ratio of vertical change to horizontal distance, so the two distances must be in the same units. Two failure modes are common:

Geographic CRS (lat/long). Horizontal units are degrees and vertical units are metres. The rise/run ratio is nonsense, and slope values come out wildly wrong. Fix by reprojecting to a metric CRS (UTM, a national grid) with gdalwarp, or by passing gdaldem's -s 111120 scale, which approximately converts degrees to metres (valid only near the equator and degrading toward the poles — reprojection is better).
Vertical units in feet on a metric grid (or vice versa). Elevations in feet with horizontal metres inflate slope by a factor of ~3.28 unless you set the z-factor accordingly.

Always run gdalinfo dem.tif first to read the CRS, pixel size and (where present) vertical unit, before deriving anything.

A worked GDAL / QGIS workflow

Starting from a DEM in a geographic CRS that needs conditioning for terrain work:

1. Reproject to a metric CRS so x, y and z share metres:

gdalwarp -t_srs EPSG:32633 -r bilinear -tr 10 10 dem_geo.tif dem_utm.tif

(Use bilinear or cubic for continuous elevation; never near, which steps the surface and adds noise.)

2. Slope in degrees with Horn's method:

gdaldem slope dem_utm.tif slope_deg.tif -alg Horn

For percent rise, add -p. For a smoother surface, try -alg ZevenbergenThorne.

3. Aspect:

gdaldem aspect dem_utm.tif aspect.tif

Use -zero_for_flat if you want flats coded 0 rather than -9999.

4. Hillshade with a custom sun and vertical exaggeration:

gdaldem hillshade dem_utm.tif hillshade.tif -az 315 -alt 45 -z 1.5

For high relief, a multidirectional hillshade (-multidirectional) blends several azimuths and avoids losing detail in shadowed faces — useful for structural and lineament interpretation.

In QGIS, the equivalents live in the Processing toolbox under Raster terrain analysis (Slope, Aspect, Hillshade) and the GDAL provider, with the same parameters exposed in the dialog.

Choosing the right derivative

Slope for any steepness threshold: hazard screening (e.g. flag slopes above 30 degrees), road grade, erosion potential.
Aspect for directional questions: solar exposure for revegetation or snowmelt, structural dip-direction context, drainage orientation.
Hillshade for communication and visual interpretation, and as a basemap under thematic layers.

Resolution matters as much as the algorithm. A 1 m lidar DEM produces crisp slope but also amplifies surface noise (vegetation returns, microtopography); a 30 m DEM smooths real steep faces. Match cell size to the landform scale you care about, and consider light smoothing before slope if the DEM is noisy.

Common pitfalls and why they happen

Computing slope in a geographic CRS. Degrees-over-metres gives garbage. Reproject or scale. This is the single most frequent terrain error.
Reading hillshade as hazard. A dramatic hillshade reflects sun angle and vertical exaggeration, not steepness or instability. It is illustration, not measurement.
Averaging aspect arithmetically. Aspect is circular; ordinary means cross the 0/360 boundary incorrectly. Use northness/eastness.
Mixing units in comparisons. Comparing a degrees slope map with a percent one, or feet-z with metre-z, produces false differences.
Choosing the highest-resolution DEM reflexively. If the question is regional landform, a fine DEM adds noise and cost without adding signal; downsample deliberately.

Validation and QA

Sanity-check slope ranges (a continental interior should not be full of 80-degree slopes; if it is, suspect a CRS or z-unit problem). Confirm flat areas in aspect are flagged, not assigned a spurious direction. Compare hillshade against the true sun-illumination logic by flipping the azimuth and confirming relief does not appear inverted. Keep a provenance note: DEM source and date, CRS, cell size, algorithm, slope units, hillshade azimuth/altitude and z-factor, so any layer can be regenerated identically.

Bathyl perspective

We treat slope and aspect as measurement layers with documented units and CRS, and hillshade as a presentation layer that never carries a number into a decision. Every terrain derivative we deliver states the DEM source, resolution and the exact parameters used to compute it.

Slope, Aspect, and Hillshade From DEM Data