Analisando movimento usando superfícies de custo com a ferramenta ArcGIS Path Distance?

Gostaria de analisar o movimento hipotético (a pé) em uma paisagem com base no gasto de energia, mas encontrei alguns problemas com os quais espero que você possa me ajudar. Eu tentei fazer isso usando a ferramenta Path Distance do ArcGIS no Spatial Analyst usando superfícies de custo que eu criei, mas o resultado não é o que eu esperava.

É assim que minha superfície de elevação se parece (baixada do ASTER GDEM):

Com base nos dados de elevação, criei uma superfície de custo que deveria conter gasto de energia (taxa metabólica em Watts) por unidade de mapa (m). Para isso, usei esta fórmula: M = 1.5W + 2.0 (W + L) (L / W)2 + N (W + L) (1.5V2 + 0.35V * abs(G + 6))

Ou coloque nos termos da Calculadora 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))))

Onde M é a taxa metabólica em Watts, W é o peso do indivíduo modelado, L é a carga transportada do indivíduo, N é um fator que descreve a facilidade de movimento no terreno (para fins de teste definidos em 1.2), V é o número de indivíduos velocidade de movimento e G é a inclinação em porcentagem. Isso criou uma superfície com valores variando entre 90 e 25000, com a maioria dos valores entre 90 e 1000 (o que parece certo, os valores absurdamente altos são provavelmente o resultado de valores de inclinação defeituosos, que poderiam ser facilmente corrigidos).

A velocidade de movimento foi calculada usando esta fórmula: V = 6e^(-3.5 * |s + 0.05|onde s é a inclinação em graus.

Ou, em termos da Calculadora de varredura: 6 * Exp( - 3.5 * Abs(Tan("slopeindegrees") + 0.05)) Isso criou uma superfície com valores entre 0 e 5,9 km / h, o que parece certo e é consistente com o que eu esperava.

Agora, essas superfícies foram usadas como entrada na ferramenta Path Distance; o DEM como varredura da superfície de entrada (ou seja, in_surface_raster), a superfície com gasto de energia como varredura de custo e o DEM como varredura vertical para permitir que a ferramenta calcule se o indivíduo modelado está subindo ou descendo uma ladeira. Para fins de teste, dois pontos nos cantos noroeste e sudeste do DEM foram usados ​​como dados de origem (ou seja, in_source_data). A saída foi essa (vermelho são os valores mais baixos e azul, mais alto):

Minha interpretação da saída é que ela praticamente ignora as diferenças de altitude, e as diferenças de valor estão simplesmente relacionadas às diferenças de distância. Eu esperaria que a superfície seguisse as áreas mais planas da parte oeste da região e evitasse as partes montanhosas do leste, o que claramente não acontece. Mas, ainda sou novo nesse tipo de análise e apreciaria as interpretações de outras pessoas. Então, alguém é capaz de apontar falhas nas minhas metodologias / fórmulas que possam causar uma saída estranha? Ou, é o resultado esperado e estou simplesmente entendendo mal o que devo esperar de uma análise de distância do caminho?

Isso é muito parecido com o resultado da ferramenta de distância do caminho, que incorpora uma especificação dem, raster vertical e fator vertical (que é basicamente o que você está tentando fazer com sua camada de resistência, mas diferencia entre movimento de subida e descida). Pode ser apenas o esperado, considerando a faixa de elevação e os pesos de resistência. Mas, com base em uma rápida olhada no DEM e na saída, parece haver várias coisas que podem estar fazendo com que os resultados não apareçam como você deseja e que você pode querer dar uma segunda olhada para ter certeza.

1) Você tem um pedaço considerável na parte sudoeste da sua área que parece ter sido codificado como nodata (no DEM ou na camada de resistência). Nesta função, o GIS trata os pixels nodata como tendo essencialmente uma resistência infinita. (É por isso que essa coisa de ilha tem um valor de distância muito alta)

2) Se você estiver usando a distância do caminho e especificando uma varredura vertical, mas não os fatores verticais (ou vice-versa) ou se alguma dessas duas partes for especificada ou formatada incorretamente, a função simplesmente falhará ao executar esta parte da ferramenta e use o botão restante do algoritmo para produzir saída, mas não emitirá nenhum aviso ou indicação de que as partes de direção vertical ou horizontal das análises não foram executadas corretamente. Além disso, às vezes o programa usa um arquivo de fator vertical ou horizontal ASCII em algumas situações, mas não em outras (como funcionará se estiver usando a GUI, mas não o python), independentemente da formatação. Isso pode dificultar a solução da ferramenta. Geralmente, comparamos os valores da distância de uma corrida com e sem os fatores verticais para ver se são diferentes.

3) Você poderá ver mais detalhes sobre o que a ferramenta está fazendo se executá-la nos pontos de teste, uma de cada vez (no momento, você só pode ver a menor das duas distâncias em cada pixel, pois a função registra apenas as distâncias de cada pixel até um dos dois pontos na entrada)

4) Sem grandes diferenças de altitude em uma área de estudo e / ou uma ampla faixa de ponderações para o VRMA, o resultado de uma análise que considera incluir o custo de subir e descer uma colina geralmente não parece muito diferente de uma análise euclidiana da distância. No entanto, os números obtidos serão ligeiramente diferentes e, em alguns casos, se você mapear os caminhos de menor custo, eles seguirão rotas ligeiramente diferentes.

5) Tecnicamente, acho que você deve usar uma varredura com z-score em vez de um DEM como entrada para a varredura vertical, mas ambos são usados ​​com freqüência nos fóruns e, pelo menos para nossos dados, as diferenças de saída são mínimas.

A documentação da ESRI sobre isso é um pouco dispersa, mas essa explicação dos fatores verticais é muito boa: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost % 20complexidade