Short answer

For DEM analysis both ArcGIS Pro and QGIS are professional-grade: each does slope, aspect, hillshade, curvature, hydrology, and viewshed to a standard you can publish. They diverge on the edges. ArcGIS Pro wins on integrated LiDAR/terrain-dataset handling, 3D scenes, and enterprise sharing through ArcGIS Online/Enterprise, at a per-user license plus extension cost. QGIS wins on price (free), on breadth of algorithms (it bundles GDAL, GRASS, and SAGA, so you get several independent implementations of every terrain operation), and on frictionless scripting. The deciding factors are your data type (raw LiDAR vs ready DEMs), your budget and existing Esri stack, and how much you value open reproducibility.

Crucially, the two do not always return the same number for the "same" operation, because defaults differ. Treat the choice as a workflow decision and always pin parameters explicitly.

Where the core terrain tools live

OperationArcGIS ProQGIS
Slope / AspectSpatial Analyst Slope, Aspectgdal:slope, gdal:aspect, GRASS r.slope.aspect, native raster terrain
HillshadeSpatial Analyst Hillshade (incl. multidirectional)gdal:hillshade, GRASS r.relief
CurvatureSpatial Analyst CurvatureGRASS r.slope.aspect (profile/tangential), SAGA
Fill sinksSpatial Analyst FillGRASS r.fill.dir, SAGA Fill Sinks (Wang & Liu)
Flow direction / accumulationSpatial Analyst Flow Direction, Flow Accumulation (D8/DInf/MFD)GRASS r.watershed, SAGA Flow Accumulation (Top-Down)
WatershedSpatial Analyst WatershedGRASS r.water.outlet, r.basin
ViewshedSpatial Analyst Viewshed 2GRASS r.viewshed
LiDAR / TIN3D Analyst terrain datasets, LAS datasetpdal integration, point cloud tools, gdal_grid

The asymmetry that matters: in QGIS many of these are extensions of the toolbox that ship for free (GRASS and SAGA come in the standard installer), whereas in ArcGIS the equivalents require the Spatial Analyst and 3D Analyst licenses.

Do they agree? Algorithms and defaults

Slope is the canonical test. Both Esri and GDAL default to Horn's (1981) third-order finite-difference method over a 3×3 window, so on the same projected DEM they typically agree to within rounding. But the defaults that trip people up:

  • Units. GDAL gdaldem slope returns degrees by default; ArcGIS Slope may be templated to percent. Set it explicitly.
  • Geographic CRS Z-scaling. If your DEM is in EPSG:4326 (degrees), horizontal units are degrees while elevation is metres, so raw slope is nonsense. GDAL needs -s (scale) or you reproject; ArcGIS has a Z-factor. The robust fix in either tool is to reproject to a projected, metre-based CRS first (gdalwarp -t_srs EPSG:32630 -r bilinear).
  • Edge handling and NoData. Different tools propagate NoData at borders differently, so a 1-pixel halo can differ.
  • Hillshade. Both default to azimuth 315°, altitude 45°, but ArcGIS multidirectional hillshade has no exact GDAL twin (GDAL offers -multidirectional as an approximation).

Practical takeaway: pick one tool per deliverable, pin every parameter, and validate against the other on a small tile rather than assuming interchangeability.

Hydrology: a genuine difference in philosophy

ArcGIS gives you a tightly integrated, GUI-guided chain (Fill → Flow Direction → Flow Accumulation → Watershed) with D8, D-Infinity, and MFD in one place and good documentation. QGIS routes hydrology mainly through GRASS r.watershed (a single command that computes flow accumulation, drainage direction, and basins, defaulting to an MFD-style algorithm many hydrologists prefer over plain D8) and SAGA terrain hydrology. Neither is "better" universally: ArcGIS is smoother for an analyst clicking through; GRASS/SAGA expose more algorithmic variety and run headless in scripts.

Reproducibility and automation

  • ArcGIS Pro: ModelBuilder (visual) and arcpy (Python). Reproducible, but bound to licensed extensions — a colleague without Spatial Analyst cannot rerun your slope model.
  • QGIS: the Processing Graphical Modeler, PyQGIS, and bare GDAL/GRASS command lines. A gdalwarp/gdaldem pipeline in a shell script or Makefile runs anywhere, on a server, in CI, with no license check. For long-lived, auditable terrain pipelines this is a real advantage.

Cost and ecosystem

ArcGIS Pro is a paid named-user license; terrain work needs Spatial Analyst, and LiDAR/3D needs 3D Analyst, each an added cost. In return you get integrated enterprise sharing, support, and tight LiDAR/terrain-dataset tooling. QGIS is free under the GNU GPL, has no per-seat cost, and leans on the broader open stack (GDAL, PROJ, GRASS, SAGA, PostGIS). For a small consultancy or a budget-constrained project, that difference is decisive; for an organisation already standardised on ArcGIS Enterprise, the integration may outweigh the cost.

Choosing — a short decision guide

  • Raw, unclassified LiDAR; 3D scenes; existing Esri Enterprise → ArcGIS Pro (Spatial + 3D Analyst, optionally Image Analyst).
  • Ready DEMs; slope/hillshade/hydrology; tight budget; scripted pipelines → QGIS with GDAL + GRASS/SAGA.
  • Mixed team, need cross-checks → use both: QGIS/GDAL for the open, reproducible pipeline; ArcGIS for sharing and stakeholder-facing scenes.

Common pitfalls and why they happen

  • Comparing slope outputs that used different units or Z-factors. They look "wrong" but the algorithm agrees; the parameters did not.
  • Running terrain analysis in a geographic CRS. Degrees-vs-metres mismatch makes slope and area meaningless in both tools. Reproject first.
  • Assuming D8 everywhere. ArcGIS Flow Direction defaults to D8; GRASS r.watershed does not. Drainage networks differ accordingly — choose deliberately.
  • Non-reproducible ArcGIS models. Sharing a ModelBuilder model with someone who lacks the extension. Document the license dependency.
  • NoData mishandling. A DEM with NoData = 0 produces edge artefacts in slope/hillshade in either tool. Set NoData correctly before processing.

QA / validation

The strongest validation is cross-tool agreement: run the same DEM through gdaldem slope and ArcGIS Slope (matched units and Z-factor) and difference the rasters — agreement to within a small edge halo confirms both. For hydrology, overlay the derived stream network on independent hydrography and check the trunk channels coincide. Always confirm CRS (projected, metres) and NoData up front, since those, not the software choice, cause most terrain errors.

Bathyl perspective

We default to the open, scriptable path (QGIS + GDAL/GRASS) for the analytical core because it is reproducible without a license gate, and we use ArcGIS Pro where its LiDAR/terrain-dataset integration or enterprise sharing genuinely earns its cost. Either way we pin parameters and cross-check the result, so a slope class or a catchment boundary stands on the numbers, not on the brand of toolbox.

Related reading

Sources