Why does my slope raster look speckled or noisy?

Slope is a derivative, so it amplifies small elevation errors. Quantized vertical values, sensor noise, interpolation artifacts, and stair-stepping in the DEM all create large cell-to-cell slope jumps even when the real terrain is smooth.

How does DEM vertical resolution cause slope noise?

If elevation is stored in coarse vertical steps (for example integer meters), flat terrain becomes a staircase. Each step edge is a sudden rise over one cell, which the slope algorithm reads as a steep face, producing banding and speckle.

How do I smooth a slope map without distorting the terrain?

Smooth the DEM before computing slope (a low-pass or mean/Gaussian filter), use a larger analysis window, or resample to a resolution matched to the question. Smoothing the slope output afterwards is less faithful than smoothing the input.

Why is LiDAR-derived slope noisier than coarse DEM slope?

Fine resolution resolves real micro-relief (vegetation residue, tractor ruts, rocks) plus sensor noise that coarse DEMs average away. At 0.5 m, every small bump is a slope feature, so the map looks busy even though it is accurate.

Why Slope Maps Look Noisy (DEM Artifacts and Fixes)

Short answer

Slope maps look noisy because slope is a derivative of elevation, and differentiation amplifies error. Any small imperfection in the DEM — a one-meter vertical quantization step, sensor speckle, an interpolation seam, a stair-stepped flat — turns into a large cell-to-cell change in slope. The fix is rarely a different color ramp. It is matching the DEM's resolution, vertical precision, and smoothing to the question you are actually asking, usually by conditioning the elevation surface before you compute slope.

How slope is computed, and why that matters

Almost every GIS computes slope from a moving 3×3 window of cells. The standard method (Horn's, used by gdaldem slope, the QGIS Slope algorithm, and the ArcGIS Slope tool by default) estimates the partial derivatives ∂z/∂x and ∂z/∂y from the eight neighbors of each cell, weighting the cardinal neighbors more than the diagonals. Slope is then atan(sqrt((dz/dx)² + (dz/dy)²)).

Two consequences follow directly:

The result depends on cell size. The same vertical change spread over a 30 m cell is a gentle slope; over a 0.5 m cell it is a cliff. Halving the cell size roughly doubles the slope from a fixed vertical error.
The window only sees three cells across. Real noise at the single-cell scale passes straight through, because there is no averaging beyond the immediate neighborhood.

So slope inherits the DEM's resolution and noise, then sharpens them.

The specific causes of noise

Vertical quantization (the staircase)

If the DEM stores elevation as integer meters (common in older or compressed data), a gently sloping field is recorded as a series of flat treads separated by 1 m risers. Across a tread, slope is 0°; at each riser, the algorithm sees 1 m of rise over one cell width and reports a steep face. The result is banding — bands of zero slope alternating with sharp lines — most visible on shallow terrain where the steps are widely spaced. The cure is finer vertical precision (floating-point elevation) or smoothing that bridges the steps.

Sensor and interpolation noise

LiDAR and photogrammetric DEMs carry measurement noise of a few centimeters to decimeters. At fine resolution this noise is comparable to real micro-relief, so it shows up as salt-and-pepper speckle in slope. Gridded DEMs interpolated from points (TIN-to-raster, IDW, splines) can also leave seams, dimples, or pits at the interpolation structure, which slope exposes.

Resolution mismatch

A 0.5 m LiDAR DTM resolves tractor ruts, drainage furrows, individual boulders, and ground-classification residue under vegetation. All of those are real, but for a regional landslide-susceptibility screen they are noise relative to the landform signal. The map is not wrong; it is answering a finer question than you asked.

Edge effects and NoData

At the raster edge and around NoData holes, the 3×3 window is incomplete. Many tools either return NoData or fudge the missing neighbors, producing a fringe of spurious high or zero slope around voids — common in DEMs with unfilled water bodies or radar shadow.

Worked example — diagnose before you smooth

First confirm the DEM is real elevation and inspect its precision:

gdalinfo -stats dem.tif
# Check: pixel size, data type (Float32 vs Int16), NoData value,
# and Min/Max — integer meters in the stats hints at quantization

A Type=Int16 with integer min/max on shallow terrain is a strong signal that staircase banding will appear in slope. A 0.5 m Float32 LiDAR DTM points instead to micro-relief speckle.

Worked example — condition the DEM, then compute slope

The most faithful approach smooths the input elevation, not the output slope, because slope of a smoothed surface is geometrically meaningful whereas a smoothed slope raster is just blurred.

# 1. Low-pass the DEM with a 3x3 mean (or use a Gaussian for gentler results)
gdal_calc.py ... # or QGIS "r.neighbors" / "Smooth raster"

# 2. Compute slope in degrees from the smoothed DEM, Horn's method
gdaldem slope dem_smooth.tif slope_deg.tif -compute_edges

-compute_edges keeps slope values at the raster border instead of leaving a NoData fringe. For percent slope add -p; never mix degrees and percent in one analysis. In GRASS (available inside QGIS), r.slope.aspect paired with r.neighbors gives fine control, and r.relief/r.param.scale allow a multi-cell window so slope reflects landform rather than single-cell noise.

Match resolution to the question

If the noise is genuine fine detail you do not need, resample to a coarser grid before computing slope:

# Resample 0.5 m LiDAR to 5 m with averaging (not nearest neighbor)
gdalwarp -tr 5 5 -r average dem_05m.tif dem_5m.tif
gdaldem slope dem_5m.tif slope_5m.tif -compute_edges

Use -r average (or cubic) so each coarse cell summarizes its inputs. Nearest-neighbor resampling preserves the noise and defeats the purpose.

A note on hillshade

If your "noisy slope map" is actually a hillshade, remember hillshade (gdaldem hillshade) is a visualization, not a measurement. It exaggerates fine relief by design (especially with low sun-altitude angles), so it will look busy on detailed DEMs. Do not interpret hillshade speckle as a quantitative slope problem; if you need numbers, work from the slope raster.

Validation

Profile a transect across terrain you know is smooth (a paved road, a flat field) and confirm slope there is near zero, not oscillating.
Compare slope from the raw and conditioned DEM side by side; the landform pattern should survive while the speckle disappears. If real ridges and valleys also vanish, you over-smoothed.
Check the slope histogram: a spike at 0° plus a secondary cluster at one specific high value is the signature of quantization banding.
Inspect edges and around NoData voids specifically, not just the clean interior.

Common pitfalls and why they happen

Smoothing the slope output instead of the DEM. It hides speckle but the values no longer correspond to any real surface gradient.
Computing slope at native LiDAR resolution for a regional question. You get accurate micro-slope where you wanted landform slope. Resample first.
Using nearest-neighbor when resampling. It carries the noise straight through. Use average or cubic for continuous elevation.
Mismatched horizontal and vertical units. A DEM in a geographic CRS (degrees) with elevation in meters yields nonsense slope; reproject to a projected CRS in meters with gdalwarp first.
Ignoring NoData. Unset or wrong NoData turns voids into extreme slopes around their edges.

Bathyl perspective

We choose DEM resolution to fit the decision, not the other way around, and we condition the elevation surface before deriving slope so the result reflects terrain rather than acquisition artifacts. Every slope deliverable carries its source DEM, resolution, vertical units, method, and any smoothing, so a reviewer can tell signal from sensor. A clean-looking slope map that hides its processing is harder to trust than a busy one that documents it.

Why Slope Maps Look Noisy