both are same

http://www.caee.utexas.edu/prof/maidment/giswr2013/Synopsis/Slope.pdf

http://www.colgate.edu/portaldata/imagegallerywww/9f6bbcda-184d-4f20-bf0f-05069a418363/ImageGallery/15_GEOG245_Tutorial8.pdf

For correct result you should calculate the slope in degrees and then convert to radians. Only then use the raster in equation. What you will get is the speed of movement through each cell. In my case the latter varies between 9,43046 x 10^-5 km/h and 5,04 km/h as the slowest and fastest respectively.

Thank you Ales for your informative reply.

I was wondering if you have ever tried to calculate the least-cost path between a source and a destination location on the basis of speed of movement, i.e. following the procedure described by source B listed in my question here?

Yes I've done this once. It is briefly described here: https://www.researchgate.net/publication/303857584_From_Hill-Fort_to_the_Mountain_Pass_and_Back_A_Comparison_of_Three_Pathfinding_Methods

Conference Paper From Hill-Fort to the Mountain Pass and Back: A Comparison o...

My additional question is: imagine that you have multiple source locations, and multiple destination locations. How is it possible to perform least-cost path analysis pairwisely, without being force to repeat the process n times (n being the number of source locations)? Have you ever faced this same or a similar issue?

In the conference contribution I added above we were able to implement the ArcMap method in Modelbuilder but not as you describe it. If I remember correctly we had to calculate the paths for each of the source locations iteratively and were able calculate it to many destinations so paths lead from all sources to all destinations. The other, even more efficient way would be to write a python script and you could process the locations and destinations pairwise.

Thank you. I will try and learn Python.

Good luck. If you need any help please go ahead. 

@Ales Grlj: eventually I managed to calculate Least-Cost paths from multiple source to multiple destinations in ArcGIS, using "Iterating Feature Selection" in Model Builder. In this way, ArcGIS will calculate the LCPs iterating trough the input sources. Should you need further details, just let me know.

Further, I was wondering: once a LCP has been calculated (say, from A to B), how can one calculate the final total walking time at B location? 

You can use Gorenflo & Gale (1990). Their equation is V = 6e-3.5|s+0.05|, where V is walking speed in km/h, s is the slope of terrain (calculated as vertical change divided by horizontal change) and e is the base for natural logarithms. The transformation of km/h is realised by the general formula 3,6/value of the raster cell (V). So the final vaules of your raster are s/m and you can evaluate time expenditure from your known point to each other cell within the region.

Hello @Joan, thank for your reply. Yes, indeed I used the approach you described, and I managed to get the anisotropic distance raster representing the time (in my case, hours) in which each can be reached by walking from the source location. On this basis, using the Cost Path tool in ArcGIS, I calculated come least-cost paths. But, once I got (say) two least cost paths (from A to B, and from A to C), how can I calculate the actual time that would take me to go from A-to-B and from  A-to-C? I am unsure if it would suffice to extract the value of the underlying anisotropic distance raster to the destination locations (i.e., B and C).

Hi @Gianmarco, there are multiple approaches to accomplish this. First, least accurate and simplest would be to generate contours from the results of Cost Distance tool and estimate the time from it.

If I remember the LCPs from model builder are in raster format. You could Set Null to all values (cells) that are not path (if they are not allready) and then convert to points. If anisotropic distance raster that you mention in the above answer is per cell, meaning that value of each cell represents time in hours to pass through it (not the cumulative time), you could extract the values to points shapefile from the beginning of this paragraph. What remains is only to sumarize the values in attribute table of the points shapefile. There should be no problem in implementing this in model builder with iteration to automatically process all the paths you created previously.

Other methods that come to my mind again include Python:)

Oh, and congratulations for implementing the previous step in model builder!

If the values of the resultant raster are in seconds per meter, you can obtain the cumulative map of the values with the cost distance function of ArcGIS. I don't understand if there is another problem I am not seeing it. If the problem is due to the cell resolution, you can transform the raster to 1m pixel size.

Well if he calculated paths then the Cost Distance is already there. I was thinking also on the representation of the routes.

@Joan and @Ales: thank you for replying back. And apologies if I am complicating things to much. I am surely missing something. Just let me rephrase: I used PATH DISTANCE followed by COST PATH to calculate the Least Cost Path. So far so good. Now, I want to be able to say "ok, that path is the least-cost one, and it would allow to go from A to B in (say) x minutes". How can I work out that? Shall I just extract the value of the anisotropic cost raster and attach it to B? (disclaimer: by anisotropic cost raster I mean the output ratser of the PATH DISTANCE tool, which is actually representing for each cell the cumulative cost (in my case, in terms of time) of moving away from the source cell). Hope I managed to make my point clearer.

