Аналіз руху за допомогою витратних поверхонь за допомогою інструменту ArcGIS Path Distance?


9

Я хотів би проаналізувати гіпотетичний рух (пішки) в ландшафті як виходячи з витрат енергії, але я зіткнувся з деякими неприємностями, з якими сподіваюся, що ви могли б мені допомогти. Я намагався зробити це за допомогою інструменту ArcGIS Path Distance-інструмент у просторовому аналітиці, використовуючи створені мною поверхні, але в результаті це не те, що я б очікував.

Ось так виглядає моя поверхня висоти (завантажена з ASTER GDEM): Дані висоти, де білі / пурпурові ділянки найвищі, а зелені - найнижчі.

На основі даних про висоту я створив поверхню витрат, яка повинна містити витрати енергії (швидкість метаболізму у Ваттах) на одиницю карти (м). Для цього я використав цю формулу: M = 1.5W + 2.0 (W + L) (L / W)2 + N (W + L) (1.5V2 + 0.35V * abs(G + 6))

Або введіть у Растровий калькулятор умови: (1.5 * 60) + (2.0 * (60 + 3) * Square((3 / 60))) + (1.2 * (60 + 3) * (Square((1.5 * "movementspeed")) + (0.35 * "movementspeed") * Abs(("slopeinpercent" + 6))))

Де M - швидкість метаболізму у ваттах, W - вага модельованого індивіда, L - перенесене навантаження індивіда, N - коефіцієнт, що описує легкість пересування по місцевості (для цілей тестування встановлено 1,2), V - індивід швидкість руху, а G - нахил у відсотках. Це створило поверхню зі значеннями від 90 до 25000, при цьому більшість значень між 90 і 1000 (що здається правильним; абсурдно високі значення, швидше за все, є наслідком хибних значень схилу, які можна було б легко виправити).

Швидкість руху обчислювали за цією формулою: V = 6e^(-3.5 * |s + 0.05|де s - нахил у градусах.

Або, кажучи, в календарі Raster Calculator: 6 * Exp( - 3.5 * Abs(Tan("slopeindegrees") + 0.05)) Це створило поверхню зі значеннями від 0 до 5,9 км / год, що здається правильним і відповідає тому, що я очікував.

Тепер ці поверхні використовувались як вхід у інструмент «Відстань шляху»; DEM як растр вхідної поверхні (тобто in_surface_raster), поверхня з витратами на енергію як растр витрат і DEM як вертикальний растр, щоб інструмент міг розрахувати, рухається чи не модельований індивід вгору чи вниз по схилу. Для цілей тестування в якості вихідних даних використовувались дві точки в північно-західному та південно-східному кутах DEM (тобто in_source_data). Вихід був таким (червоний - неінтуїтивно найнижчі значення, а синій - найвищі): Витрати на енергію з найменшими значеннями - червоний

Моя інтерпретація результату полягає в тому, що він в значній мірі ігнорує відмінності у висоті, а відмінності у величині просто пов'язані з різницею у відстані. Я б очікував, що поверхня піде на більш плоскі райони в західній частині регіону і уникне гірських східних частин, чого, очевидно, не робить. Але я все ще досить новачок у подібних типах аналізів і буду вдячний за тлумачення інших. Отже, чи може хтось вказати на якісь недоліки в моїй методології / формулах, які могли б спричинити дивний вихід? Або, чи очікується вихід, і я просто не розумію, чого слід очікувати від аналізу відстані шляху?


У "Інструменті відстані шляху" поле "Введення растрових даних або даних джерела функції" являє собою одну або декілька точок, ЯКІ Ви обчислюєте шлях. ESRI каже: "Це растровий набір даних або функцій, який ідентифікує комірки або місця, до яких обчислюється найменше накопичена вартість відстані для кожного місця вихідної комірки. Використання DEM для цього не має сенсу, IMO. Після цього кроку слід Обчислення "Найкоротшого шляху" (Інструменти перетасовувались навколо Arc10 та називали по-різному), за допомогою якого ви вводите точку ВІД, звідки ви обчислюєте шлях до раніше визначених вихідних місць.
G-wizard

Я не використовував DEM в якості вихідного шару, він використовувався лише як вхідний дані в тому, що ARCGIS називає "in_surface_raster". Я використовував два точки на північному заході та південному сході в якості вихідного шару. Вибачте за плутанину, я відредагую свою публікацію, щоб правильно розмежувати їх.
Ола

Відповіді:


4

Це дуже схоже на те, як виглядає наш вихід із інструменту відстані шляху, що містить дем, вертикальний растр та специфікацію вертикального коефіцієнта (що в основному те, що ви намагаєтесь зробити з вашим шаром опору, але він розрізняє рух вгору та на спуск). Це може бути саме те, що очікується, враховуючи ваш діапазон висот та коефіцієнт опору. Але, виходячи з швидкого огляду вашої DEM та результатів, можливо, є багато речей, які можуть спричинити показ ваших результатів не так, як ви могли б хотіти, і, можливо, ви хочете переглянути ще один погляд, щоб бути впевненим.

1) У вас в південно-західній частині вашої області помітний шматок, який, схоже, був закодований як нодати (або в DEM, або в шарі опору). У цьому функціонері GIS розглядає пікселі нодатів, як по суті, мають нескінченний опір. (Ось чому ця острівна річ має дуже велике значення відстані)

2) Якщо ви використовуєте відстань шляху і вказуєте вертикальний растр, але не вертикальний коефіцієнт (або навпаки) або якщо будь-яка з цих двох частин неправильно вказана або відформатована, функція просто не зможе виконати цю частину інструменту і використовувати решта алгоритму для отримання результатів, але не видаватиме жодних попереджень або вказівки на те, що частини вертикального чи горизонтального напрямів аналізів не були виконані належним чином. Крім того, іноді програма використовуватиме файл вертикального або горизонтального фактора ASCII в деяких ситуаціях, але не в інших (як це буде працювати, якщо використовувати графічний інтерфейс, але не пітон), незалежно від форматування. Це може ускладнити усунення несправностей. Зазвичай ми входимо і порівнюємо значення відстані від пробігу з і без вертикальних факторів, щоб побачити, чи вони різні.

3) Можливо, ви зможете побачити більш детальну інформацію про те, що робить цей інструмент, якщо запустити його на своїх тестових балах по одному (зараз ви можете переглядати лише коротші з двох відстаней на кожному пікселі, оскільки функція записує лише відстані від кожного пікселя назад до однієї з двох точок на вході)

4) Без великих перепадів висоти в досліджуваній області та / або широкого діапазону вагових коефіцієнтів для факторів VRMA результат, отриманий з аналізу, який враховує, включаючи витрати на просування вгору та вниз по схилу, часто просто не сильно відрізняється від евклідовий аналіз відстані. Однак отримані вами цифри будуть дещо різними, і в деяких випадках, якщо ви складете карту найменш витратних шляхів, вони пройдуть трохи іншими маршрутами.

5) Технічно я думаю, що ви повинні використовувати растр z-score замість DEM в якості вхідного сигналу для вертикального растру, але обидва використовуються часто на форумах і, принаймні, за нашими даними, відмінності у виході мінімальні.

Документація ESRI щодо цього дещо розсіяна, але це пояснення вертикальних факторів досить добре: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost % 20складність

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.