Least Cost Path results are strange

[AmyNewsam]

Hello All,

I ran a least cost path analysis from points to polylines in Pro.  At first it looked great, but when I zoomed in, all of the resulting paths either overshoot or undershoot the line features.  Overshooting is fine, but they need to at least touch the target lines.  Any ideas what could cause this?  (the paths also seem awfully straight, but other paths did have some variation, so maybe it's just because England is pretty flat?  I used a slope raster from Copernicus as my cost raster.)

[AmyNewsam]

Update - I realized the two feature classes were in different coord systems, so I put them in the same and reran LCP.  This time they paths looked much, much better, although still just a hair off of the lines.  I'm going to need these lines to touch, as I'll be using them for route analysis later.  Perhaps there's a way to fill in those gaps?  Or maybe there's a gap tolerance setting in route analysis... but still seems like there shouldn't be any gap.

[Anonymous User]

Hi Amy:

Which tools are you using for your least cost path generation?

If you're using DistanceAccumulation/OptimalPathAsLine (or the legacy versions CostDistance/CostPathAsPolyline), then your source features for DistanceAccumulation/CostDistance, which i think are the polylines in your case, are going to get rasterized first. The second step, path generation, will end at cell centers instead of precisely on the source lines.

You can mitigate this somewhat by using a smaller cell size for the analysis. You might also try post-processing with the extend line and trim line tools.

Regards,

Jim TenBrink

spatial analyst team

[AmyNewsam]

Hi Jim,

OK, I didn't realize the polylines were transformed to rasters during the process.  That makes sense.  I'm using the legacy tools, but I will look into the newer versions.  But I think the extend line option might be just fine.  Thanks so much for your help!

Amy

[Anonymous User]

Hi Amy:

You're welcome. Can you elaborate a bit on what your application is? In general, I don't recommend using a slope raster directly as an input cost surface. The slope of a cell can be zero, but having a zero cost to move through a cell is not legal. More generally, slope (either in degrees or percent rise) doesn't have a lot of meaning as a cost. I recommend using something like the reclassify tool to move slope ranges into cost units that are meaningful for your application (for example  - energy per meter, 'risk' per meter, travel time per meter, etc.). In other words, multiplying a value in an input cost cell times a distance has to produce 'accumulated distance' units (total energy, total risk, total travel time, etc). An example that uses reclassified slope is given here.

-jt

[AmyNewsam]

This is for faculty research on estimating historical routes between cities across Europe.  The primary roads are already determined (at least, there is a shapefile that everyone seems to use, even though it's rather crude), but the cities don't fall directly on those lines, so we're trying to estimate a likely route from the cities to the existing routes.  Then I would use route analysis to determine the shortest routes between each pair of cities.  I'm not sure LCP is really very helpful in identifying where these roads actually were, but it seems to be what people use.  Stanford has a brilliant tool for calculating likely routes based on all sorts of factors, but I need to get all the routes at once - over 1,000,000 routes. 

I'll have to look into how to create a better cost raster... the slope raster I used from Copernicus ran without any holes in the resulting cost distance and backlink rasters, so perhaps the zeros were already fixed?  I have no experience with raster analysis, so this is a good learning opportunity for me.  🙂

[JamesTenbrink · Accepted solution]

Thanks for that additional info. By 'copernicus slope' are you referring to this map service ? It looks like the values in the service are neither slope-in-degrees nor slope-ratio, which is a bit misleading. The metadata site provides a lookup table for converting those cell values into slope-in-degrees.

But the larger issue is trying to use any kind of slope directly as an input cost raster. I don't recommend doing it because your output accumulative cost units may not be meaningful (what does distance  times degrees mean?).

I recommend that, for your application, you first define the agent that is moving (is it humans on foot, horses, motorized vehicles)? That will influence how you transform slope to meaningful units for your analysis, as well as indicate additional inputs which may be needed (for example: barriers , land use/land cover, etc.).

Directionality may also be important. Its easy to walk along a contour line, even if you're on a steep slope. The DistanceAccumulation tool allows you to incorporate directionality (but additional inputs are then required). This help topic goes into more detail on directionality.

Least cost path modelling can get complicated and abstract. Perhaps the best way to get a first approximate answer is to simply use an input cost raster with all cells set to 1, along with two additional input parameters: a DEM as the surface input parameter, and an input dataset to identify barriers  (rivers, cliffs, swamps, etc). Your output paths will then be true shortest ground paths but accounting for moving around barriers and the increased length of going up and down hills. Use the new Distance Accumulation/Optimal Path As Line combination when doing this. The older CostDistance/CostPath approach did not do as good a job with that case, as explained in this blog post.

Regards,

-jt

[AmyNewsam]

Yes, slope alone really doesn't make much sense, does it?  I will try your suggestion in the last paragraph as a first pass, which should be good enough for our purposes.  Thanks again for all your help!  -- Amy