This is very similar to what our output looks like from the path distance tool incorporating a dem, vertical raster, and vertical factor specification (which is basically what you are trying to do with your resistance layer but it differentiates between uphill and downhill movement). It may just be what's expected given your elevation range and resistance weightings. But, based on a quick look at your DEM and output there appear to be a number of things that could be causing your results to not appear as you might wish and that you may want to take a second look at to be sure.
1) You have a sizable chunk in the southwestern part of your area that seems to have been coded as nodata (either in the DEM or resistance layer). In this funciton, GIS treats nodata pixels as essentially having an infinite resistance. (This is why that island thing has a very high distance value)
2) If you are using path distance and specifying a vertical raster but not vertical factors (or vice versa) or if any of those two parts are improperly specified or formatted, the function will simply fail to execute this portion of the tool and use the rest of the algorithm to produce output, but will not issue any warnings or indications that the vertical or horizontal direction portions of the analyses were not executed properly. Also, sometimes the program will use an ASCII vertical or horizontal factor file in some situations but not others (like it will work if using the GUI, but not python), regardless of formatting. This can make this tool difficult to troubleshoot. We usually go in and compare the distance values from a run with and without the vertical factors to see if they are different.
3) You may be able to see more detail about what the tool is doing if you run it on your test points one at a time (right now you can only view the shorter of the two distances at each pixel, since the function only records the distances from each pixel back to one of the two points in the input)
4) Without large differences in altitude across a study area and/or a wide range in weightings for the VRMA factors the output from an analysis that looks at including the cost of moving up and down a hill often just doesn't look much different from a euclidean analysis of distance. However, the numbers you get will be slightly different, and in some cases if you map the least cost paths they will take slightly different routes.
5) Technically I think you're supposed to use a z-score raster instead of a DEM as input for the vertical raster, but both are used frequently on the forums and, at least for our data, the differences in output are minimal.
ESRI's documentation on this is a little scattered, but this explanation of the vertical factors is pretty good: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Path%20Distance:%20adding%20more%20cost%20complexity
Best Answer
GRASS GIS has a C implementation in
r.cost
(source, documentation) which uses a min-heap. Alternatively, you could use a graph package like QuickGraph and Floyd-Warshall to compute the cost.Recent changes in GRASS 6.4 have made r.cost significantly faster, so perhaps performance may be good enough: on my laptop, it takes about 3s for a 1M cell region, or 5s with knight's move enabled. GRASS is a C application, not a drop-in solution for a C# codebase. If you're OK adding to your stack, you could use PyWPS to make calls to GRASS, and then use the result elsewhere in your application.