Chciałbym przeanalizować hipotetyczny ruch (pieszo) w krajobrazie pod kątem zużycia energii, ale mam pewne kłopoty, które, mam nadzieję, mogą mi pomóc. Próbowałem to zrobić za pomocą narzędzia ArcGIS's Path Distance-Tool w programie Spatial Analyst, używając utworzonych przez nas powierzchni kosztów, ale nie są to oczekiwane wyniki.
Tak wygląda moja powierzchnia elewacji (pobrana z ASTER GDEM):
Na podstawie danych dotyczących wysokości utworzyłem powierzchnię kosztów, która powinna zawierać wydatek energii (tempo metaboliczne w watach) na jednostkę mapy (m). Do tego użyłem tej formuły:
M = 1.5W + 2.0 (W + L) (L / W)2 + N (W + L) (1.5V2 + 0.35V * abs(G + 6))
Lub wprowadź terminy kalkulatora rastrowego:
(1.5 * 60) + (2.0 * (60 + 3) * Square((3 / 60))) + (1.2 * (60 + 3) * (Square((1.5 * "movementspeed")) + (0.35 * "movementspeed") * Abs(("slopeinpercent" + 6))))
Gdzie M to tempo metabolizmu w watach, W to masa modelowanego osobnika, L to nośność osobnika, N to czynnik opisujący łatwość poruszania się w terenie (dla celów testowych ustawiony na 1,2), V to jednostka prędkość ruchu, a G to nachylenie w procentach. Stworzyło to powierzchnię o wartościach między 90 a 25000, z większością wartości między 90 a 1000 (co wydaje się słuszne, absurdalnie wysokie wartości są najprawdopodobniej wynikiem wadliwych wartości nachylenia, które można łatwo naprawić).
Szybkość ruchu obliczono za pomocą tego wzoru:
V = 6e^(-3.5 * |s + 0.05|gdzie s to nachylenie w stopniach.
Lub w terminach kalkulatora rastrowego:
6 * Exp( - 3.5 * Abs(Tan("slopeindegrees") + 0.05))
To stworzyło powierzchnię o wartościach od 0 do 5,9 km / h, co wydaje się właściwe i zgodne z tym, czego się spodziewałem.
Teraz te powierzchnie zostały użyte jako dane wejściowe w narzędziu Odległość odległości; DEM jako raster powierzchni wejściowej (tj. in_surface_raster), powierzchnia z wydatkiem energii jako raster kosztów, a DEM jako raster pionowy, aby umożliwić narzędziu obliczenie, czy modelowana osoba porusza się w górę lub w dół zbocza. Do celów testowych jako dane źródłowe wykorzystano dwa punkty w północno-zachodnim i południowo-wschodnim narożniku DEM (tj. In_source_data). Wynik był taki (czerwony to nieinicjalnie najniższa wartość, a niebieski najwyższa):
Moja interpretacja wyniku jest taka, że prawie ignoruje różnice w wysokości, a różnice w wartości są po prostu związane z różnicami w odległości. Spodziewałbym się, że powierzchnia podąży za płaskimi obszarami w zachodniej części regionu i uniknie górzystych wschodnich części, czego wyraźnie nie robi. Ale wciąż jestem nowy w tego typu analizach i doceniłbym interpretacje innych. Czy ktoś jest w stanie wskazać jakieś wady w mojej metodologii / formułach, które mogą powodować dziwne wyniki? Czy też oczekuje się wyników i po prostu nie rozumiem, czego powinienem oczekiwać po analizie odległości ścieżki?
Odpowiedzi:
Jest to bardzo podobne do tego, jak wygląda nasz wynik z narzędzia odległości odległości zawierającego specyfikację dem, pionowego rastra i współczynnika pionowego (co jest zasadniczo tym, co próbujesz zrobić z warstwą oporu, ale rozróżnia ruch pod górę i z góry). Może to być po prostu to, czego oczekujesz, biorąc pod uwagę twój zakres wysokości i wagi oporu. Jednak na podstawie szybkiego spojrzenia na twój DEM i wyniki wydaje się, że istnieje wiele rzeczy, które mogą powodować, że twoje wyniki nie będą wyglądać tak, jak chcesz, i że możesz chcieć się przyjrzeć ponownie.
1) W południowo-zachodniej części twojego obszaru masz spory kawałek, który wydaje się być zakodowany jako nodata (w warstwie DEM lub oporowej). W tej funkcji GIS traktuje piksele nodata jako zasadniczo mające nieskończoną oporność. (Właśnie dlatego ta wyspa ma bardzo dużą wartość odległości)
2) Jeśli używasz odległości ścieżki i określasz pionowy raster, ale nie czynniki pionowe (lub odwrotnie) lub jeśli którakolwiek z tych dwóch części jest nieprawidłowo określona lub sformatowana, funkcja po prostu nie wykona tej części narzędzia i użyje reszta algorytmu do generowania danych wyjściowych, ale nie będzie generować żadnych ostrzeżeń ani wskazań, że części analiz w kierunku pionowym lub poziomym nie zostały poprawnie wykonane. Czasami program użyje pliku współczynnika pionowego lub poziomego ASCII w niektórych sytuacjach, ale nie w innych (tak jak będzie działać, jeśli użyje GUI, ale nie Pythona), niezależnie od formatowania. Może to utrudnić rozwiązanie tego narzędzia. Zazwyczaj wchodzimy i porównujemy wartości odległości z biegu z czynnikami pionowymi i bez nich, aby sprawdzić, czy są one różne.
3) Możesz być w stanie zobaczyć więcej szczegółów na temat tego, co robi narzędzie, jeśli uruchamiasz je na punktach testowych pojedynczo (w tej chwili możesz zobaczyć tylko krótszą z dwóch odległości na każdym pikselu, ponieważ funkcja rejestruje tylko odległości od każdego piksela z powrotem do jednego z dwóch punktów na wejściu)
4) Bez dużych różnic wysokości na badanym obszarze i / lub szerokiego zakresu wag dla VRMA, czynniki wynikające z analizy, która uwzględnia koszty przesuwania się w górę i w dół, często po prostu nie różnią się znacznie od euklidesowa analiza odległości. Jednak liczby, które otrzymasz, będą nieco inne, aw niektórych przypadkach, jeśli mapujesz ścieżki o najniższych kosztach, wybiorą nieco inne trasy.
5) Technicznie myślę, że powinieneś użyć rastra Z-score zamiast DEM jako danych wejściowych dla rastra pionowego, ale oba są często używane na forach i, przynajmniej dla naszych danych, różnice w wynikach są minimalne.
Dokumentacja ESRI na ten temat jest nieco rozproszona, ale to wyjaśnienie czynników wertykalnych jest całkiem dobre: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost % 20 złożoności
źródło