# How can I estimate a Least Cost Path in Google Earth Engine?

I'm using Google Earth Engine to estimate walking time based on slope, using the Google tutorial and this example based on a DEM. My code actually runs, but I don't know what units the output raster is in.

To estimate the travel in time, I used an equation that gives me the hours needed to cross 30 m (the size of the pixel) for each degree of slope (Rees' update of Naismith's rule). For example, between 1 and 2 degrees, it takes 0.037 hours (2.2 minutes) to cross a 30 m pixel. According to the function reference, the cost should be to move across one pixel. I wonder if it accounts for diagonal or knight's moves. I used this code in GEE:

`````` cover.gt(1).and(cover.lt(2).multiply(0.0376700260935214).add(
``````

I calculated the values in Excel. The equation looks like this:

``````=(0.75+(0.09*ABS(TAN(RADIANS(slope in degrees))))+(14.6*(ABS(TAN(RADIANS(slope in degrees)))*EXP(2))))/3600*30
``````

The cumulativeCost function does seem to work – the cost raster shows higher costs for higher slopes (contours every 500 units).

My main question: The resulting cumulativeCost raster has values up to 10,620. What are units are these? My input is in hours but there's no way it takes 10,620 hours to walk across 10 km (the maximum distance). I want the output raster to be in hours of travel time.

A minor issue: What is the syntax for inputting the cost equation directly into the code, instead of adding a line of code for each degree of slope?

A broader question: How can I use this cost raster to estimate a least cost path between two points? I would need to estimate direction of travel somehow. I can't find any related functions and very few applications – is this even possible in Google Earth Engine?

Because you are using the ee.Image.and() method in your cost calculation, the resulting `cost` variable is binary. That is why the results seem non-sensical.

The units of the output of ee.Image.cumulativeCost() are the `cost` input parameter's unit multiplied by a unit of meter. You can test this by examining the result of a unit cost input (script link). So to get a travel time in hours, you will need to define `cost` in units of hours per meter.

The Excel formula that you quoted can be expanded out in pseudocode as:

``````(
0.75 + (
0.09 *
ABS(
TAN(
)
)
) + (
14.6 * (
ABS(
TAN(
)
) * EXP(2)
)
)
) / 3600 * 30
``````

Using Earth Engine's image math methods, it can be written as:

``````var slope_in_radians = slope.multiply(3.1415).divide(180);
var cost = (
ee.Image(0.09).multiply(
)
ee.Image(14.6).multiply(
.multiply(ee.Number(2).exp())
)
)
).divide(3600).multiply(30);
``````

or using the ee.Image.expression() method, it can be written as the following (where `b(0)` is the first band of the `slope_in_radians` image):

``````var cost = slope_in_radians.expression(
"(0.75 + (0.09 * abs(tan(b(0)))) + (14.6 * (abs(tan(b(0))) * exp(2)))) / 3600*30"
);
``````

• Excellent answer @Tyler! For the equation to be in hours per meter, I removed the final term (*30) and ran the updated code. This makes the cost surface range 0–2700 units – I am still not sure what the units are. It could be minutes... but I was expecting hours. Also, based on the shape of your other linked script, it seems that GEE does not use a knight's move (see this explanation). Aug 4, 2018 at 13:16

First To Answer this: A broader question: How can I use this cost raster to estimate a least cost path between two points?

First instead of a single point you can mask a source image as 0 and give it as input. Then on inspecting pixels it can calculate the cost from the source image to the destination pixel.

Now to answer this: I would need to estimate direction of travel somehow. I can't find any related functions and very few applications – is this even possible in Google Earth Engine?

I also faced the same problem, so here is what I did, I used the cumulativeCost() function using both my source and destination.

I then added these two costs to a different band. Why? Each pixel in the path will now have the same value as the cost (of src to destn OR destn to src). So on applying a filter or an expression you can give discrete values to pixels belonging and not belonging on the path.

You should now be able to visualise the path. (I'll try to add a reproducable code)