Analyse du mouvement à l'aide de surfaces de coût avec l'outil ArcGIS Path Distance?

Je voudrais analyser le mouvement hypothétique (à pied) dans un paysage en fonction de la dépense énergétique, mais j'ai rencontré des problèmes avec lesquels j'espère que vous pourriez m'aider. J'ai essayé de le faire en utilisant l'outil Path Distance d'ArcGIS dans Spatial Analyst en utilisant des surfaces de coût que j'ai créées, mais elles ne correspondent pas à ce à quoi je m'attendais.

Voici à quoi ressemble ma surface d'élévation (téléchargée depuis ASTER GDEM):

Sur la base des données d'altitude, j'ai créé une surface de coût qui est censée contenir la dépense énergétique (taux métabolique en watts) par unité de carte (m). Pour cela, j'ai utilisé cette formule: M = 1.5W + 2.0 (W + L) (L / W)2 + N (W + L) (1.5V2 + 0.35V * abs(G + 6))

Ou en termes de calculatrice raster: (1.5 * 60) + (2.0 * (60 + 3) * Square((3 / 60))) + (1.2 * (60 + 3) * (Square((1.5 * "movementspeed")) + (0.35 * "movementspeed") * Abs(("slopeinpercent" + 6))))

Où M est le taux métabolique en watts, W est le poids de l'individu modélisé, L est la charge transportée de l'individu, N est un facteur qui décrit la facilité de mouvement sur le terrain (à des fins de test définies à 1,2), V est l'individu vitesse de déplacement et G est la pente en pourcentage. Cela a créé une surface avec des valeurs comprises entre 90 et 25000, avec la majorité des valeurs entre 90 et 1000 (ce qui semble juste, les valeurs absurdement élevées sont très probablement le résultat de valeurs de pente défectueuses, qui pourraient facilement être corrigées).

La vitesse de déplacement a été calculée à l'aide de cette formule: V = 6e^(-3.5 * |s + 0.05|où s est la pente en degrés.

Ou en termes de calculatrice raster: 6 * Exp( - 3.5 * Abs(Tan("slopeindegrees") + 0.05)) cela a créé une surface avec des valeurs comprises entre 0 et 5,9 km / h, ce qui semble à peu près correct et correspond à ce que j'attendais.

Maintenant, ces surfaces ont été utilisées comme entrée dans l'outil Distance-chemin; le DEM en tant que raster de surface en entrée (c'est-à-dire in_surface_raster), la surface avec une dépense d'énergie en tant que raster de coût et le DEM en tant que raster vertical pour permettre à l'outil de calculer si l'individu modélisé monte ou descend une pente. À des fins de test, deux points situés dans les coins nord-ouest et sud-est du DEM ont été utilisés comme données sources (c'est-à-dire in_source_data). La sortie était la suivante (le rouge est involontairement les valeurs les plus faibles et le bleu les plus élevées):

Mon interprétation de la sortie est qu'elle ignore à peu près les différences d'élévation, et les différences de valeur sont simplement liées aux différences de distance. Je m'attendais à ce que la surface suive les zones plus plates de la partie ouest de la région et j'évitais les parties montagneuses de l'est, ce qui n'est clairement pas le cas. Mais, je suis encore assez nouveau dans ces types d'analyses et j'apprécierais les interprétations des autres. Alors, quelqu'un peut-il signaler des défauts dans ma méthodologie / formules qui pourraient provoquer une sortie étrange? Ou, la sortie est-elle attendue et je ne comprends tout simplement pas ce que je dois attendre d'une analyse de distance de chemin?

Ceci est très similaire à ce à quoi ressemble notre sortie de l'outil de distance de trajectoire incorporant une spécification dem, raster vertical et facteur vertical (ce qui est fondamentalement ce que vous essayez de faire avec votre couche de résistance, mais il différencie entre le mouvement en montée et en descente). C'est peut-être ce que l'on attend compte tenu de votre plage d'altitude et de vos pondérations de résistance. Mais, sur la base d'un examen rapide de votre DEM et de votre sortie, il semble qu'il y ait un certain nombre de choses qui pourraient faire en sorte que vos résultats n'apparaissent pas comme vous le souhaitez et que vous voudrez peut-être examiner de nouveau pour en être sûr.

1) Vous avez un gros morceau dans la partie sud-ouest de votre zone qui semble avoir été codé comme nodata (soit dans la couche DEM, soit dans la couche de résistance). Dans cette fonction, le SIG traite les pixels nodaux comme ayant essentiellement une résistance infinie. (C'est pourquoi cette chose insulaire a une valeur de distance très élevée)

2) Si vous utilisez la distance du chemin et spécifiez un raster vertical mais pas des facteurs verticaux (ou vice versa) ou si l'une de ces deux parties n'est pas correctement spécifiée ou formatée, la fonction échouera simplement à exécuter cette partie de l'outil et à utiliser le reste de l'algorithme pour produire une sortie, mais n'émettra aucun avertissement ou indication que les parties de direction verticale ou horizontale des analyses n'ont pas été exécutées correctement. De plus, le programme utilise parfois un fichier de facteur vertical ou horizontal ASCII dans certaines situations mais pas dans d'autres (comme cela fonctionnera si vous utilisez l'interface graphique, mais pas en python), indépendamment du formatage. Cela peut rendre cet outil difficile à résoudre. Nous allons généralement comparer les valeurs de distance d'une course avec et sans les facteurs verticaux pour voir si elles sont différentes.

3) Vous pourrez peut-être voir plus de détails sur ce que fait l'outil si vous l'exécutez sur vos points de test un par un (pour le moment, vous ne pouvez voir que la plus courte des deux distances à chaque pixel, car la fonction enregistre uniquement les distances de chaque pixel à l'un des deux points de l'entrée)

4) Sans de grandes différences d'altitude dans une zone d'étude et / ou une large gamme de pondérations pour les facteurs VRMA, la sortie d'une analyse qui examine notamment le coût du déplacement de haut en bas d'une colline n'est souvent pas très différente de une analyse euclidienne de la distance. Cependant, les chiffres que vous obtiendrez seront légèrement différents et, dans certains cas, si vous mappez les chemins les moins coûteux, ils emprunteront des itinéraires légèrement différents.

5) Techniquement, je pense que vous êtes censé utiliser un raster z-score au lieu d'un DEM comme entrée pour le raster vertical, mais les deux sont fréquemment utilisés sur les forums et, au moins pour nos données, les différences de sortie sont minimes.

La documentation d'ESRI à ce sujet est un peu dispersée, mais cette explication des facteurs verticaux est plutôt bonne: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost % 20complexité