Me gustaría analizar el movimiento hipotético (a pie) en un paisaje basado en el gasto de energía, pero me he encontrado con algunos problemas con los que espero que puedan ayudarme. He intentado hacer esto usando la herramienta de distancia de ruta de ArcGIS en Spatial Analyst usando las superficies de costo que he creado, pero el resultado no es lo que esperaba.
Así es como se ve mi superficie de elevación (descargada de ASTER GDEM):
Con base en los datos de elevación, creé una superficie de costo que se supone que contiene el gasto de energía (tasa metabólica en vatios) por unidad de mapa (m). Para esto utilicé esta fórmula:
M = 1.5W + 2.0 (W + L) (L / W)2 + N (W + L) (1.5V2 + 0.35V * abs(G + 6))
O poner en términos de calculadora ráster:
(1.5 * 60) + (2.0 * (60 + 3) * Square((3 / 60))) + (1.2 * (60 + 3) * (Square((1.5 * "movementspeed")) + (0.35 * "movementspeed") * Abs(("slopeinpercent" + 6))))
Donde M es la tasa metabólica en vatios, W es el peso del individuo modelado, L es la carga transportada del individuo, N es un factor que describe la facilidad de movimiento en el terreno (para fines de prueba establecidos en 1.2), V es el individuo velocidad de movimiento y G es la pendiente en porcentaje. Esto creó una superficie con valores que oscilan entre 90 y 25000, con la mayoría de los valores entre 90 y 1000 (lo que parece correcto, los valores absurdamente altos son probablemente el resultado de valores de pendiente defectuosos, que podrían ser fácilmente corregidos).
La velocidad de movimiento se calculó utilizando esta fórmula:
V = 6e^(-3.5 * |s + 0.05|donde s es la pendiente en grados.
O ponga en términos de Calculadora Ráster:
6 * Exp( - 3.5 * Abs(Tan("slopeindegrees") + 0.05))
Esto creó una superficie con valores entre 0 y 5.9 km / h, lo que parece correcto y es consistente con lo que esperaba.
Ahora, estas superficies se usaron como entrada en la herramienta Distancia de ruta; el DEM como el ráster de superficie de entrada (es decir, in_surface_raster), la superficie con gasto de energía como un ráster de costos y el DEM como el ráster vertical para permitir que la herramienta calcule si el individuo modelado se mueve hacia arriba o hacia abajo en una pendiente. Para fines de prueba, se usaron dos puntos en las esquinas noroeste y sureste del DEM como datos de origen (es decir, en_datos_de_fuentes). El resultado fue este (el rojo es intuitivamente los valores más bajos y el azul el más alto):
Mi interpretación de la salida es que ignora las diferencias en la elevación, y las diferencias en el valor simplemente están relacionadas con las diferencias en la distancia. Hubiera esperado que la superficie siguiera las áreas más planas en la parte occidental de la región y hubiera evitado las partes montañosas del este, lo que claramente no hace. Pero todavía soy bastante nuevo en este tipo de análisis y agradecería las interpretaciones de los demás. Entonces, ¿alguien puede señalar fallas en mi metodología / fórmulas que puedan causar un resultado extraño? O, ¿se espera la salida y simplemente estoy malinterpretando lo que debería esperar de un análisis de distancia de ruta?
Respuestas:
Esto es muy similar a cómo se ve nuestra salida de la herramienta de distancia de ruta que incorpora una especificación dem, ráster vertical y factor vertical (que es básicamente lo que está tratando de hacer con su capa de resistencia pero diferencia entre el movimiento cuesta arriba y cuesta abajo). Puede ser lo que se espera dado su rango de elevación y ponderaciones de resistencia. Pero, basándose en un vistazo rápido a su DEM y salida, parece haber una serie de cosas que podrían estar causando que sus resultados no aparezcan como desea y que es posible que desee echar un segundo vistazo para estar seguro.
1) Tiene una parte considerable en la parte suroeste de su área que parece haber sido codificada como nodata (ya sea en el DEM o en la capa de resistencia). En esta función, GIS trata los píxeles de nodata como esencialmente una resistencia infinita. (Es por eso que esa cosa de la isla tiene un valor de distancia muy alto)
2) Si está utilizando la distancia de ruta y especificando un ráster vertical pero no factores verticales (o viceversa) o si alguna de esas dos partes está especificada o formateada incorrectamente, la función simplemente no ejecutará esta parte de la herramienta y usará resto del algoritmo para producir resultados, pero no emitirá ninguna advertencia o indicación de que las porciones de dirección vertical u horizontal de los análisis no se ejecutaron correctamente. Además, a veces el programa usará un archivo de factor vertical u horizontal ASCII en algunas situaciones pero no en otras (como si funcionara con la GUI, pero no con Python), independientemente del formato. Esto puede hacer que esta herramienta sea difícil de solucionar. Normalmente entramos y comparamos los valores de distancia de una carrera con y sin los factores verticales para ver si son diferentes.
3) Es posible que pueda ver más detalles sobre lo que está haciendo la herramienta si la ejecuta en los puntos de prueba de uno en uno (en este momento solo puede ver la menor de las dos distancias en cada píxel, ya que la función solo registra las distancias desde cada píxel hasta uno de los dos puntos en la entrada)
4) Sin grandes diferencias de altitud en un área de estudio y / o un amplio rango de ponderaciones para los factores VRMA, el resultado de un análisis que incluye el costo de subir y bajar una colina a menudo simplemente no se ve muy diferente de Un análisis euclidiano de la distancia. Sin embargo, los números que obtenga serán ligeramente diferentes y, en algunos casos, si asigna las rutas de menor costo, tomarán rutas ligeramente diferentes.
5) Técnicamente creo que se supone que debes usar un ráster de puntuación z en lugar de un DEM como entrada para el ráster vertical, pero ambos se usan con frecuencia en los foros y, al menos para nuestros datos, las diferencias en la salida son mínimas.
La documentación de ESRI sobre esto está un poco dispersa, pero esta explicación de los factores verticales es bastante buena: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost % 20complejidad
fuente