Réponse courte

La pente est le rapport dénivelé sur distance. Dans un SCR géographique comme WGS84 (EPSG:4326), la distance — l'espacement horizontal entre pixels — est exprimée en degrés de latitude et de longitude, tandis que le dénivelé — l'altitude — est en mètres. L'algorithme de pente calcule la différence d'altitude divisée par la distance horizontale ; il divise donc des mètres par des degrés. Ce n'est pas seulement imprécis, c'est dimensionnellement incohérent, et comme un degré couvre environ 111 km alors que les différences d'altitude se chiffrent en dizaines de mètres, la distance est énormément sous-estimée et la pente ressort follement exagérée, souvent collée près de 90 degrés sur tout le raster.

La solution consiste à rendre identiques les unités horizontales et verticales. Soit reprojeter le MNT vers un SCR projeté en mètres avant de calculer la pente, soit fournir un z-factor qui convertit les unités — et la voie du z-factor est fragile car la conversion dépend de la latitude.

Ce que calculent réellement les algorithmes de pente

La pente standard (la méthode de Horn 1981 utilisée par GDAL gdaldem et les outils de pente de QGIS/ArcGIS) ajuste un plan à une fenêtre de 3×3 cellules et calcule le gradient à partir des différences d'altitude au sein de la fenêtre, divisé par l'espacement des cellules. En pseudo-code :

