What should a terrain analysis checklist for a client report contain?

At minimum: DEM source, acquisition date and resolution, horizontal CRS (EPSG code) and vertical datum, processing algorithm and parameters, slope units, hillshade illumination settings, void/artifact handling, and a confidence note on what each layer can and cannot support.

How do I document DEM provenance and vertical datum in a deliverable?

Record the product name (e.g. Copernicus GLO-30), the horizontal CRS as an EPSG code, and the vertical datum explicitly (e.g. EGM2008 geoid vs WGS84 ellipsoid). Mixing geoid- and ellipsoid-referenced elevations introduces tens of metres of offset.

What slope and hillshade settings should I report to a client?

State whether slope is in degrees or percent rise, the algorithm (Horn vs Zevenbergen-Thorne), and the cell size used. For hillshade, report azimuth, altitude, and any z-factor applied, and label it as a visualization layer rather than a measurement.

How do I make a terrain map reproducible for review?

Keep the exact GDAL/QGIS commands or a model file, the input DEM checksum, and the parameters in a methods appendix so a reviewer can regenerate the output byte-for-byte from the same source.

Terrain Analysis Checklist for Client Reports

The checklist in one paragraph

A defensible terrain deliverable answers four questions before any colour ramp is chosen: where did the elevation come from, what coordinate and vertical reference is it in, exactly how was each derivative computed, and what is the layer allowed to be used for. If those four are written down and reproducible, the rest of the report follows. This checklist walks through each item with the parameter names, EPSG codes, and command flags you should be recording, and the specific failure each check prevents.

1. DEM provenance and fitness for purpose

Start by naming the source product, not just "a DEM". The differences matter for what the map can claim:

Copernicus GLO-30 / GLO-90 — 30 m and 90 m global, derived from TanDEM-X. A digital surface model (DSM): it sits on canopy and rooftops, not bare earth.
SRTM 1 arc-second (~30 m) — older, with known voids in steep terrain that may have been filled by interpolation. Note whether you are using a void-filled version.
Copernicus DEM, USGS 3DEP — 3DEP includes 1 m and 1/3 arc-second lidar-derived products in the US; these can be DTMs (bare earth).
National lidar / photogrammetric DTMs — best for engineering work, but check the stated vertical accuracy (often quoted as RMSE in the metadata).

Record acquisition or release date and the native resolution. A 30 m DSM is unsuitable for measuring a 2 m road cutting; a smoothed 90 m product may be exactly right for regional landform context. Write down which it is and why it fits the question.

2. Coordinate reference system and vertical datum

This is the single most common source of silent error in terrain deliverables. Two separate things must be stated:

Horizontal CRS as an EPSG code. Geographic CRSs (EPSG:4326, lat/lon in degrees) are unsuitable for slope and area calculations because a cell is not square on the ground. Reproject to a metric projected CRS — a UTM zone (e.g. EPSG:32633 for UTM 33N) or a national grid (e.g. EPSG:27700, British National Grid) before computing derivatives.
Vertical datum. Is elevation referenced to a geoid (EGM2008, EGM96) or to the WGS84 ellipsoid? The difference reaches tens of metres regionally. A report that quotes elevations without naming the vertical datum is not auditable.

A clean reprojection to a metric grid with cubic resampling looks like:

gdalwarp -t_srs EPSG:32633 -tr 30 30 -r cubic -r_resampling \
  -dstnodata -9999 input_dem.tif dem_utm.tif

Confirm the result with gdalinfo dem_utm.tif and copy the reported CRS, pixel size, and NoData into your methods section verbatim.

3. Slope: units and algorithm

Slope is the item clients most often misread. Two settings must appear in the report:

Units. Degrees (0–90) or percent rise (rise/run × 100). They are not interchangeable: 45 degrees equals 100 percent. A geotechnical threshold of "slopes above 30 degrees" becomes nonsense if the raster is actually in percent.
Algorithm. GDAL gdaldem slope and QGIS default to the Horn method (3×3 neighbourhood, all eight neighbours). Zevenbergen-Thorne weights only the four cardinal neighbours and is sometimes preferred on smooth surfaces. State which you used.

gdaldem slope dem_utm.tif slope_deg.tif -alg Horn        # degrees
gdaldem slope dem_utm.tif slope_pct.tif -p -alg Horn     # percent

Because slope is computed over a 3×3 window, the cell size is part of the result. The same hillside yields a gentler slope on a 90 m DEM than on a 2 m DEM. Report the cell size alongside the slope statistics.

4. Hillshade: illumination settings, not measurements

Hillshade is a rendering. It is invaluable for revealing fault scarps, terraces, and drainage texture, but it is not a quantity. Always record:

Azimuth (default 315, light from the NW) and altitude (default 45 degrees).
z-factor — set to 1 only when horizontal and vertical units match. If horizontal is in degrees and vertical in metres, the z-factor must convert, or the relief will be wildly exaggerated. Working in a metric projected CRS (item 2) makes z-factor = 1 correct.

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

A known pitfall: a single NW azimuth creates azimuth bias — lineaments parallel to the light direction disappear. For structural interpretation, generate multidirectional hillshade (-multidirectional) or two hillshades at orthogonal azimuths and note this in the report.

5. Voids, artifacts, and edge effects

Inspect the data before trusting it:

NoData / voids — confirm NoData is set and not being read as 0 (which would appear as sea-level cliffs). gdalinfo -stats should not report a minimum of an implausible value.
Striping and stepping — common in older photogrammetric DEMs and in integer-quantised products; visible as banding in hillshade.
Edge effects — derivatives on the outer ring of cells are computed from incomplete neighbourhoods. Clip the analysis extent slightly inside the data footprint, or buffer the input DEM before processing and clip afterwards.
Pits and spurious sinks — matter most for hydrological derivatives; fill deliberately (e.g. QGIS Fill sinks (Wang & Liu)) and record that you did.

6. Documentation and reproducibility

The deliverable is only trustworthy if a reviewer can regenerate it. Include a short methods appendix containing:

The input DEM product, date, resolution, and a checksum (sha256sum input_dem.tif).
The exact reprojection and derivative commands, or the QGIS model / Processing history.
All parameters: algorithm, units, cell size, azimuth/altitude, z-factor, NoData.
A confidence note per layer: what it supports (e.g. "regional slope screening at 1:50,000") and what it does not (e.g. "not suitable for individual slope-stability assessment").

Worked example: a slope-class map for a client

gdalinfo the source: confirm it is GLO-30, EPSG:4326, EGM2008 vertical.
Reproject to EPSG:32633 at 30 m, cubic resampling, NoData -9999.
gdaldem slope -alg Horn in degrees.
Reclassify into client classes (0–5, 5–15, 15–30, >30 degrees) with the QGIS Reclassify by table algorithm, documenting the breakpoints and their geotechnical rationale.
Overlay a multidirectional hillshade at 40 percent opacity for context only.
Export with a layout that prints the CRS, source, date, and a "screening only" disclaimer.

QA before sign-off

Open the slope raster and check the value range matches the stated units (max ≤ 90 for degrees).
Spot-check three known locations against a topographic map or field knowledge.
Confirm the legend units, CRS, and source appear on the printed map, not only in the project file.
Re-run the documented commands on a clean machine and diff the output.

Bathyl perspective

We treat a terrain report as a chain of evidence: every derivative traces back to a named source, a stated CRS and datum, and a recorded parameter set. The colour ramp is the last decision, not the first. A client should be able to hand the appendix to a third party and get the same raster back.