Yes, I was definitely overthinking. Calculating the final cost of a path is definitely tantamount to extracting the value of the anisotropic raster (from the source) at the destination location.

To  make me sure, I made a simple calculation using A (source) and B (destination), converting the path from raster to points, and extracting the values of the underlying anisotropic raster to the path's points. The attached pict is showing the last bit of the path (toward the destination; B: green triangle), with labels corresponding to the cumulative time from the origin.

Maybe that fact that I was dealing with multiple sources and multiple destination misled me.

Feel free to comment further. 

Thank you for your insights.

Best

If the cells of your raster are bigger than 1m res. the value of each cell correspond to the time needed for going through 1m along that pixel. In order to calculate the exact cumulative time of your path between A and B, you need to either have 1m res. pixels or multiply the value of each pixel for its resolution in meters (or the unit you are using in your model s/m, h/km, etc.). In all those calculations we are assuming displacement along pixel's axes.

On the other hand, are you sure you are dealing with an anisotropic model? Is the cost between A and B different that between B and A? I made that mistake before, but a cost dependent model is not the same than an anisotropic one. Nevertheless, if stated, it is correct to assume the hypothesis of movement isotropy, meaning that directional slope has a minor effect on the quality of the displacement model (Llobera 2000; van Leusen 2002).

@Joan: thanks for the follow up. Yes, since I am implementing Tobler's hiking function, the model is anisotropic; so, as you correctly pointed out, the cost from A to B is not necessarily equal to that from B to A. And again yes, you raise a sound point about the cell resolution. I am wondering why references (A) and (B) (listed in my earlier thread) do not mention that "issue".

I really don't know, but they state very explicitly the results being "TIME (HOURS) TO CROSS 1 METER", so if your cell res. is 15m you nead at least 15 times that time to cross the pixel. I mentioned the assumption of non-directional slope because it is an important premise when you are working on cost-based autocorrelation models rather than LCP or SCs.

As far as I know the output of the Tobler's hiking equation is maximum speed that each cell allows to move through it in km/h. You can verify this by examining the maximum value of the result. If it is in km/h the max should be somewhere between 5 and 6 depending on slope values (see image below that we used in our last publication on this matter where the speed is shown on vertical axis and slope on horizontal). To get the speed in m/s the multiplication of the result with 0,2778 is required as 1 km/h = 0,2778 m/s. Now to get the actual time (in this case in seconds) to pass through each cell one should divide the cell size with the speed. This approach, as Joan said, assumes that you move along the cell axes and will underestimate the time needed to get to your destination. In the division above you could use diagonal of the cell (as we did in our research) as you can move diagonally also but the resulting time could be overestimated. From here on you could use the aproach with conversion of the paths to points I described above.

Oh and one more thing, unit of speed: TIME (HOURS) TO CROSS 1 METER from the first reference is really wierd, I noticed this just now. Why would someone use such unit. Therefore the equation used there is also differernt from original Tobler's equation which can be found on the link below. Also everything that I have written here (conversions and stuff) applies to the original Tobler's equation.

https://en.wikipedia.org/wiki/Tobler's_hiking_function

@Ales: "As far as I know the output of the Tobler's hiking equation is maximum speed that each cell allows to move through it in km/h"

Yes, you're correct. But, if you follow the workflow described by references (A) and (B) (see my earlier thread), you will notice that the output raster returned by the PATH DISTANCE tool (in which you use a user-defined vertical factor table, which is provided by those two sites) is the cumulative time to cross 1 cell from the source location. In this specific case, the time is in HOUR. Then, one can use the COST PATH tool to calculate the LCP. Of course, if the time in minutes is needed, one has to multiply the hour raster by 60.

@Gianmarco, in order to test taking into account pixel size in your calculation, might you calculate the cumulative time from A to B both with your original time raster and also multiplying it by your cell resolution? The results should be up to an order of magnitude (depending on the res.) than the originals. If you know the sites location and distance, maybe you can compare the results for assessing which model is the correct one. For example, for a raster with a 10m res. you'd have a path accounting for either 6 minutes between A and B or 1 hour. Let me know!