dz/dx = (variation d'altitude est–ouest) / (2 × cell_width)
dz/dy = (variation d'altitude nord–sud) / (2 × cell_height)
slope = atan( sqrt( (dz/dx)^2 + (dz/dy)^2 ) )

L'algorithme suppose que cell_width, cell_height et les valeurs d'altitude sont tous dans la même unité linéaire. Dans une dalle SRTM à 1 arc-seconde, la taille de cellule indiquée dans le raster est 0.0002777778 degré, pas 30 mètres. Injectez cela dans la formule face à des altitudes en mètres et dz/dx est gonflé d'un facteur d'environ 111 000 — le nombre de mètres dans un degré. La pente sature.

Le piège de la latitude

Même si vous tentez de compenser, les coordonnées géographiques cachent un second problème : un degré de longitude n'est pas une distance au sol fixe. Il rétrécit avec le cosinus de la latitude.

  • À l'équateur, 1 degré de longitude ≈ 111,3 km.
  • À 45 degrés de latitude, ≈ 78,7 km.
  • À 60 degrés de latitude, ≈ 55,7 km.

Un degré de latitude reste proche de 111 km partout. Donc, dans un SCR géographique, vos pixels ne sont même pas carrés au sol — ils sont progressivement plus larges (E–O) que hauts (N–S) à mesure que vous vous éloignez de l'équateur. Toute correction d'unité horizontale unique n'est donc valable qu'à une seule latitude. Sur un MNT qui s'étend sur plusieurs degrés de latitude, aucun z-factor constant n'est correct partout.

Les deux solutions

Solution 1 (recommandée) : reprojeter vers un SCR métrique

Reprojetez le MNT vers un système de coordonnées projeté dont les unités sont des mètres et qui correspond à votre zone — en général la zone UTM locale, ou une grille nationale. Avec GDAL :

gdalwarp -t_srs EPSG:32633 -r bilinear -tr 30 30 \
  dem_wgs84.tif dem_utm33n.tif

Ici EPSG:32633 est WGS84 / UTM zone 33N, -r bilinear est le rééchantillonnage approprié pour une altitude continue (jamais le plus proche voisin pour un MNT dont vous tirerez la pente — il introduit des artefacts en escalier), et -tr 30 30 fixe une grille propre de 30 m. Calculez ensuite la pente sur le raster reprojeté :

gdaldem slope dem_utm33n.tif slope_deg.tif

Désormais dénivelé et distance sont tous deux en mètres, le z-factor vaut 1 par défaut, et la sortie est correcte. Dans QGIS, c'est Raster → Projections → Warp (Reprojeter) suivi de Analyse de terrain raster → Pente, ou l'algorithme de pente GDAL dans la boîte à outils de traitements.

Solution 2 (dernier recours) : fixer un z-factor

Si vous ne pouvez vraiment pas reprojeter — disons que les données doivent rester en 4326 pour un pipeline de tuilage — vous pouvez passer un z-factor qui met à l'échelle les unités verticales vers les degrés horizontaux. Pour un MNT avec des altitudes en mètres, une approximation utilisable à une latitude représentative φ est :

z-factor = 1 / (111320 × cos(φ))

ArcGIS Pro l'expose directement : l'outil Pente, lorsque l'entrée est dans un SCR géographique, peut appliquer un z-factor tenant compte de la latitude, et Esri publie une table de correspondance des z-factors par latitude. QGIS et gdaldem exposent un paramètre -s/scale qui fait la même chose (gdaldem slope -s 111120 ... est le raccourci courant, valable uniquement près de l'équateur). Le hic est tout ce qui précède : ce n'est correct que pour une bande de latitude étroite. Réservez-le aux petites dalles à faible relief et à latitude unique, et documentez-le. Reprojetez pour tout le reste.

Exemple détaillé

Vous téléchargez une dalle Copernicus DEM à 1 arc-seconde centrée sur 60°N. Les altitudes sont en mètres, le SCR est EPSG:4326.

  • Calcul de pente tel quel : quasiment chaque cellule indique une pente supérieure à 89 degrés. Manifestement faux.
  • Application d'une seule échelle équatoriale de 111120 : la pente baisse mais reste trop forte, car à 60°N un degré de longitude ne fait que ~55,7 km, soit environ la moitié de la valeur équatoriale — votre distance est surestimée, la pente sous-estimée dans la direction E–O et incohérente avec la N–S.
  • Reprojection vers EPSG:32635 (UTM 35N) avec gdalwarp, puis gdaldem slope : les valeurs ressemblent enfin à un vrai terrain — fonds de vallée à 0–3 degrés, versants à 15–35 degrés, falaises au-delà de 45. Recoupez avec des courbes de niveau ou une pente de route connue pour confirmer.

QA et validation

  • Inspectez d'abord le SCR. gdalinfo dem.tif affiche le système de coordonnées et, vers le bas, Pixel Size = (0.000277..., -0.000277...). Des degrés dans la taille de pixel sont votre signal d'alarme.
  • Vérifiez l'histogramme de pente. Un raster de pente correct présente une distribution lisse concentrée sous 45 degrés pour la plupart des paysages. Un pic au maximum signale une incohérence d'unités.
  • Comparez à un témoin. Mesurez une pente que vous connaissez — un front de carrière, une route en remblai, une piste de ski — et confirmez que le raster concorde à quelques degrés près.
  • Revérifiez les unités verticales. Un MNT en pieds face à une grille horizontale métrique nécessite un z-factor de 0,3048. C'est un autre axe du même problème d'unités, tout aussi capable de produire une pente fausse.

Pièges courants et leurs causes

  • Se fier à la reprojection à la volée. QGIS affichera ensemble un MNT en 4326 et un fond de carte en UTM, ce qui fait croire que le MNT est « en mètres ». La reprojection d'affichage ne change jamais l'espacement de pixels stocké que lit l'outil de pente.
  • Utiliser le Web Mercator (EPSG:3857) comme SCR métrique. Il est en mètres, mais il déforme fortement la distance avec la latitude — le facteur d'échelle à 60°N est d'environ 2. La pente d'un MNT en Mercator est fausse de la même famille de façons. Utilisez une projection locale conforme (UTM, grille nationale), pas Mercator, pour le terrain.
  • Rééchantillonnage au plus proche voisin lors de la reprojection. Il préserve les valeurs exactes mais crée des marches d'altitude qui deviennent des pics de pente parasites. Utilisez le bilinéaire ou le cubique pour les MNT.
  • Un seul z-factor sur une zone d'étude étendue. Correct à la latitude centrale, de plus en plus faux vers les bords supérieur et inférieur.

Le point de vue Bathyl

Nous traitons le SCR d'un raster d'altitude comme une composante de la mesure, pas comme un réglage d'affichage, car la pente, l'exposition et la courbure héritent toutes silencieusement d'une erreur d'unités de la grille sur laquelle elles sont calculées. L'habitude fiable est simple : reprojeter les MNT vers un SCR métrique local avant toute dérivée de terrain, et réserver les coordonnées géographiques au stockage et à l'échange, jamais à l'analyse.

Pour aller plus loin avec Bathyl

Sources