Я хотел бы проанализировать гипотетическое движение (пешком) в ландшафте, основанное на расходе энергии, но я столкнулся с некоторыми проблемами, с которыми я надеюсь, что вы могли бы помочь мне. Я попытался сделать это, используя инструмент Path Distance в ArcGIS в Spatial Analyst, используя созданные мной стоимостные поверхности, но результат оказался не таким, как я ожидал.
Вот так выглядит моя поверхность возвышения (скачано с 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 км / ч, что кажется правильным и согласуется с тем, что я ожидал.
Теперь эти поверхности использовались в качестве входных данных в инструменте Path Distance; матрица высот в качестве входного растра поверхности (т. е. in_surface_raster), поверхность с расходом энергии в качестве растра затрат и матрица высот в качестве вертикального растра, чтобы инструмент мог рассчитать, движется ли моделируемый индивид вверх или вниз по склону. В целях тестирования в качестве исходных данных использовались две точки в северо-западном и юго-восточном углах матрицы высот (т.е. in_source_data). Вывод был таким (красный - это самые низкие значения, а синий - самые высокие):
Моя интерпретация выходных данных заключается в том, что он в значительной степени игнорирует различия в высоте, а различия в значении просто связаны с различиями в расстоянии. Я ожидал бы, что поверхность будет следовать за более плоскими областями в западной части региона и избегать горных восточных частей, чего он явно не делает. Но я все еще довольно новичок в этих видах анализа и буду признателен за интерпретации других. Итак, кто-нибудь может указать на какие-либо недостатки в моей методологии / формулах, которые могут привести к странным результатам? Или ожидаемый результат, и я просто не понимаю, чего мне ожидать от анализа расстояния пути?
Ответы:
Это очень похоже на то, как выглядит наш вывод из инструмента «Траектория расстояния», который включает в себя спецификации демона, вертикального растра и вертикального фактора (что в основном то, что вы пытаетесь сделать со своим слоем сопротивления, но оно различает движение в гору и спуск). Это может быть только то, что ожидается, учитывая ваш диапазон высот и веса сопротивления. Но, основываясь на быстром взгляде на вашу матрицу высот и результаты, кажется, что есть ряд вещей, которые могут привести к тому, что ваши результаты не будут отображаться так, как вы могли бы пожелать, и что вы, возможно, захотите взглянуть еще раз, чтобы быть уверенным.
1) У вас есть значительный кусок в юго-западной части вашего района, который, по-видимому, был закодирован как нодата (либо в DEM, либо в слое сопротивления). В этой функции ГИС рассматривает пиксели узлов как имеющие бесконечное сопротивление. (Вот почему эта островная вещь имеет очень большое значение расстояния)
2) Если вы используете расстояние пути и задаете вертикальный растр, но не вертикальные факторы (или наоборот) или если какая-либо из этих двух частей неправильно задана или отформатирована, функция просто не сможет выполнить эту часть инструмента и использовать остальная часть алгоритма для получения выходных данных, но не будет выдавать никаких предупреждений или указаний на то, что части анализа в вертикальном или горизонтальном направлении не были выполнены должным образом. Кроме того, иногда программа будет использовать вертикальный или горизонтальный факторный файл ASCII в некоторых ситуациях, но не в других (например, это будет работать при использовании графического интерфейса, но не Python), независимо от форматирования. Это может затруднить устранение неисправностей этого инструмента. Обычно мы входим и сравниваем значения расстояния от пробега с вертикальными коэффициентами и без них, чтобы увидеть, отличаются ли они.
3) Возможно, вы сможете увидеть более подробную информацию о том, что делает инструмент, если вы запустите его на своих контрольных точках по одному (сейчас вы можете видеть только меньшее из двух расстояний в каждом пикселе, поскольку функция записывает только расстояния от каждого пикселя до одной из двух точек на входе)
4) Без значительных различий в высоте над зоной исследования и / или в широком диапазоне весовых коэффициентов для факторов VRMA результаты анализа, в котором учитывается стоимость перемещения вверх и вниз по склону, часто просто не сильно отличаются от евклидов анализ расстояния. Однако числа, которые вы получите, будут немного отличаться, и в некоторых случаях, если вы отобразите пути с наименьшей стоимостью, они выберут несколько другие маршруты.
5) Технически я думаю, что вы должны использовать растр с z-счетом вместо матрицы высот в качестве входных данных для вертикального растра, но оба они часто используются на форумах, и, по крайней мере для наших данных, различия в выходных данных минимальны.
Документация ESRI по этому вопросу немного разбросана, но это объяснение вертикальных факторов довольно хорошее: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost % 20complexity
источник