# Least cost path: what does least cost value represent, based on slope raster layer

#### Context and question

I have a raster layer with slopes in percent and used the least cost path plugin in QGIS to calculate the least cost path from start to end. I try now to understand what the attribute value `total_cost = 1428.691` in the resulting line layer represents. How is `total_cost` calculated? This is probably software independet, but I used QGIS 3.30.0. Here the project and data can be found (all in one Geopackage file, 376 kB).

#### What I tried

1. My first idea was that it simply sums up the slope values of all cells touched by the path (sum of values in line 2 of all yellow cells in the screenshot below). To simulate this, I converted the raster to a polygon grid with same CRS (`EPSG:2056`), extent and resolution (0.5 m). I used select by expression to get all cells intersecting with the path (highlighted in yellow below), then created the sum of `slope` attributes of all selected cells. This resulted in a value of `2111.342`, so ca. 33% larger than the `total_cost` of the least cost path.

2. My second try was to weight the slope by the length of the path inside each cell: so the slope of cells that are only marginally touched by the path are less weighted than cells where the path passes throught the whole cell. I calculated the length of the segement the least cost path passes through the cell (first line in the labels below), multiplied this with the slope value. This value is the third line in the screenshot. I then summed up the results for all yellow cells. Here, I got a value of `715.900`, about 50% of the `total_cost`.

Both approaches do not produce the same value as `total_cost`. So how is `total_cost` calculated?

#### Screenshot

red line= least cost path; blue cells=slope raster; yellow/selected cells=cells intersection with the least cost path; Labels represent: 1st line: length of the least cost path inside the current cell, 2nd line: slope of the current cell (in percents); last line: length multiplied by slope: The plugin uses the Djikstra algorithm.

For orthogonal directions (up, down, left, right), the cost to move between two pixels is:

``````(pixel 1 + pixel 2) / 2
``````

For diagonal pixels, it's:

``````sqrt(2) * (pixel 1 + pixel 2) / 2
``````

Each cost is accumulated.

Below is a simple example using your slope data.

Total cost between below two points == 761.389  Slope values:

``````414.854095458984
116.551086425781
115.511352539063
110.033432006836
111.751174926758
``````

Total cost ==

``````sqrt(2) * (414.854095458984 + 116.551086425781) / 2
+
(116.551086425781 + 115.511352539063) / 2
+
(115.511352539063 + 110.033432006836) / 2
+
sqrt(2) * (110.033432006836 + 111.751174926758) / 2
``````
• This returns exactly the value I have. I only have to leave out the second last yellow cell at the bottom left with values 0.2 /12.806 / 2.2. Since the end-point is not in the middle of o pixel, the least cost path passes through this cell, but for calculation it seems start/end-points are snapped to pixel centroids and the last segment of the least cost path at the bottom left in fact is just a diagonal and does not cross the mentioned cell. Visually, when the line is drawn, it looks as if the cell is crossed, however. This is good to konw. May 7 at 15:31
• Don't forget that slope may not be the best way to model cost of traversing a pixel. I.e. it can be less costly to go down gentle hills than up and slope doesn't account for that, see Tobler's hiking function. May 7 at 21:12